WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Steve Green
Date: Aug 4, 2025 8:01AM

Thanks for this, Sailesh. However, the article doesn’t address the issue of “aria-label” attributes overriding the roles of child elements.

Steve

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

Here is an article on the topic written some time ago:
Text link Accessibility: aria-label and title attribute
https://www.deque.com/blog/text-links-practices-screen-readers/
Sailesh Panchang

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













On Fri, Aug 1, 2025 at 1:49 PM Steve Green via WebAIM-Forum < <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >> wrote:
I have been testing a website that contains some code that is nasty, but not strictly wrong as far as I can tell. Both JAWS and NVDA handle it in a way the developer would not have intended, and not only do they behave the same, but they do so with both Chrome and Firefox. I am told that Voiceover on macOS handles it differently, but I have not verified it and it's not particularly relevant. The code is very simple:

<a href="#" aria-label="foo">
<h3>bar</h3>
</a>

It's not obvious how you would expect a screen reader to announce this, but you would probably expect its announcements to include a link called "foo" and a heading called "bar". Or maybe a heading/link called "foo". Neither of these happen. JAWS and NVDA just announce a link called "foo" and nothing else. If the "aria-label" attribute is removed, they announce a heading/link called "bar", as you would expect.

The accessibility tree shows that the <a> element has an accessible name of "foo" and that the heading contents are "bar". This looks correct to me and suggests that JAWS and NVDA are interpreting it incorrectly. But before I report the issue to both vendors I would be interested in the thoughts from this forum. Are the browsers doing something wrong? Is the correct behaviour ambiguous? Is the code invalid in a way I've missed?

Steve Green
Managing Director
Test Partners Ltd