E-mail List Archives
Thread: Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
Number of posts in this thread: 16 (In chronological order)
From: Benjamin.Hofer
Date: Wed, Jan 27 2021 2:33AM
Subject: Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
No previous message | Next message →
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
From: Patrick H. Lauke
Date: Wed, Jan 27 2021 3:38AM
Subject: Re: Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
On 27/01/2021 09:33, = EMAIL ADDRESS REMOVED = wrote:
> 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?
That wiki resource seems slightly out of date (still references OAA
which has been defunct for ages). I'd recommend reviewing the examples
from ARIA Practices https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView
(and just to clarify, when you say "copy the code example in a plain
HTML file" ... of course, to actually work, you need more than just the
HTML - you need actual JavaScript to implement the whole interaction of
a tree view, expose/change the open/closed tree branches, etc ... it's
not sufficient to just grab the HTML itself)
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Benjamin.Hofer
Date: Wed, Jan 27 2021 3:52AM
Subject: Re: Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
Hi Patrick,
thanks for coming back on this.
> (and just to clarify, when you say "copy the code example in a plain HTML file" ... of course, to actually work, you need more than just the HTML - you need actual JavaScript to implement the whole interaction of a tree view, expose/change the open/closed tree branches, etc ... it's not sufficient to just grab the HTML itself)
Of course, this is not enough to implement the whole tree so that the user can interact with it. It was only for testing if the screenreader is generally able to navigate such a tree; and we found that only the first element is accessible which was also the case with fully implemented trees like in Angular components.
We'll check the link.
Best
Ben
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > Im Auftrag von Patrick H. Lauke
Gesendet: Mittwoch, 27. Januar 2021 11:38
An: = EMAIL ADDRESS REMOVED =
Betreff: Re: [WebAIM] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
On 27/01/2021 09:33, = EMAIL ADDRESS REMOVED = wrote:
> 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?
That wiki resource seems slightly out of date (still references OAA which has been defunct for ages). I'd recommend reviewing the examples from ARIA Practices https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView
(and just to clarify, when you say "copy the code example in a plain HTML file" ... of course, to actually work, you need more than just the HTML - you need actual JavaScript to implement the whole interaction of a tree view, expose/change the open/closed tree branches, etc ... it's not sufficient to just grab the HTML itself)
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Mark Magennis
Date: Wed, Jan 27 2021 4:05AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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?
From: Jonathan C. Cohn
Date: Wed, Jan 27 2021 6:04AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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 ADDRESS 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?
>
>
From:
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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 ADDRESS 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?
>>
>>
From: Benjamin.Hofer
Date: Wed, Jan 27 2021 7:52AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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 ADDRESS REMOVED = > Im Auftrag von Léonie Watson
Gesendet: Mittwoch, 27. Januar 2021 14:42
An: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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?
>>
>>
From: Mark Magennis
Date: Wed, Jan 27 2021 8:25AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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
From: Jonathan Cohn
Date: Wed, Jan 27 2021 8:50AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
Hello,
Thinking about this a little more, Touch Navigation mode in JAWS or Object Navigation mode in NVDA should be able to view the individual elements of the tree. I believe however, that few Screen Reader users know how to use these modes.
To enable Touch mode in JAWs press shift with numpad plus. Object Navigation mode in NVDA is just using numpad arrow keys and the insert/zero numpad key.
Best wishes,
Jonathan Cohn
> On Jan 27, 2021, at 10:25, Mark Magennis < = EMAIL ADDRESS REMOVED = > wrote:
>
> 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
>
>
From: Benjamin.Hofer
Date: Wed, Jan 27 2021 9:17AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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 ADDRESS REMOVED = > Im Auftrag von Mark Magennis
Gesendet: Mittwoch, 27. Januar 2021 16:25
An: WebAIM Discussion List < = EMAIL ADDRESS 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
From: Patrick H. Lauke
Date: Wed, Jan 27 2021 9:20AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
On 27/01/2021 16:17, = EMAIL ADDRESS REMOVED = wrote:
> 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.
Just picking up on the last point - making it dependent on Javascript
developers. That's pretty much inevitable, since there is no actual
native tree widget HTML element with built-in behaviour. So, to mimic
this non-standard (for the web/HTML) concept, you simply can't get
around relying on custom Javascript to handle all interactions, focus
handling, keyboard support, etc.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Peter Krautzberger
Date: Wed, Jan 27 2021 9:24AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = > Im Auftrag von
> Mark Magennis
> Gesendet: Mittwoch, 27. Januar 2021 16:25
> An: WebAIM Discussion List < = EMAIL ADDRESS 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
>
>
From: glen walker
Date: Wed, Jan 27 2021 9:32AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
Yes, I was thinking the same thing, Peter, but the example on
https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-2/treeview-2a.html
has all three top level tree items in the DOM. The child elements have
display:none. So I expected to be able to navigate to "Vegetables" and
"Grains". They're in the DOM and accessibility tree. But even navigating
character by character (right arrow in NVDA), it only walks through 'F',
'r', 'u', 'i', 't', 's' and then goes to the 'A' in "Accessibility
Features" in the heading following the tree.
On Wed, Jan 27, 2021 at 9:24 AM Peter Krautzberger < = EMAIL ADDRESS REMOVED = >
wrote:
>
> 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.
>
>
From: Jonathan Avila
Date: Wed, Jan 27 2021 11:04AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
> has all three top level tree items in the DOM. The child elements have display:none. So I expected to be able to navigate to "Vegetables" and "Grains". They're in the DOM and accessibility tree.
It's pretty standard for Windows screen readers that they only show the accessible name and role of the tree and the selected item to users in browse mode and do not show other top level items even if they are visible. This is very similar to how a standard select with multiple visible items work in HTML with a Windows screen reader - you don't have access to the other visible items in the list - only the list itself and the selected item.
Jonathan
From: Jonathan Avila
Date: Wed, Jan 27 2021 11:10AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | Next message →
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
From: Brooks Newton
Date: Wed, Jan 27 2021 11:37AM
Subject: Re: [EXTERNAL] Accessibility: ARIA trees obviously not accessible with NVDa/JAWS screenreader and Firefox/Chrome on Windows
← Previous message | No next message
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 ADDRESS 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
>
>