WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows

for

From: Jonathan C. Cohn
Date: Jan 27, 2021 6:04AM

Ok, in non auto forms mode JAWS will read the selected or first element when it encounters a tree in VPC. When one switchs into forms mode by pressing space, navigation is then handled by the JAVASCRIPT on the page. But you stated you were not working with JS so navigation would be impossible there too.
When you mark a element as treeview the screen reader sees it as one widget,. often developers will use a list of buttons or links with ariaexpanded and no role sence this works without JS and can be navigated in Virtual screen reader modes.


Sent from my iPhone

> On Jan 27, 2021, at 6:05 AM, Mark Magennis < <EMAIL REMOVED> > wrote:
>
> Hi Benjamin,
>
> I have an idea that this may be to do with the screen reader expecting you to be in forms/focus mode in order to access the tree content. As you know, Aria treeviews are intended to implement a keyboard interaction pattern which is coded using Javascript. Screen readers Jaws and NVDA know this. So when you tab into the treeview (assuming the first element is focusable the screen reader automatically switches into forms mode (Jaws) or focus mode (NVDA term for the same thing).
>
> My conjecture: When you arrow into the treeview the screen reader doesn't enter forms/ focus mode, but I'm guessing that it expects you to manually enter forms/focus mode if you want to interact with it and doesn't support interacting with it 'correctly' in browse mode.
>
> So the screen reader is making a decision not to allow access to the tree content in browse mode.
>
> Anyone think this is correct/wildly wrong?
>
>