WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Birkir R. Gunnarsson
Date: Aug 5, 2025 4:54AM

That's the problem when browsers and AT vendors do not follow the
specifications and/or when the specifications are too vague.
Sometimes they break with the spec for the good of the end users, but in
those cases they should push for the recommendation to be modified.
I believe in HTML5 you can put any HTML flow content inside a link
(including headings, even entire tables).
For a button you can't, since all child elements of a button are
presentational.
Have you viewed the accessible name of the link and the heading as
calculated by Chrome (in the Chrome developer tools)?
I am wondering whether it is Chrome or the screen reader that decides
whether to expose the heading markup or not once there is an aria-label on
the link that overrides the heading content.
Have you tried reversing the setup; wrap the link in the heading and put
aria-label on the heading?
Note, I tried a while back and it didn't work. Only Voiceover + safari
exposed the aria-label value as the accessible name of a heading.


In BCAG (Birkir's version of WCAG) I fail all link/heading combos unless
the accessible name of the link and the heading are identical and both
serve to label the content section and identify the link target, usually
this means people end up not using this combo. ;) But BCAG is not yet an
official recommendation and never will be.




On Tue, Aug 5, 2025 at 6:04 AM Steve Green via WebAIM-Forum <
<EMAIL REMOVED> > wrote:

> Hi Laura, I see that "ignored: Yes (default)" in Safari when the parent
> element is a button, and VoiceOver does indeed ignore the heading. This
> follows the ARIA specification. JAWS ignores it too. NVDA doesn't, but
> that's ok because the requirement is a "should".
>
> The ARIA specification says that the link role does not have "Children
> Presentational: True", which is why VoiceOver announces both the link and
> the heading. I still don't understand why JAWS and NVDA don't, because both
> of them expose the heading in the accessibility tree regardless of whether
> the parent is a link or a button. It looks like JAWS and NVDA are making
> the decision not to announce the heading, not the browser.
>
> I didn't write this code and wouldn't have done - I am just investigating
> problems screen reader users have reported with a large e-commerce website.
> The organisation say they did a WCAG audit and tested with VoiceOver on
> macOS, but JAWS and NVDA users are getting a different and much worse user
> experience. A fix would be trivially easy - they just need to remove the
> "aria-label" attributes - but it's usually all but impossible to get large
> organisations like this to make even the simplest of changes when they can
> hide behind a test report that says everything is ok.
>
> Steve
>