WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Steve Green
Date: Aug 5, 2025 7:31AM

Hi Sailesh, this isn’t about the accessible name. It’s about whether a link’s child element’s role should appear in the accessibility tree and be announced by screen readers. Every specification I can find says it must, but JAWS and NVDA violate that. I will report bugs against both of them.

The ARIA specification states that a button’s child element’s role should not appear in the accessibility tree, but it is not prohibited. Chrome and Firefox expose it, which is allowed. Safari does not, which is also allowed. NVDA ignores it, which is ok. JAWS ignores the child’s role, which is ok, but it announces the child’s contents instead of the “aria-label” attribute, which is a bug that I will report.

My apologies to everyone who is bored to tears by this thread, but I regard it as important that we determine the expected behaviours in terms of authoritative specifications rather than the old wives’ tales, rumours and over-simplifications that abound in our profession.

Steve

From: Sailesh Panchang < <EMAIL REMOVED> >
Sent: 05 August 2025 14:03
To: WebAIM Discussion List < <EMAIL REMOVED> >
Cc: Steve Green < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe) (Steve Green)

The accessible name for the link can be derived from the link's content. But as we know the aria-label overrides that so I believe the SR does not have to look at the link's content and expose that to the user. Else what is the point of the aria-label taking precedence?
If the anchor's content be it a heading or a data table is what needs to be available to the user, then inserting an aria-label is plain wrong.
Alright, just because "any HTML flow content inside a link" is valid, it does not mean one needs to do that unless it serves a usable purpose.
An anchor tag (with an href) is meant to serve as a link, which when activated will bring up the content of the relevant URI. That purpose available as the link's name needs to be clear to everyone. It needs to pass SC 2.4.4.
Thanks
Sailesh Panchang

Email: <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
Deque Systems Inc | - Accessibility for Good | www.deque.com<;http://www.deque.com>;













On Tue, Aug 5, 2025 at 6:04 AM Steve Green via WebAIM-Forum < <EMAIL REMOVED> <mailto: <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