JAWS Latest NVDA Orca screen readers VoiceOver WAI-ARIA widgets Window-Eyes

(Not so) Simple ARIA tree views and screen readers Articles

I started testing numerous screen readers with totally different ARIA tree views. It seems that there’s little to do with screen readers and tree views, so the research is a bit lengthy. It has also turned out that there are appreciable variations between screen readers on how they deal with totally different ARIA tree views. I couldn't discover any solution to construct a easy tree view that gives what I call a wonderfully respectable expertise in at present's fashionable screen readers.

Nevertheless, I’ve tried the check outcomes to develop an strategy which I feel greatest help for present näytönlukija- and browser, though some compromises. This greatest strategy is described under. Pattern tree views and check outcomes will come after you have an interest.

Additionally word that I am not an actual JavaScript or jQuery developer with any stretching, so despite the fact that the script behind the tree view examples works, its construction is definitely pleasant. In different words, you’ll be able to freely use it on your own head, however the mileage might differ.

What’s a tree view?

WAI-ARIA 1.0 Manufacturing Strategies:

Wooden View is a element for you to go to hierarchical lists. It consists of a number of prime degree nodes. The node might have youngsters or it might be a node. Youngsters's knots might be expanded or collapsed – the kid's nodes are visible when expanded. When youngsters have collapsed, they don’t seem to be seen. Often there’s some type of visual indication of whether the node has youngsters and it can be expanded. Any variety of nodes might be expanded at a time and baby nodes can include youngsters.

This kind of navigation element ought to be acquainted. It’s obtainable in some type for viewing and navigating folder and file hierarchies on main operating methods. Additionally it is used in net purposes with file or doc management features.

Though they’re very common, tree views usually are not the only interactive widgets, and guarantee they are out there to screen reader users, which suggests good keyboard and focus help, in addition to details about tree structure and status. Luckily, ARIA presents numerous roles and features that can be utilized to accomplish this.

Roles and Options of the ARIA Tree View

Primary views use the next ARIA attributes:

In addition to Position = "Presentation" and international attributes similar to Aria label and Aria-Labeled, there are different ARIA attributes that can be used in response to the complexity or function of the tree view. These embrace Aria-activated, Aria-level, Aria-owned, Aria-setsize, and Aria-posinset.

Keyboard Focus and Interaction

The WAI-ARIA 1.zero manufacturing policies for tree views describe keyboard instructions that must be made obtainable to customers to allow them to work together with the tree view. For the essential navigation of the tree view, the next arrow key behaviors are outlined:

  • Arrow up and arrow to maneuver focus between visible nodes
  • Left arrow in open node closes node.
  • Left Arrow
  • Right Arrow Expands Closed Node, Strikes to First Node of Open Node, or Does Nothing.

In a standard tree view, only one node must be in the Tab order and be centralized at a time. This is sometimes carried out by managing the tabindex attributes of the tree targets. The worth "-1" deletes the component from the Tab order, while the worth "0" provides it (if it isn’t naturally refined). As such, only the at present focused tree node ought to have tabindex = "0". All others ought to have tabindex = "- 1". When the main target moves to another node, tabindex values ​​are updated accordingly. We will discuss with this roaming tab index strategy as a result of tabindex = "0" passes around the tree view with a specified node.

The second strategy used on this proposed greatest strategy consists of specializing in the wooden packaging itself. Each node is stored outdoors the Tab order. With a purpose to monitor which node is lively, the Aria activedescendant is positioned in a picket container and dynamically up to date with a reference to the at present refined node identifier.

Anticipated Ultimate Screen Reader Operation

