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: Brooks Newton
Date: Jan 27, 2021 11:37AM

I have four questions related to the tree view widget and other common
widgets not currently supported through semantically meaningful HTML markup:

- Is it the W3C or WHATWG that is in charge of determining when new
widget markup is added to the HTML specification?
- How long does a widget have to be used in the wild before a standards
body is required to create markup that supports easy accessible
implementations of such widgets?
- Are user agent manufacturers, authoring tool manufacturers and
assistive technology manufacturers required to adopt new HTML markup
standards so that the new widget markup implemented by content authors will
work for users?
- How are individual site owners and content authors supposed to keep up
with the business need for implementing new accessible widgets without
strong support from standards bodies, user agent manufacturers, assistive
technology manufacturers and authoring tools manufacturers?


Thanks,

Brooks Newton

On Wed, Jan 27, 2021 at 12:10 PM Jonathan Avila < <EMAIL REMOVED> >
wrote:

> One reason why trees and other widgets may not be navigable with browse
> mode is that they require knowing the focused element. In browse mode JAWS
> and NVDA (no longer) sets focus to the elements on navigation with arrow
> keys. Focus setting would need to occur - but this has potential side
> effects that would need to be handled. It's likely something that could
> be addressed but my guess is that it's tricky.
>
> Jonathan
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> <EMAIL REMOVED>
> Sent: Wednesday, January 27, 2021 9:52 AM
> To: <EMAIL REMOVED>
> Subject: Re: [WebAIM] [EXTERNAL] Accessibility: ARIA trees obviously not
> accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> 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
> > > > > >