E-mail List Archives
Number of posts in this thread: 20 (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 | 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
>
>
From: Steve Green
Date: Aug 4, 2025 7:59AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
I'm obviously familiar with the accessible name computation, and that the "aria-label" attribute overrides all the content in the link, but I don't understand why the heading role is not conveyed. The "aria-label" attribute doesn't override roles. If it's supposed to, why is the heading role still exposed in the accessibility tree?
I just checked using Voiceover on macOS and verified that it does indeed announce both the heading and link. If you're correct (and I am not convinced you are) it means the fault is in Safari and/or VoiceOver.
Since the thread has been trimmed, here's a reminder of the code:
<a href="#" aria-label="foo">
<h3>bar</h3>
</a>
The HTML specification allows heading elements to be contained in links, and I can't find anything in the ARIA specification that says the "aria-label" attribute overrides the roles of child elements.
Steve
From: Steve Green
Date: Aug 4, 2025 8:01AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
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 ADDRESS REMOVED = >
Sent: 01 August 2025 20:47
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Steve Green < = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = 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
From: Steve Green
Date: Aug 4, 2025 8:08AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
Thanks, Christine. What you are saying is true of HTML4 and XHTML 1.x, but HTML5 allows heading elements to be children of links. As you say, it's much more flexible, to the point of allowing almost any element to contain almost any other element.
The whole rationale for dropping SC 4.1.1 was that there is now a specification that tells browsers how to create the DOM when elements are nested incorrectly, but they are not nested incorrectly in this case. Given that this specification exists and browsers should apply it when the HTML5 doctype is specified, it is all the stranger that JAWS and NVDA behave differently from VoiceOver.
Steve
From: Steve Green
Date: Aug 4, 2025 8:52AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
Here's another test that clearly shows something is wrong somewhere. I replaced the link element with a button, and JAWS now does announce the heading, but it ignores the "aria-label" attribute. You would expect it to behave the same as before, but it doesn't. It announces the following code as "heading level three button bar".
<button aria-label="foo">
<h3>bar</h3>
</button>
NVDA reads this as "button foo", so it is acknowledging the "aria-label" attribute and ignoring the heading, as it did with the link.
As before, Chrome's accessibility tree shows the button's name as "foo". The heading has a role of "h3" and contents of "bar".
Steve
From: Sailesh Panchang
Date: Aug 4, 2025 10:49AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
Steve,
The entire content of the anchor element or button should be ignored as
per my understanding and JAWS does that for the link but is apparently
failing to do that for a button as you reported.
So the role of the content within the element is immaterial if it is meant
to be ignored.
And in such situations the deprecated SC 4.1.1 would probably play a
role: flag improper nesting of elements.
Thanks,
Sailesh
Sailesh Panchang
Email: = EMAIL ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Mon, Aug 4, 2025 at 10:52 AM Steve Green via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> Here's another test that clearly shows something is wrong somewhere. I
> replaced the link element with a button, and JAWS now does announce the
> heading, but it ignores the "aria-label" attribute. You would expect it to
> behave the same as before, but it doesn't. It announces the following code
> as "heading level three button bar".
>
> <button aria-label="foo">
> <h3>bar</h3>
> </button>
>
> NVDA reads this as "button foo", so it is acknowledging the "aria-label"
> attribute and ignoring the heading, as it did with the link.
>
> As before, Chrome's accessibility tree shows the button's name as "foo".
> The heading has a role of "h3" and contents of "bar".
>
> Steve
>
From: Laura Fathauer
Date: Aug 4, 2025 1:29PM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
I'm not surprised that you see differences in the way Voiceover/Safari's
accessibility tree handles cases like this vs how Chrome's accessibility
tree is read by Jaws and NVDA. Looking at Safari's accessibility info for
the example, it does show the enclosed heading element is "ignored: Yes
(default)".
The coding change to get better consistency across all screen
reader/browser combinations would be to move the H3 outside of the button
element, or remove the aria-label from the button.
Note that the WAI-ARIA spec indicates that button elements have a
characteristic "Children Presentational: True
<https://www.w3.org/TR/wai-aria/#tree_exclusion>", and its recommendation
is that enclosed elements "should not" be exposed in the accessibility tree
(with some exclusions).
Laura
On Mon, Aug 4, 2025 at 10:14 AM Steve Green via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> Thanks, Christine. What you are saying is true of HTML4 and XHTML 1.x, but
> HTML5 allows heading elements to be children of links. As you say, it's
> much more flexible, to the point of allowing almost any element to contain
> almost any other element.
>
> The whole rationale for dropping SC 4.1.1 was that there is now a
> specification that tells browsers how to create the DOM when elements are
> nested incorrectly, but they are not nested incorrectly in this case.
> Given that this specification exists and browsers should apply it when the
> HTML5 doctype is specified, it is all the stranger that JAWS and NVDA
> behave differently from VoiceOver.
>
> Steve
>
From: Steve Green
Date: Aug 5, 2025 3:17AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe)
← Previous message | Next message →
I can’t find any specification that says the entire child element should be ignored when a parent element has an “aria-label” attribute. Can you point to such a specification? The accessible name computation says that the “aria-label” attribute takes precedence over the contents in terms of computing the parent element’s accessible name, but it does not say that the children should be completely ignored. If that was the case, an entire group of elements would be hidden if they had a parent element with role=”group” and an “aria-label” attribute. Obviously, this does not happen.
In terms of SC 4.1.1, the nesting is not improper under HTML5 and it passes the W3C HTML Nu validator. It also passes the tests done by the Axe and ARC Toolkit browser extensions.
Steve
From: Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
Sent: 04 August 2025 17:50
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Steve Green < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Weird bug in both JAWS and NVDA (maybe)
Steve,
The entire content of the anchor element or button should be ignored as per my understanding and JAWS does that for the link but is apparently failing to do that for a button as you reported.
So the role of the content within the element is immaterial if it is meant to be ignored.
And in such situations the deprecated SC 4.1.1 would probably play a role: flag improper nesting of elements.
Thanks,
Sailesh
Sailesh Panchang
Email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
Deque Systems Inc | - Accessibility for Good | www.deque.com<;http://www.deque.com>;
On Mon, Aug 4, 2025 at 10:52 AM Steve Green via WebAIM-Forum < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
Here's another test that clearly shows something is wrong somewhere. I replaced the link element with a button, and JAWS now does announce the heading, but it ignores the "aria-label" attribute. You would expect it to behave the same as before, but it doesn't. It announces the following code as "heading level three button bar".
<button aria-label="foo">
<h3>bar</h3>
</button>
NVDA reads this as "button foo", so it is acknowledging the "aria-label" attribute and ignoring the heading, as it did with the link.
As before, Chrome's accessibility tree shows the button's name as "foo". The heading has a role of "h3" and contents of "bar".
Steve
From: Steve Green
Date: Aug 5, 2025 4:04AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Aug 5, 2025 4:54AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
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 ADDRESS 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
>
From: Steve Green
Date: Aug 5, 2025 5:23AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
Thanks, Birkir. In Chrome, the link's accessible name is the "aria-label" as you would expect. The heading is exposed in the accessibility tree, and its name comes from its contents, as you would expect. But JAWS and NVDA don't announce the heading, so it looks like they are making that decision for reasons I don't understand.
I haven't reversed the elements. We know that both the link and heading would be announced because lot of accordions and disclosure elements are designed that way as long as the "aria-label" attribute is not put on the heading. One of the many things that annoys me is that the "aria-label" attribute isn't even needed on this website.
Steve
From: Sailesh Panchang
Date: Aug 5, 2025 7:02AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
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 ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Tue, Aug 5, 2025 at 6:04 AM Steve Green via WebAIM-Forum <
= EMAIL ADDRESS 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
>
From: Steve Green
Date: Aug 5, 2025 7:31AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
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 ADDRESS REMOVED = >
Sent: 05 August 2025 14:03
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Steve Green < = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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
From: Christine Hogenkamp
Date: Aug 5, 2025 7:53AM
Subject: Re: Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | Next message →
Hi Steve,
I agree with what you've said, for me as a web developer who deals in using
HTML for creating custom emails, I can only think of what I will refer to
as "the Outlook problem" - basically some programs, especially older ones,
do not follow the most recent versions of HTML or even convert standard
HTML to their own version of HTML which can cause all kinds of weird
behavior. In Outlook's case, it turns div tags into paragraph tags, which
can wreak havoc with an email's formatting if you use div tags for
creating a layout for an email, instead of using a table. You may exclaim
"But tables are an outdated way to create containers and layout, compared
to divs, which are much more flexible and adjustable, etc!" and that's
true, but the reality is that if you want an email to have a certain layout
look for Outlook, you gotta use a table ha ha!
It may be that some part of JAWS or NVDA hasn't been updated to be more
HTML5 compatible, or something similar. Since VoiceOver is part of the
MacOS, it makes sense that it might get updated along with the rest of the
OS when Apple is creating a new OS. Generally for these types of issues, if
you find coding the older way does work as intended for JAWS/NVDA, then you
have to decide what you want to prioritize: more "backwards compatibility"
or is the effect you want to achieve more important AND only achievable by
having a link tag around a header tag. Generally I tend to prioritize the
broadest compatibility but I understand that can be sometimes difficult to
reconcile with client requests/expectations/etc.
*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer & Accessibility Lead
Context Creative – a Mod Op company
416.972.1439 | contextcreative.com
On Mon, Aug 4, 2025 at 10:08 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:
> Thanks, Christine. What you are saying is true of HTML4 and XHTML 1.x, but
> HTML5 allows heading elements to be children of links. As you say, it's
> much more flexible, to the point of allowing almost any element to contain
> almost any other element.
>
> The whole rationale for dropping SC 4.1.1 was that there is now a
> specification that tells browsers how to create the DOM when elements are
> nested incorrectly, but they are not nested incorrectly in this case.
> Given that this specification exists and browsers should apply it when the
> HTML5 doctype is specified, it is all the stranger that JAWS and NVDA
> behave differently from VoiceOver.
>
> Steve
>
From: Patrick H. Lauke
Date: Aug 5, 2025 8:37AM
Subject: Re: {Spam?}Weird bug in both JAWS and NVDA (maybe) (Steve Green)
← Previous message | No next message
On 05/08/2025 14:31, Steve Green via WebAIM-Forum wrote:
> 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
Maybe not necessarily that "it must", but rather ... specs are currently
vague/silent about the scenario. The ARIA spec does not explicitly
mention that once an aria-label or aria-labelledby has been used to
effectively overwrite the content of an element with a particular role,
the child elements within it are essentially ignored. Because of this
vagueness/ambiguity, there are diverging implementations in practice of
how AT handle this.
>, but JAWS and NVDA violate that. I will report bugs against both of them.
See existing things like https://github.com/nvaccess/nvda/issues/13296
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke