WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relationship between WCAG and the ARIA in HTMLspecification

for

From: Steve Green
Date: Aug 8, 2023 7:44AM

It sounds like you are basing your comments on screen reader behaviour rather than the accessibility tree. That's not wrong, but it's important to specify the method because it has a profound effect on the results.

I just tested a button inside a link using the following code:

<p><a href="#">Home</a></p>
<p>Test code</p>
<a href="#">Foo<span role="button" tabindex="0 ">Bar</span></a>
<p>End of test code</p>

The accessibility tree looks the same in Chrome and Firefox insofar as the link and button roles are conveyed correctly. The link's accessible name is the concatenation of the link and button labels, so I can report this as a non-conformance of WCAG SC 4.1.2. It sounds like a trivial issue, but the effect on JAWS and NVDA is extraordinary - they don't seem to be taking any notice of the accessibility tree.

JAWS 2021 gives the following behaviours with Chrome and Firefox:
In virtual cursor mode the word "Foo" just appears to be text, not a link.
When tabbing, the "Foo" link is announced as the previously focusable element i.e. neither its name nor role is announced. In my test page it is announced as "Home link" when tabbing forwards and as "Bar button" when tabbing backwards.
When tabbing forwards, the "Bar" button is correctly announced as "Bar button". But tabbing backwards, it is announced as "FooBar link Bar button".
In both cases, the "Bar" button is announced correctly.

With NVDA 2021 (with Screen Layout turned off), I get the following with Chrome and Firefox:
In virtual cursor mode the "Foo" link is announced as "Link Foo". The "Bar" button is announced as "Link button Bar".
When tabbing forwards, the "Foo" link is announced as "Foo Bar link". The "Bar" button is announced as "Bar button link".
When tabbing backwards, the "Foo" link is a silent tab stop. The "Bar" button is announced as "Bar button link".

Steve