Links that include header elements omit their descendant content from the link's accessible name

[mraccess77]

If you have a link with href attribute and the link contains a header element and other sibling elements such as a span or div - the content within the descendants of the header is not included in the name from content of the link while the text content from other elements are included in implementations of the accessible name calculation. Browser's like Chrome omit this content but some screen readers announce it - so it seems like there is inconsistent implementation of how to handle this situation. It would be good to get clarity on if the text within the header should be used.

[chrisblouch]

So a structure like this:

<a href="foo">
   <header>
       <time>Some text</time>
       <h1>More info</h1>
   </header>
   <div>
      <span>Read about it</span>
   </div>      
</a>

Should the accessible name be just "Read about it" or should the elements in the header contribute text as well? Voiceover seems to just read the span at the end while Jaws and NVDA read it all when tabbed to but presents as three links when arrowing through. Chrome's accessibility tab says the link has an accessible name of "Read about it".

[JAWS-test]

Related: #120

[accdc]

Hi, in this case the result would be accName: "Read about it"

The reason why is because header in this case maps to role="banner" in the accessibility tree, and banner is a landmark region that does not support "name from content" in accordance with the ARIA spec.

This relates to the implicit mapping section at:
https://www.w3.org/TR/html-aria/

header
"If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner
Otherwise, role=generic"

In contrast, if role=generic is applied according to these rules, then the header content should be parsed. The generic role should always be traversed, otherwise content from divs and spans would not be parsed either.

There isn't anything in the AccName spec that would specifically prevent header from being parsed as part of the recursion algorithm. It gets complicated when implicit mappings change the perceived role of an element, though this is handled as part of a different spec.

[mraccess77]

Hi Bryan, thanks for that detail - In the case we are finding it the anchor is a descendant of an article, section, and aside (all 3) and it is not working as expected with the acc name calc prototype or Chrome's accessible name calculation. So it seems like this nuance is not being picked up consistently.

[accdc]

Thanks, we discussed this today in the ARIA meeting, and it is related to the issue filed against ARIA
w3c/aria#1821

I've agendad the original AccName traversal issue so we can hopefully get some traction on this soon.

[cookiecrook]

Related: w3c/aria#1860

[MelSumner]

we are finding it the anchor is a descendant of an article, section, and aside (all 3) and it is not working as expected with the acc name calc prototype or Chrome's accessible name calculation

@mraccess77
All three at once? Or all three separately? Can you give me a code sample that demonstrates the issue? A trivial example would be fine, I'm just having a hard time imagining what you are seeing in the DOM.

[mraccess77]

we are finding it the anchor is a descendant of an article, section, and aside (all 3) and it is not working as expected with the acc name calc prototype or Chrome's accessible name calculation

@mraccess77 All three at once? Or all three separately? Can you give me a code sample that demonstrates the issue? A trivial example would be fine, I'm just having a hard time imagining what you are seeing in the DOM.

Chris Blouch provided the example above I was referring to. Thanks.

[chrisblouch]

The example I provided on January 23 was found in the wild and was originally inside an Aside element. So if that changes things, the more complete markup would be:

<aside>
   <a href="foo">
      <header>
         <time>Some text</time>
         <h1>More info</h1>
      </header>
      <div>
         <span>Read about it</span>
      </div>      
   </a>
</aside>

The same site had the same Anchor structure inside an Article element as well and exhibited the same behavior. Both the Aside and Article elements were children of a Section element.