Re: AccName test expectations bug + prototype bug?

As far as I know the title attribute in HTML does not define a text alternative so 2.D. should not apply in any case where there is a title attribute in HTML.
2.I. should be where title occurs in the accessible name calculation.

I have previously logged https://github.com/w3c/accname/issues/10 on this.


James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com



From: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Date: Wednesday, September 12, 2018 at 10:51 AM
To: "jdiggs@igalia.com" <jdiggs@igalia.com>
Cc: "bryan.garaventa@ssbbartgroup.com" <bryan.garaventa@ssbbartgroup.com>, "public-aria@w3.org" <public-aria@w3.org>
Subject: Re: AccName test expectations bug + prototype bug?
Resent-From: <public-aria@w3.org>
Resent-Date: Wednesday, September 12, 2018 at 10:50 AM

Hi, Joanie.

I guess 2. D. is fuzzy in this case, because it says:

" if the current node's native markup provides an attribute<https://w3c.github.io/accname/#dfn-attribute> (e.g. title) or element<https://w3c.github.io/accname/#dfn-element> (e.g. HTML label) that defines a text alternative, return that alternative "

but the example has both an attribute (title) AND an element (label) so the returned value is ambiguous.

Sorry...
Car


----- Original message -----
From: Joanmarie Diggs <jdiggs@igalia.com>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: AccName test expectations bug + prototype bug?
Date: Wed, Sep 12, 2018 11:45 AM

Hey Bryan, all.

In order to get AccName out the door, I'm trying to fix the remaining
issues in the implementations. While working on one, and discussing it
with others (including the HTML-AAM editors), my conclusion is that our
expectations are wrong.

One example test case -- which is repeated in multiple variations
throughout our test set -- can be found here:
https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_test_case_661.

As you will see there, the expected result is "foo bar baz". That test
case has CSS-generated content which is not relevant to the problem at
hand, so I'll provide a simpler variant:

<label for="test">foo <input id="test" type="button" name="test"
title="bar"> baz</label>

Beginning the calculation from the AccName spec:

1. Root node = input with id="test"
   Current node = input with id="test"
   Total accumulated text = ""

2. Compute the text alternative for the current node (input with
   id="test"):

   A. n/a because the current node is not hidden.

   B bullet 1. n/a because the current node lacks an aria-labelledby.

   B bullet 2. n/a because we're not computing a description.

   C. n/a because the current node lacks an aria-label.

   D. Does apply because the current node's native markup does provide
      an attribute (e.g. title) or element (e.g. HTML label) that
      defines a text alternative. We are instructed to "return that
      alternative in the form of a flat string as defined by the host
      language." Therefore, we should return "foo baz" as the accessible
      name; not "foo bar baz".

Do you agree with my assessment? If so, then we need to update the test
expectations in WPT and regenerate results based on those expectations.

In addition to the above, while I'm pretty sure that Bryan's
tool/prototype used to return "foo bar baz" for test case 661, it no
longer does. Now it returns accName: "foo bar baz bar". Surely that's
not correct (right?).

Thanks in advance for your timely responses to these issues (Must. Get.
AccName. Out. The. Door! :))

--joanie