Totally different browsers in several browsers present totally different operating models with ARIA tree views. If we take a look at all of these behaviors along with software roles and ARIA statements, I might recommend that the perfect display reader conduct with tree views should embrace: (see related article
ARIA Widgets and Focus / Varieties Mode Help in JAWS and NVDA)

  • recognizes the widget as a tree view or comparable when specializing in a tree;
  • acknowledges the expanded / collapsed state of the node when it receives the main target or is
  • indicating the level of the branch of the present node when it receives the main target,
  • indicates the number of sister nodes at the current branch degree and the situation of the present node when receiving the main target (e.g. signifies something like "two out of four"),
  • denotes the variety of baby nodes when the expanded node will get the main target (for instance, indicating one thing in "three places").
  • Of the 5 screen readers tested, each showed at the very least a number of of these behaviors in 4 examples and in some instances virtually all of them

    What’s the greatest strategy?

    The Greatest Strategy Instance

    The subsequent tree view is about testing and is described under. In case you have ideas on how one can enhance it or the best way to better deal with a few of the flaws that sure screen reader and browser mixtures include with easy ARIA tree views, share it.

    This tree view works on all screen readers and browser mixtures. Perhaps the most important drawback, as proven under, is that the expertise skilled while navigating the tree with JAWS, NVDA and Window-Eyes in Web Explorer is an issue I haven't found a perfect answer that doesn't cause more critical issues on the similar time different screen readers, especially VoiceOver.

    Primary Construction

    Tree views are a option to navigate hierarchical lists, so based on good semantic style, utilizing the tree infrastructure record entry might be probably the most applicable. Some tree views use div and span parts that work nicely so long as ARIA and JavaScript are supported. If not, the consumer is left with only numerous nested div and span parts that are not helpful.

    In this proposed greatest strategy, the tree view uses a non-organized listing and every record has a nested hyperlink. Listing gadgets have a task = "treeitem" and execute Aria-selected, Aria-level and Aria-expanded if they have youngsters. The nested hyperlink for every item within the listing is about to "play" and tabindex = "- 1". All these attributes are added utilizing JavaScript as a result of the performance of the tree view is determined by the controls on the scripted arrow keys.

    Nested links might be just as properly replaced with nested bands if a specific tree view doesn’t have to use hyperlinks. With this greatest follow instance, there isn’t a difference in conduct in any screen reader apart from the relatively small improve in verbality in Window-Eyes with nested links compared to lengths.

    The hierarchical construction of the tree and the connection between the child aspect and the nodes and their mother and father are thus represented within the construction of the DOM. In different phrases, youngster node lists are an inventory structure for child-knots. If the nested links have been nodes, each baby node listing can be a sibling as an alternative of a mum or dad node hyperlink to its youngster. In any case, this doesn’t seem to matter to the JAWS, NVDA, or ORCA, who are doing properly to record the kid nodes or siblings of the kid nodes in the DOM hierarchy. Window-Eyes doesn’t think about nested transmissions as nodes, however doesn’t work nicely with nested links. And VoiceOver doesn't like nested links as nodes at all.

    Wood uses Aria activedescendant (to help VoiceOver). Focus strikes and stays on the tree listing itself. It does not move via the tree nodes. As an alternative, use the arrow keys to pick a node or to broaden / scale back the node by updating the chosen and Aria-extended attributes of the nodes as needed and the Aria activedescendant attribute within the tree listing. Pressing the Enter or Area button units the situation to the nested link href whose ID is referenced by Aria activedescendant.

    Each baby node listing has a task = "group" that signifies that the gadgets it incorporates represent a separate collection of nodes in the tree hierarchy of the father or mother node. While youngster node lists are in the record of child-older nodes, this leads to issues in how Web Explorer calculates the identify utilized by the mother or father node. For more details about Web Explorer and the names which might be disabled, see. A part of the problematic conduct in IE is mitigated by putting the Aria-labelledby root on the u to seek advice from its earlier title. The remaining can simply be solved through the use of Aria-Labeledby, if you wish to set the desired label for every node listing, however this causes critical issues for VoiceOver in Safari. This means that when VoiceOver helps the tabindex strategy to roaming and can determine the variety of youngsters in each node regardless of the DOM construction, making knotted links from nodes might be an inexpensive strategy

    On account of a very good DOM structure and to stop VoiceOver from presenting false information about youngster node protection, right here the proposed greatest strategy makes use of an inventory of nodes and doesn’t include nested links, although this makes things a bit of verbos for IE screen readers.

    Fixing Issues

    VoiceOver / Safari and Aria-activedescendant

    Since Safari's VoiceOver at present only supports real tree views that use Aria activedescendant as an alternative of roaming tab index and DOM structure, which reflects the relationships between the node and baby node, greatest The strategy to the example begins with it. All different approaches merely don't work appropriately with VoiceOver

    If you use the roaming tabindex strategy with VoiceOver, the arrow keys transfer the browser weight node to the node and increase or scale back the nodes, but the VoiceOver cursor does not comply with. The VoiceOver cursor is subsequently not synchronized with the browser cursor. VoiceOver will announce modifications in the node's expanded / compressed state, however it won’t show the at present specified node label (until the VoiceOver cursor can also be in that node).

    It isn’t clear whether this limitation is an issue with VoiceOver or Safari, however Apple has been knowledgeable about it. I think it’s a VoiceOver drawback because of what I can say, Safari transfers the suitable values ​​to the Mac OS X accessibility protocol, regardless that it might be a roaming tabindex strategy

    . -activated strategy works nicely with VoiceOver when utilizing the arrow keys, it doesn't work in any respect with VoiceOver navigation commands (Ctrl + Choice + Arrow Keys). Additionally, the VoiceOver command to open and close the opening and closing clause (Ctrl + Choice +) doesn’t work to broaden / compress the node.

    Thankfully, the other four screen readers examined are properly controlled by the Aria activedescendant strategy

    Internet Explorer and Accessible Names

    Web Explorer creates an easy-to-use identify for some parts which have a task attribute by combining the text of all baby parts. For example, if an inventory pane with a task = "treeitem" has a nested record of 15 baby nodes when setting the main target or choosing that record merchandise, JAWS and NVDA will read the textual content of the item in this record, but from each of the 15 youngster node lists, whether expanded or visible. What's worse is that when the main target moves from outdoors the tree to the tree or tree node, NVDA and Window-Eyes read each particular person node in the entire tree, broaden and appear. This shortly becomes annoying, particularly in a tree with lengthy baby nodes. Attempt the instance in A IE on any of those screen readers and verify it your self.

    In IE, when the newly selected node is in a unique department and a part of the youngsters's record with position = "group", NVDA reads within each node and adds the phrase "grouping". If we take away the position of "role" from the child record, NVDA provides the word "list" as an alternative of "grouping" but nonetheless reads the gadgets within the group listing. If we use the Aria-labelledby in the youngster listing to confer with the dad or mum node label, NVDA makes use of that label as a grouping identify that is a lot less verbose, regardless that this now causes NVDA to current each baby listing labeled as FF in the FF that it didn’t do earlier than. With this answer, the Orca FF behaves in the identical approach that it imports "grouping" as an alternative of "panel" for every youngster listing, using the labeled reference to outline the panel.

    If we transfer one step additional and use the position = "performance" in the youngster record as an alternative of the position = "group", then NVDA won’t read the child group in any respect in IE. Nevertheless, utilizing the position "play" within the youngster record as an alternative of the position = "group" will trigger JAWS in FF to increase the node with youngsters by studying the entry for every visible node in that youngster listing. This might be thought-about as a small improve in vascularity for JAWS in FF, to significantly scale back the viability of NVDA in IE. However, since most NVDA customers will in all probability play with Firefox, and the position = "group" is, I feel, the appropriate ARIA for youngster listings for tree targets, one of the best strategy instance penetrates into position = "group" and applies

    Please word that div and span using the weather as an alternative of the record does not clear up this drawback in how IE calculates the names of the nodes record buildings and how the screen readers convey that the

    ARIA barrier counting rule 2C, IE's conduct appears to be considerably right, despite the fact that I'm unsure its this should embrace the offspring hidden on the screen: not and subsequently shouldn’t be present within the accessibility tree. Nor am I positive that this is the best strategy to wooden factors. I feel this makes extra sense for more discrete interactive parts corresponding to buttons and menu gadgets that are not expected to include nested drivers. Nevertheless, I see a case where wooden supplies akin to regular lists can fairly include a number of controllers. Anyway, with the appropriate conduct or not, it makes a reasonably accurate experience with screen readers in IE

    VoiceOver doesn't like the solution

    To unravel this, the perfect answer can be to be sure that each the primary tree ul and each tree node li use Aria-labeled program to determine the tree and the appropriate identify for every node. In a really perfect world, we might use Aria-labeledby mainly to discuss with the title previous the title, and in each of the nodes of the nodes, Aria-labelledby by referring to the nested link.

    I say "in an ideal world" as a result of Aria-Labeledby (or Aria-label use) nodes for some purpose block VoiceOver from indicating the identify of the selected node. VoiceOver also calls the tree view as an alternative of the table as an alternative of the table as a result of VoiceOver often makes tree views, and I anticipate most VoiceOver customers to be acquainted.

    Utilizing Aria-labelledby on the primary tree, ul, seems to cause no drawback, and has the benefit of stopping NVDA and Window-Eyes from reading each single node in the whole tree when the main target first moves to the tree. Nevertheless, when the identify of each node isn’t listened to when it navigates by way of the tree with VoiceOver, it’s a bit of a circuit breaker, so the most effective proposed strategy doesn’t use Aria-labelledby nodes.

    This can be a major compromise: If you want to get a tree view that works in VoiceOver and other necessary screen readers, JAWS and NVDA users who need to work with Internet Explorer will get a a lot much less nice expertise.

    Some tree views have hyperlinks which might be linked to particular person nodes, whereas others use hyperlinks from nodes themselves. Some timber wouldn’t have any links at all and might exchange them with nested edges. Again, every of those approaches may be made to work in a number of, but not all, screen readers. I have included links to most of nested check examples, as a result of I feel they’re using strategies, and using links causes some issues with some screen readers which are value noting. Hyperlinks also provide a default, naturally refined and useful component, similar to JavaScript not enabled.

    In VoiceOver, if a tree view of Aria activedescendant uses nested hyperlinks as nodes as an alternative, record buildings point out that each youngster node has a zero closed baby node, which is simply invalid. Using Aria ownership, whether it is mixed with Aria-setsize and Aria posinset, doesn’t work to determine VoiceOver's number of baby nodes. Because of this, the proposed greatest strategy retains the gadgets within the record node as an alternative of utilizing nested links as nodes. ". Thus, in the example of the best approach, nested links are assigned a role = "presentation. in mode

    Though position = "performance" in nested hyperlinks will routinely assist JAWS in Firefox to type mode, it can make Window-Eyes a verbose. if the chosen node is a part of the branch of the kid node, the IE eyes in IE reads the labels for all nodes in the baby's department, whether they are visible or not, simply as JAWS and NVDA do in IE. nicely, and not read all the child This is only occurring in Window-Eyes. Whether nested links or throughputs, JAWS and NVDA behave equally within the instance of this greatest strategy in IE. As soon as once more, depending in your use, you might need to go together with nested lanes as an alternative of links.

    Department Degree Numbering

    Within the case of the advanced node branch degree, by default, some screen readers define the basis of the basis node as zero, while others call it the level 1. In JAWS and VoiceOver, the top of the tree is taken into account to be zero. NVDA solely in Firefox and Window-Eyes and Orca maintain the basis node branch at degree 1. In IEDA, NVDA doesn’t present the present page degree of the node.

    You possibly can set the node Aria degree to determine the desired branch degree, although this doesn’t work for all screen readers. For example, setting Aria-level = "1" for first-level nodes will get VoiceOver for both JAWS in IE, but not for Firefox, so that these nodes are at degree 1 as an alternative of zero. This enables for more constant conduct between screen readers and is carried out as greatest steered here.

    Expression of Baby Protection

    Only the JAWS and VoiceOver of IE indicate the number of expanded nodes in the number of youngster nodes. It might be great if this might be dealt with utilizing an Aria posetet with Aria setsize, but these attributes don’t seem to have any effect on any screen reader and browser mixtures the place the variety of youngster nodes isn’t reported

    NVDA and Internet Explorer 10

    In IE10, NVDA's interaction with tree views that use Aria-activedendant seems a bit broken. This appears to be an IE10 drawback as a result of NVDA works as anticipated in IE9. In principle, in IE10, NVDA doesn’t routinely entry the appliance mode when the main target is positioned on the tree node. Automated software mode may be pressured by setting the position = "application" within the tree container, but this doesn’t make the remainder of the tree usable with NVDA in IE10. Though someone manages to get into the appliance area, it isn’t attainable to succeed in all nodes within the tree

    . This is one other vital compromise: A tree view that works on all the screen readers tested doesn’t work with all NVDA usage in IE10. On the similar time, this is in all probability not the worst factor on the earth because most NVDA customers are more likely to work with Firefox.

    all collectively

    Bearing in mind all the issues described above, I’ve tried to propose an strategy for building the tree view, which operate in all fashionable näytönlukija- and browser mixtures, and reduce the dangerous effects of each screen reader to specific behaviors. I’m not very happy with this as a result of it causes unpleasant conduct by IE screen readers to help vital restrictions on handling VoiceOver tree views.

    When you’ve got one other strategy, which do you assume will management these issues higher, or in the event you discover something that I have forgotten, let me know. Both the tree view of the marking of the varied screen readers and browsers treating is so much variation that it isn’t unlikely that I've forgotten something

    precise screen reader testing the conduct of

    reader helps WAI-ARIA in the tree view, I created 4 simple examples. The truth is, I have created many other examples, just making an attempt to rule out potential solutions to a few of the problems found. However I simply embrace the four examples under as they reveal an important points that the proposed greatest strategy is making an attempt to deal with.

    Every instance is an easy, one-choice tree view, in contrast to the multi-selector tree, on the similar time, multiple object might be chosen. In these examples, only one tree object may be selected at a time. Which means the batch of the superior tree can also be recognized through the use of Aria-selected = "true".

    Examples are variations of other pattern tree views discovered on the net, akin to Tree Instance three of iCITA, Hans Hillen's easy-to-use jQuery-ui elements, and an example of James Craig's ARIA tree.

    Screen readers have been tested

    Examples have been tested with the next screen reader and browser mixtures, how nicely they confirmed six preferrred behaviors for the ARIA tree within the above-mentioned views:

    • each JAWS 14 and NVDA 2012.three.1 with Internet Explorer 9 and Firefox 19: Windows 7 and Web Explorer 10 on Home windows 8
    • Window-Eyes 8.1 with Internet Explorer 10 and Firefox 19, Both Windows 8
    • VoiceOver with Safari 6.0.2 for Mac OS X 10.eight.2 (Mountain Lion) and 10.7.5 (Lion)
    • Orca three.four.2 by Firefox 19 on Ubuntu 12.04

    Observe that in the outcome tables for every example, until otherwise said, JAWS conduct in IE: 9 is identical as its conduct in IE10. The identical goes for NVDA in IE9 and IE10.

    Additionally learn the check results for every instance, as they cope with different behavioral patterns and points that aren’t coated in the scoreboard.

    Instance A

    Instance A makes use of a easy unordered record with a task = "tree". Particular person listing gadgets have a task = "treeitem" and have nested span parts. Primary keyboard commands focus the record from the record pane. The listing unit or node with focus is Aria-selected = "true", whereas all other nodes are set to Aria-selected = "false".

    The open or closed state of child nodes is visually displayed as comparatively normal and minus icons loaded as CSS background photographs for a blank div. Aria-Hidden = "true" is enabled although it’s in all probability not essential to ensure that they’re hidden on screen readers. Mouse customers can click on these icons to vary the expanded / collapsed state of the node. Keyboard customers, in fact, use the arrow keys

    When a node with youngsters is expanded, its Aria-extended attribute modifications from "false" to "true", and updating the displayed swap icon takes place from the plus signal to a minus signal that displays the node standing. The position = "group" previously hidden on screen: none is about to point out: block. Using the Aria Hidden Use just isn’t required as a screen: nothing permits you to cover content for all users and assistive applied sciences.

    This mannequin of updating the related attributes of node and youngster nodes groups happens kind of in the same

    Here is an example of Instance A:

    • Flora

      • Timber

        • Maple

    Check Outcomes for Example A

    Screen Reader Help for Wood View Instance A

    Screen Reader / Browser Enters Focus Mode Detects Tree View or Comparable Detects Extended or Collapsed Mode of Node Indicates Node Department Degree Signifies node location amongst sibling nodes ] Indicates youngsters of expanded nodes
    in JAWS IE9 / 10 Sure Yes, but only in searching mode Yes Yes Yes, however solely collapsed or ended node [[] 19659112] Sure [19659115] JAWS in FF19 Yes Yes, however only in shopping mode Sure Yes Yes No
    NVDA in IE9 / 10 Yes Yes Sure Sure No No No
    NVDA in FF19 Yes Sure Sure Sure Yes Yes Yes [1965912] No
    Window-Eyes in IE 10 Yes Yes Yes Yes Sure No
    Window-Eyes in FF19 Sure Sure 19659112] Sure Yes yes Sure No
    VoiceOver in Safari 6.0.2 N / A Desk No No No No
    Orca in FF19 [19659152] N / A Yes Sure Yes No No

    End result Notes to Example A

    JAWS and Example A
    • Each in IE and FF Getting into the Tree View JAWS offers interplay instructions: "Use the arrow keys to move or expand items." This conduct is widespread to JAWS in all the examples introduced right here
    • Only in IE, when focusing or increasing / shrinking the node with youngsters, JAWS reads each baby node whether or not it’s expanded and seen or not. That is fairly and annoying, and it is related to an fascinating mixture that IE does with a number of the position attributes of the attributes set by the attribute. The out there identify for li with a task = "treeitem" becomes a string containing text for each baby component, including nested baby lists which might be hidden on the screen: nothing.
    • Reading ARIA's Unrestricted Names Calculation Rule 2C, IE's conduct appears to be right, though I’m not positive it ought to be included that calculates descendants which are hidden by means of the screen: nothing, and subsequently should not be within the accessibility tree
    NVDA and Example A
    • Once you concentrate on any of the nodes within the IE tree, NVDA reads every node within the tree, expanded and displayed, or not. Jälleen, aria-labelledby: n käyttäminen pääpuiden luettelossa ratkaisee tämän.
    • Kun tarkennus muuttuu haaraan ja siirretään solmuun listassa, jossa on rooli = "ryhmä", se lukee jokaisen ryhmittymän solmun ja lisää sanan " ryhmittymä". Jos poistamme rooli = "ryhmä" lapsiluettelosta, NVDA yksinkertaisesti lisää sanan "lista" sanan "ryhmittely" sijasta, mutta lukee silti ryhmän luettelotiedot. Jos käytämme lapsiluettelossa aria-labelledbyä viittaamaan vanhemman solmun etikettiin, NVDA käyttää tätä merkkiä ryhmittelyn nimellä, joka on paljon vähemmän verbose. Vielä parempi, jos käytämme rooli = "esitys" lapsiluettelossa roolin = "ryhmän" sijasta, NVDA ei lue lapsiryhmää. Tämä aiheuttaa kuitenkin FF: n JAWS: n, kun se laajentaa solmua lapsilla, lukemaan jokaisen näkyvän lapsisolmun etiketin.
    • Lisäksi IE: ssä, kun asetetaan tarkennus solmulle, jossa on lapsia, NVDA lukee jokaisen lapsisolmun, olipa se sitten on laajennettu ja näkyvissä. Tämän lisäksi NVDA lukee ensin kaikki lapsilistan solmut roolilla "group", kun tarkennus siirtyy ensin ryhmään kuuluvaan solmuun.
    • NVDA ei ilmoita laajennetun solmun alaisten lasten kohteiden lukumäärää.
    Window-Eyes ja esimerkki A
    • IE: ssä, kun ensin määritetään tarkennus puun solmulle, Window-Eyes lukee jokaisen puun solmuista näkyvän ja laajennettu tai ei.
    • Kun siirrät tarkennuksen solmuun eri haarassa, Window-Eyes ilmoittaa solmun haaratasosta, jota se kutsuu "syvyyteen".
    VoiceOver ja esimerkki A
    • Mielenkiintoista on, että VoiceOver tunnistaa puita taulukkoina ja tunnistaa valitun solmun vastaavan rivinumeron. Tämä vastaa ainakin sitä, miten VoiceOver käsittelee puunäkymiä Finderissa Mac OS X: ssä, joten odotan, että VoiceOverin käyttäjät tuntevat sen.
    • Nuolinäppäimillä liikkuminen siirtää selaimen tarkennuksen solmusta solmuun, mutta VoiceOver-kohdistin ei seuraa selaimen tarkennusta. Voit laajentaa / pienentää solmuja nuolinäppäimillä ja VoiceOver ilmoittaa, mikä rivinumero on laajennettu / romahtanut, mutta ei solmun tekstisisältöä, mikä tekee tästä puunäkymästä käyttökelvoton tässä tapauksessa. It isn’t clear if this can be a WebKit or a VoiceOver bug, but Apple has been made aware of it.
    • Conversely, using the VoiceOver navigation instructions to maneuver the VoiceOver cursor from node to node does trigger VoiceOver to announce the node's identify, place and expanded/collapsed state, however browser focus does not comply with and hold sync with the VoiceOver cursor. The VoiceOver command (Ctrl+Choice+) for expanding/collapsing gadgets also doesn’t work, and in line with James Craig, gained't until help for the expandrequest and collapserequest IndieUI occasions are supported.
    Orca and Instance A
    • Orca does not indicate the variety of youngster gadgets underneath an expanded node. Utilizing aria-setsize doesn't have any impact.
    • Orca doesn’t indicate the number of sibling nodes on the present department degree or the place among them of the node with focus. Using aria-posinset with aria-setsize has no impact.

    Example B

    Instance B is an unordered listing with position="tree", like example A, but the listing gadgets have nested links, and it’s the hyperlinks which might be set with position="treeitem". Focus strikes via the links, and the hyperlinks' aria-selected values are up to date accordingly. To stop the semantics of the record gadgets interfering, each li has position="presentation.

    Word that baby node groupings are usually not nested as direct descendants of their dad or mum nodes, that are the links with @position="treeitem". As an alternative, they’re siblings to the link. This doesn't appear to hamper JAWS, NVDA, or ORCA, which assign applicable relationships between tree gadgets and their sub-node groupings. It might have some effect in VoiceOver, however VoiceOver doesn't work with this tree view structure in any case.

    Check Outcomes for Example B

    Screen Reader Behaviour with Tree View Example B

    Screen Reader/Browser Enters Software Mode on Focus Identifies Tree View or Comparable Identifies Node's Expanded/Collapsed State Signifies Node's Branch Degree Signifies Node's Place Among Sibling Nodes Signifies Variety of Expanded Node's Youngsters
    JAWS in IE9/10 Yes Sure, however only in Browse Mode Yes Yes Sure, however just for collapsed or end nodes Yes
    JAWS in FF19 Yes Yes, but only in Browse Mode Yes Sure Sure No
    NVDA in IE9/10 Sure Yes Yes No No No
    NVDA in FF19 Yes Yes Sure Sure Sure No
    Window-Eyes in IE10 No Sure Yes Yes Sure No
    Window-Eyes in FF19 Sure Yes Yes Yes Sure No
    VoiceOver in Safari 6.0.2 N/A Tree identified as a desk No No No No
    Orca in FF19 N/A Yes Sure Sure No No

    End result Notes for Instance B

    JAWS and Instance B

    Outcomes for instance B are the identical as these for instance A, with one main exception: As a result of the nested hyperlinks, and not the listing gadgets, are set with position="treeitem", setting focus to or increasing/collapsing a node doesn’t cause JAWS to read each one among its baby nodes.

    NVDA and Example B

    Outcomes are the identical as those for example A, except that moreover, in IE, when setting focus to a node, which is a link in this example, NVDA reads the link's href worth.

    Window-Eyes and Example B

    Results for Window-Eyes in instance B are the identical as in instance A, besides that in IE:

    • When first setting focus to a node within the tree, Window-Eyes doesn’t mechanically enter varieties mode; and,
    • When focus is about to a node, Window-Eyes, like NVDA, reads the link's href value.
    VoiceOver and Instance B

    VoiceOver's behaviour in example B is identical as in instance A.

    Orca and Example B

    Orca's behaviour in instance B is identical as in example A.

    Example C

    Instance C is like example B, in that the listing gadgets have nested hyperlinks. On this case, nevertheless, the listing gadgets are the nodes and set with position="treeitem". Focus moves via the record gadgets. Activating a tree item by pressing Enter or Area units location to the nested link's href worth.

    Check Results for Instance C

    Screen Reader Behaviour with Tree View Instance C

    Screen Reader/Browser Enters Software Mode on Focus Identifies Tree View or Comparable Identifies Node's Expanded/Collapsed State Indicates Node's Department Degree Indicates Node's Place Among Sibling Nodes Signifies Variety of Expanded Node's Youngsters
    JAWS in IE9/10 Yes Sure, however solely in Browse Mode Yes Yes Yes, but only for collapsed or end nodes Sure
    JAWS in FF19 Sure, however see notes Yes, however solely in Browse Mode Sure Yes Yes No
    NVDA in IE9/10 Sure Yes Yes No No No
    NVDA in FF19 Yes Yes Yes Yes Sure No
    Window-Eyes in IE10 Sure Sure Sure Sure Yes No
    Window-Eyes in FF19 Sure Yes Yes Sure Yes No
    VoiceOver in Safari 6.zero.2 N/A Tree identified as a desk No No No No
    Orca in FF19 N/A Sure Yes Yes No No

    Outcome Notes for Example C

    JAWS and Example C
    • In IE, as with instance A, JAWS reads all baby nodes, expanded and seen or not, when setting focus to or increasing/collapsing a node with youngsters.
    • In FF, upon first setting focus to a node in the tree, JAWS will routinely enter varieties mode only if the hyperlinks nested inside the listing gadgets are set with position="presentation". Otherwise, one needs to manually enter varieties mode by hitting Enter on the focussed node. Alternatively, one can flip off JAWS' Virtual PC Cursor. Using nested spans as an alternative of nested hyperlinks avoids this concern.
    NVDA and Instance C

    NVDA's behaviour in example C is identical as in example A.

    Window-Eyes and Example C

    Window-Eyes' behaviour in example C is identical as in example A.

    VoiceOver and Instance C

    VoiceOver's behaviour in instance C is identical as in examples A and B.

    Orca and Instance C

    Orca's behaviour in instance C is identical as in examples A and B, with one main exception: As soon as focus is about to an end node that accommodates a hyperlink, focus is about to the hyperlink itself. At that point, the arrow keys will move focus from hyperlink to hyperlink, but not node to node, thereby requiring Orca navigation commands (Orca Modifier + arrow keys) to truly change node, whereas simply the the left and right arrow keys proceed to broaden/collapse nodes with youngsters. Nevertheless, setting position="presentation" on the nested hyperlinks solves this drawback for Orca. This isn’t an enormous deal because the links aren't focussable anyway as a result of they’re set with tabindex="-1" to be able to drive focus to the listing gadgets, which act as the tree nodes.

    Instance D

    Instance D is like instance C, in that the record gadgets are the tree gadgets, however departs from the three earlier examples in that it uses aria-activedescendant. Focus doesn’t roam via the tree nodes, but as an alternative stays on the tree itself. With give attention to the tree, using the arrow keys updates the tree's aria-activedescendant value to the id of the chosen node, which is about with aria-selected="true". Urgent Enter or Area units location to the href worth of the nested hyperlink whose id is referenced by aria-activedescendant.

    Check Results for Instance D

    Screen Reader Behaviour with Tree View Example A

    Screen Reader/Browser Enters Software Mode on Focus Identifies Tree View or Comparable Identifies Node's Expanded/Collapsed State Signifies Node's Branch Degree Indicates Node's Place Amongst Sibling Nodes Signifies Variety of Expanded Node's Youngsters
    JAWS in IE9/10 Sure Sure, however solely in Browse Mode Yes Yes Sure, but only for collapsed or end nodes Yes
    JAWS in FF19 Yes, but see notes Yes, however only in Browse Mode Yes Sure Yes No
    NVDA in IE9/10 — see notes Sure, however see notes Yes Sure No No No
    NVDA in FF19 Yes Sure Sure Yes Yes No
    Window-Eyes in IE10 Sure Yes Sure Yes Yes No
    Window-Eyes in FF19 Yes Yes Sure Yes Sure No
    VoiceOver in Safari 6.zero.2 N/A Tree identified as a table Sure, but see notes Sure No Yes
    Orca in FF19 N/A Yes Sure Sure No No

    End result Notes for Instance D

    JAWS and Example D

    Behaviour in instance D is identical as in instance C: In FF, the hyperlinks nested inside the record merchandise tree nodes need position="presentation", else JAWS does not routinely enter types mode. Nevertheless, in FF, without position="presentation" on the hyperlinks, hitting Enter on the at present selected node only serves to right away toggle types mode on and off again on the similar time. Nevertheless, manually turning off JAWS's Virtual PC Cursor does the job for providing access to the tree view. Once more, if nested spans are used as an alternative of links, this is not a problem.

    NVDA and Instance D
    • In IE9, NVDA performs successfully the same as it does in examples A and C. Nevertheless, in IE10, interaction with this instance tree view appears somewhat damaged. This is able to look like an IE10 concern, as NVDA performs as anticipated in IE9. Principally, in IE10, NVDA doesn’t routinely enter software mode when focus is about to the tree. Even when one manages to get into software mode (by pressing Down arrow and then Tab once focus is about to the tree container), full entry to each node within the tree doesn't appear potential.
    • In a fast check using IE10 with a variation on example D with out nested links inside the record gadgets, as could be found with James Craig's ARIA tree view instance, the results are a lot the same: While James' instance makes use of position="application", which routinely forces NVDA into software mode, it stays that not one of the node's text is announced by NVDA, making the tree view successfully unusable.
    • In IE9, upon choosing (aka setting aria-activedescendant to the id of) a node with youngsters, NVDA reads all youngster nodes, expanded and visible or not. It additionally does this on this example each time increasing or collapsing a node. Setting aria-labelledby to the id of the nested hyperlink's text solves this, although doing so causes critical issues with VoiceOver. And even then, youngster lists with position="group" still get learn out by NVDA when a node in a new baby record group is chosen. If desired, this might be addressed by setting aria-labelledby on the child listing's ul, or utilizing position="presentation" as an alternative of position="group".
    • In FF, NVDA's behaviour with instance D is identical as with examples A, B, and C.
    Window-Eyes and Instance D

    Window-Eyes' behaviour in instance D is identical as in examples A and C.

    VoiceOver and Example D

    • That is the one example through which VoiceOver works with the tree view. It might seem that, at the very least in the intervening time, VoiceOver doesn’t help the roaming tabindex strategy where focus truly strikes from node to node, but requires using aria-activedescendant on the tree container to point to the presently chosen node.
    • Since VoiceOver identifies the tree as a table, when a specific node with youngsters is expanded/collapsed, VoiceOver pronounces the number of rows which were added or removed, and the row number of the at present chosen node.
    • When focus is first set to the tree view, VoiceOver does not announce the label of the at present lively descendant. Once the lively descendant node modifications by way of the arrow keys, nevertheless, then VoiceOver proclaims its label. Since adding aria-labelledby to the nodes causes problems with VoiceOver, I've not discovered a method to overcome this slight limitation.

    Orca and Example D

    Orca's behaviour in instance D is identical as in examples A and B.


    Many because of James Craig for recommendation on ARIA tree views normally and offering an example that labored in Safari with VoiceOver, and to Todd Kloots for helpful insights and dialogue, and testing VoiceOver in Mac OS X Lion.


    Word: The translations under are listed with no assure of their accuracy (or the accessibility of their content).