E-mail List Archives
Number of posts in this thread: 6 (In chronological order)
From: Steve Green
Date: Aug 1, 2025 11:49AM
Subject: Weird bug in both JAWS and NVDA (maybe)
No previous message | Next message →
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
From: Steve Green
Date: Aug 1, 2025 11:55AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
It's worth mentioning that the heading also does not appear in JAWS' Headings List and cannot be found using the screen reader's H or 3 shortcuts.
Steve
From: Léonie Watson
Date: Aug 1, 2025 12:06PM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
This isn't a bug. It's the way the Accessible Name and Description
Computation algorithm works [1].
The short version is that ARIA takes precedence over all other sources
for the accessible name, so in this case the content of the anchor is
overridden by the value of the aria-label attribute.
Léonie
[1] https://www.w3.org/TR/accname-1.1/
On 01/08/2025 18:49, Steve Green via WebAIM-Forum 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
>
--
Léonie Watson (she/her)
Director
https://tetralogical.com
Looking to kick start or refresh your accessibility knowledge? Then
sign-up for our free six day newsletter Accessibility Unlocked!
<https://tetralogical.com/newsletters/accessibility-unlocked/>
From: Patrick H. Lauke
Date: Aug 1, 2025 12:11PM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
The aria-label completely overrides whatever's inside that link, so this
is as expected.
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Christine Hogenkamp
Date: Aug 1, 2025 1:00PM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
Hi Steve,
In terms of proper HTML, the header tag should go on the outside and the
link would go inside. A link tag is by default an "inline" element like a
span tag compared to a header tag, which by default is a display:block
element. My understanding is that HTML5 is a bit more flexible about this
and most modern browsers are more forgiving of incorrect HTML, but there
may be assistive devices/tech that follows the rules of older HTML and
operate in a more strict fashion.
This may explain why you are experiencing some announcement issues.
*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer & Accessibility Lead
Context Creative – a Mod Op company
416.972.1439 | contextcreative.com
On Fri, Aug 1, 2025 at 2:00 PM < = EMAIL ADDRESS REMOVED = > wrote:
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Weird bug in both JAWS and NVDA (maybe) (Steve Green)
> 2. Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
>
>
>
> ---------- Forwarded message ----------
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Fri, 1 Aug 2025 17:49:15 +0000
> Subject: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Fri, 1 Aug 2025 17:55:56 +0000
> Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
> It's worth mentioning that the heading also does not appear in JAWS'
> Headings List and cannot be found using the screen reader's H or 3
> shortcuts.
>
> Steve
>
From: Sailesh Panchang
Date: Aug 1, 2025 1:46PM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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
>
>