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: Peter Krautzberger
Date: Jan 27, 2021 9:24AM

Hi Benjamin

> But why can't modern browsers / screenreaders deal with trees, menus and
other role elements like with any other, more traditional, elements? I see
that it's a lot more convenient to navigate a tree by arrow keys if it's
implemented in a correct way.

One reason I can think of is that trees might not have all their children
present in the DOM - e.g., in a cloud storage system, a folder view tree
might fetch the subdirectory structure asynchronously.

Slightly related: the ARIA Working Group has had a couple of deep-dive
meetings in recent months about trees, cf.
https://github.com/w3c/aria/issues/1311

Best regards,
Peter Krautzberger.

Am Mi., 27. Jan. 2021 um 17:17 Uhr schrieb < <EMAIL REMOVED> >:

> Yes, Mark, that's what I think. Technically, I'm not deep enough to know
> exactly how browser/screenreader interaction exactly works (an article
> about that would be quite interesting). But why can't modern browsers /
> screenreaders deal with trees, menus and other role elements like with any
> other, more traditional, elements? I see that it's a lot more convenient to
> navigate a tree by arrow keys if it's implemented in a correct way. But I
> can't see a technical reason why information isn't passed correctly to the
> screenreader when using the virtual mode(which many normal users without
> technical background do). And, the most important apect: It very much
> depends on the Javascript developer how navigating such elements actually
> works!!
> I think that would be worth passing to accessibility API teams if anyone's
> here being able to do that.
>
> Ben
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von
> Mark Magennis
> Gesendet: Mittwoch, 27. Januar 2021 16:25
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] [EXTERNAL] Accessibility: ARIA trees obviously not
> accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
>
> It seems a bit strange to me too Ben but it's not confined to treeviews.
> Take a menu for example. Jaws enters forms mode in a menu (role="menu"). I
> would have expected that if I exit forms mode by pressing numpad + while
> still in the menu Jaws, now in virtual mode, would respond to the down
> arrow by reading the next element instead of traversing the menu. But
> instead, it traverses the menu, wrapping if that's the behaviour the menu
> scripting implements. So it seems that while you are inside a menu, Jaws
> passes key presses to the browser no matter what and you can't stop that.
> Which makes me wonder why it needed to enter forms mode in the first place.
>
> Mark
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> <EMAIL REMOVED>
> Sent: 27 January 2021 14:52
> To: <EMAIL REMOVED>
> Subject: Re: [WebAIM] [EXTERNAL] Accessibility: ARIA trees obviously not
> accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
>
> Hello Léonie and others,
> thank you for your further replies and clarifications. That has helped us
> very much understanding the whole topic. Being a screenreader user and IT
> professional myself, I'm very aware of the different modes a screenreader
> knows and how to handle them. What I was not aware of, though, is that a
> tree isn't navigatable using the screenreaders virtual / browse mode which
> is normally used to navigate the web. That behaviour is still a bit strange
> for me: When browse mode / virtual mode is activated by the user, why isn't
> the screenreader able to get at least the information about all nodes of
> the tree and navigate it in browse/virtual mode? For default elements like
> a form are also navigatable both ways. And if the keyboard navigation of a
> tree (in this example) works or not highly depends on the JavaScript
> developer which isn't desirable in my view. Implementing this is definitely
> possible, but doing it right seems quite a bit of effort for the JS
> developer (OK, there are samples, but not everyone keeps up and actually
> implements it) and it's very confusing at the first glance.
> So this should be solved by browser/screenreader interaction rather than
> the Javascript developer...
>
> Thanks
> Ben
>
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum < <EMAIL REMOVED> > Im Auftrag von
> Léonie Watson
> Gesendet: Mittwoch, 27. Januar 2021 14:42
> An: WebAIM Discussion List < <EMAIL REMOVED> >
> Betreff: Re: [WebAIM] [EXTERNAL] Accessibility: ARIA trees obviously not
> accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
>
> The behaviour reported by Benjamin is expected.
>
> The expected keyboard interaction for a tree is to use the arrow keys
> (left/right/up/down) to navigate it. This interaction has to be provided
> using JavaScript.
>
> Ordinarily Windows screen readers use the arrow keys for the purposes of
> reading content; left reads the previous character, right reads the next,
> and so on.
>
> So there is a conflict. The screen reader wants the arrow keys to do one
> thing and the JavaScript wants them to do another.
>
> Certain ARIA roles (like tree, grid, tablist and progressbar) resolve the
> conflict by telling the screen reader to stop intercepting the keys and let
> the JavaScript do its thing instead.
>
> It's the same thing that happens with form fields. Ordinarily screen
> readers use most letter keys for the purposes of navigating through
> content; h for headings, t for tables, and so on. When the screen reader
> focuses on an edit field it stops intercepting keystrokes so they revert to
> their original purpose of typing characters.
>
> So in the case of an ARIA tree with the appropriate JavaScript to provide
> the expected keyboard interaction, tabbing onto the tree should cause the
> screen reader to stop trying to use the arrow keys so that the JavaScript
> can use them instead.
>
> It is worth noting that when any of these roles is used they stop the
> screen reader from intercepting and using *any keys except for a few like
> tab, space, and enter. This means that the JavaScript needs to handle all
> the expected keyboard interactions.
>
> It's also worth mentioning that sometimes screen readers fail to switch
> modes automatically. Usually pressing enter when focus is on the tree (or
> other interactive component) will do the trick.
>
>
> More on this general topic here:
> https://tink.uk/understanding-screen-reader-interaction-modes/
>
> Léonie.
>
>
> On 27/01/2021 13:04, Jonathan C. Cohn wrote:
> > 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?
> >>
> >> -----Original Message-----
> >> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf
> >> Of <EMAIL REMOVED>
> >> Sent: 27 January 2021 09:34
> >> To: <EMAIL REMOVED>
> >> Subject: [EXTERNAL] [WebAIM] Accessibility: ARIA trees obviously not
> >> accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
> >>
> >> Hello WebAIM Community,
> >> I'm new in this list and hope you can give advice on that specific
> question.
> >> We've basically implemented an ARIA tree in the way W3C recommends,
> >> please see cocde example in this link:
> >> https://www.w3.org/WAI/GL/wiki/Using_ARIA_trees
> >>
> >> Many samples and templates (e.g. official ones from Angular) are based
> on these recommendations.
> >> If you copy the code example (see link above) in a plain HTML file and
> open it with Firefox and Chrome, screenreaders can only access the first
> tree element (in this example "Fruits") and its child elements. Other
> elements at the first level are not accessible in the virtual mode of
> screenreaders.
> >> This was tested using NVDA and JAWS screenreaders as well as Firefox
> and Chrome browsers.
> >> Is this a known issue? Does t depend on specific product versions
> (screenreaders, browsers)?
> >> Did anyone manage to solve the problem?
> >>
> >> Best,
> >> Benjamin
> >>
> >> Benjamin Hofer | Deutsche Telekom
> >>
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
> --
> Director @TetraLogical
> https://tetralogical.com/
> > > at http://webaim.org/discussion/archives
> > > > at http://webaim.org/discussion/archives
> > > > at http://webaim.org/discussion/archives
> > > > > >