WebAIM - Web Accessibility In Mind

E-mail List Archives

for

From: Sailesh Panchang
Date: Aug 1, 2025 1:46PM

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>
Deque Systems Inc | - Accessibility for Good | www.deque.com














On Fri, Aug 1, 2025 at 1:49 PM Steve Green via WebAIM-Forum <
<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
>
>