RE: Accessible name computation and web-platform-tests

That sounds correct to me.


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: James Nurthen <nurthen@adobe.com>
Sent: Monday, October 28, 2019 3:39 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Sebastian Silbermann <silbermann.sebastian@gmail.com>; public-aria@w3.org
Subject: Re: Accessible name computation and web-platform-tests

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

So do we need to move (and modify) the following text:
“If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, ignore aria-label and skip to rule 2E.”

I’d suggest (from reading this thread) that this needs to be the first bullet under 2B not 2C and should read:
“If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, then skip to rule 2E.”


James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com<mailto:nurthen@adobe.com>



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Date: Monday, October 28, 2019 at 3:32 PM
To: Sebastian Silbermann <silbermann.sebastian@gmail.com<mailto:silbermann.sebastian@gmail.com>>, "public-aria@w3.org<mailto:public-aria@w3.org>" <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Accessible name computation and web-platform-tests
Resent-From: <public-aria@w3.org<mailto:public-aria@w3.org>>
Resent-Date: Monday, October 28, 2019 at 3:32 PM

Hi,
That’s true for widget controls, where it doesn’t matter if aria-labelledby or aria-label is present, nor an associated label element with matching for and id attributes, nor a title attribute. Only the value is taken into account if the widget control is an embedded child node of the root node.

This widget control value is ignored however, if the root node is the same widget control that is referencing a parent container as the label for that control, in which case, both the root node and the current node are the same node.

E.G

<label>
Date of birth:
<input type=”text” value=”11/25/1979”>
</label>

In this case, “Date of birth:” is the accessible name for the input, no matter what the value property is.

Hopefully this makes sense.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Sebastian Silbermann <silbermann.sebastian@gmail.com<mailto:silbermann.sebastian@gmail.com>>
Sent: Sunday, October 27, 2019 8:27 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Re: Accessible name computation and web-platform-tests

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I think the point is that 2C has to be checked regardless of the existence of the `aria-label`. Meaning that since we are traversing current node due to recursion and it is an embedded control we skip 2D and use 2E.

Am Mi., 23. Okt. 2019 um 08:38 Uhr schrieb Sebastian Silbermann <silbermann.sebastian@gmail.com<mailto:silbermann.sebastian@gmail.com>>:
Thanks for the response Bryan.

Ok I understand the which step is used but in the algorithm step 2D comes before 2E. In 2D we check for a title attribute, no? Where is it specified that we don't use the title if the current node is not the root node?

Or is it actually step 2D and we prioritize the value attribute over the title attribute? If so where is this order specified?

And last but not least: The element is a combobox. Where is it specified that the chose option is the value attribute? The sentence explicitly links to the option role not a section that specifies how to compute the chosen option of a combobox.

Thank you for your time. I appreciate it that someone assists me understanding this!

Am Di., 22. Okt. 2019 um 00:43 Uhr schrieb Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>:
Hi,
Actually this has to do with the difference between the ‘root node’ and the ‘current node’, where, for widget controls, only the value is returned when the root node is not the same as the current node.

In this case, the root node is the heading, and that is where it stays during the computation. In contrast, the current node is recursively moved into the child nodes within the heading to compute the accessible name for the root node.

If this were a different test, such as testing the accessible name only on the combobox, then the title attribute would be used because both the root node and the current node are the same element, and the value property is not a valid labelling mechanism for a widget control.

However, since the root node and the current node don’t match, and the current node is a widget with a value, then it returns the name based on the AccName step 2E, where it states:

“■ If the embedded control has role combobox or listbox, return the text alternative of the chosen option.”
https://www.w3.org/TR/accname-1.1/


Since the accessible name for the combobox is already returned using its value, the title attribute is ignored.

Hopefully this makes sense.

All the best,
Bryan



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Sebastian Silbermann <silbermann.sebastian@gmail.com<mailto:silbermann.sebastian@gmail.com>>
Sent: Friday, October 18, 2019 4:59 AM
To: public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Accessible name computation and web-platform-tests

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello,

I'm currently implementing the accessible name computation for HTML elements following https://w3c.github.io/accname/ and comparing the results with https://github.com/web-platform-tests/wpt/tree/574af55b103d2e732efa72af2719121f96db38f3/accname.


There's currently one test case that confuses me:
<h2>
  Country of origin:
  <input role="combobox" type="text" title="Choose your country." value="United States">
</h2>
from https://github.com/web-platform-tests/wpt/blob/574af55b103d2e732efa72af2719121f96db38f3/accname/name_heading-combobox-focusable-alternative-manual.html


The test expects the accessible name for the h2 element to be "Country of origin: United States". However, I'm not sure which path in https://w3c.github.io/accname/#mapping_additional_nd_te is taken to arrive at this computation as I arrive at "Countr of origin: Choose your country".

From my understanding we use 2F since h2 allows name from content and then we concetanate the text node and the accessible name of the input. However for the input I would use 2D which isn't defined in this document as far as I can tell. So I looked into https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element and there it says I should use the `title`. There's no mention of using the `value` attribute.

What I could see is 2E being used for the input (combobox) and then the `value` being considered as the selected option.

I would appreciate it if somebody could clarify this. So far the documents have been very clear to me.

Kind regards,
Sebastian