RE: 4.3 Text Alternative Computation Example under 2B

Hi,
Both examples are correct.

The first one in the spec is correct because the “/>” at the end of the element indicates that this is an automatically closed element that has no inner HTML. This is also true for elements that have no child elements by design such as IMG, Input, etc.

Your example however uses an element that does support child elements and does have embedded content, so your example changes the accessible name to reflect the content as the accessible name in accordance with the spec.


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

From: Devarshi Pant [mailto:devarshipant@gmail.com]
Sent: Monday, June 26, 2017 8:29 AM
To: public-aria@w3.org
Subject: 4.3 Text Alternative Computation Example under 2B


Refer to the code snippet under #2B (https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te) –

<element1 id="el1" aria-labelledby="el3" />

<element2 id="el2" aria-labelledby="el1" />

<element3 id="el3"> hello </element3>

Where second bullet says, “element2 has no accessible name. The computation involves a first traversal of its aria-labelledby leading to element1, but element1's aria-labelledby is not subsequently followed.”

I think element2 does have an accessible name. It is the innerHTML of element1. Note - IDREF upon subsequent traversal at element2 points to element 1.

 Here is an example similar to the one under #2B:

 <a id="el1" href="#" aria-labelledby="el3">Link 1</a>

<a id="el2" href="#" aria-labelledby="el1">Link 2</a>

<a id="el3"> hello </element3>

On testing with JAWS 17 / 18 and NVDA 2017, Link2 (with aria-labelledby pointing to Link1) is read as Link1, which implies Link2’s accessible name is Link1.
Thanks,
Devarshi