Community
Participate
Working Groups
Our homegrown nav table/tree is not keyboard accessible. I've always assumed that when this became a requirement, we would look at dojo. I took a quick look at the tree grid (http://docs.dojocampus.org/dojox/grid/TreeGrid) when we started, but it was new in 1.4 and advertised as being "in flux." For sure if we need multi-type cell editing support, I think we'd consider moving to this widget, and probably for keyboard support. We should take another look at it when accessibility is on the table. We also have to consider the dojox/requirejs complications.
Talked to Carolyn today about accessibility/keyboard access. Turns out there are some HTML attributes (tabindex=0, -1) that could be used to create a better/more natural tab order for the navigator, and to remove focus-taking things (like our checkboxes and links, etc.) from being in the tab order. However we would still have to implement our own keyboard traversal mechanism in the treetable (right/left expand and collapse, up/down etc.) to be truly accessible. My assumption has been that this work would make us take another look at TreeGrid. For the flat lists (git log, search results, etc....everyone but nav) the keyhandling requirements may be simple enough to take them on. Parallel experiments may be in order. Carolyn will provide more relevant links in this bug to the tab traversal mechanisms that are available to us.
Here's a 12-step guideline for creating an accessible widget with ARIA: http://www.w3.org/TR/wai-aria-practices/#accessiblewidget Detail on the expected keyboard interaction in a "TreeGrid" can be found here: http://www.w3.org/TR/wai-aria-practices/#treegrid Including the general keyboard behavior in the following section: http://www.w3.org/TR/wai-aria-practices/#aria_ex
Tabindex, focus, and keyboard navigation: Section 3.1.2 and 3.1.3: http://www.w3.org/TR/wai-aria-practices/#kbd_generalnav Section 3.2.1 (potentially useful suggestions in the bullet list): http://www.w3.org/TR/wai-aria-practices/#focus_tabindex
This isn't an accessibility issue, but when we start comparing what we gain for accessibility by changing widgets, we should see if we get free/simple drag and drop from dijit. That would be compelling.
I'm sure you saw this, but for the record, here's the drag and drop guidelines: http://www.w3.org/TR/wai-aria-practices/#dragdrop
*** Bug 368862 has been marked as a duplicate of this bug. ***
I've created a fix for the navigator to be accessible to screen readers. The commit is in the bug349591 branch. https://github.com/max-li/orion.client/commit/11cfb438005c82d83e9b0f864f7857719edda468
thanks, Max! My inclination is to hold off on accessibility fixes until 0.4 is done since we aren't committing to accessibility complete on this release. However, Libing, could you take a look at this and assess the risk? If it were to help out with keyboard access in any way, fix annoyances/bugs, then we might want to consider it. But I think we should err on the conservative side.
(In reply to comment #8) > thanks, Max! > My inclination is to hold off on accessibility fixes until 0.4 is done since we > aren't committing to accessibility complete on this release. > > However, Libing, could you take a look at this and assess the risk? > > If it were to help out with keyboard access in any way, fix annoyances/bugs, > then we might want to consider it. > > But I think we should err on the conservative side. Yeah, I will take a look and feed back today.
I reviewed and tested. The part for activating the action menu is enhancing the existing key navigation for sure. But given that we are so close to RC2 and this part is not that critical I think we better hold off. Talked to John and Susan and they have the same feeling. The code itself looks good to me. I think in 0.5, we can just pick up the patch and refine the activating menu part. For the screen reader part, which is the main part of the patch, I can't say much because I am not familiar on that.
Thoughts for activating the menu in the future. Having a special "quick key" for the menu might be cool, but I'd first like to see us make regular tabbing work as expected. The problem as I see it: Today, we seem to have two unrelated keyboard/focus models, and I think we need to get our keyboard navigation working with real browser focus. What we have now: we put focus on the whole navigator div, at which point the up and down arrows and left/right arrows will work. But the up and down arrows aren't putting the real browser focus anywhere, so if the user hits tab, they get normal browser traversal, and end up at the link at the top of the list. This is what necessitates the need for a "go to the menu" shortcut. Also, at this point if the user decides to hit an arrow key, they'll get the default browser scrolling, since the focus is now on the link and not the navigator div. What I think we should do: the navigator div as a whole doesn't ever take focus. Instead, it has to watch the keystrokes coming in to its elements. So the user would tab into the nav by getting to the first link. At that point, up and down arrow could be made to traverse the list up and down, etc., left/right, etc. But the user could also use tab to move across the row, and they would hit the menu naturally after just hitting one tab key. So I don't see the fix as making a new keystroke for "go to the menu for the fake focused item." I see the fix as: "we need to make the keyboard navigation model use real browser focus." Otherwise we will continue to need "special tricks" to work around this difference. This means we have to watch the keys on the links, menus inside the navigator and interpret those, rather htan relying on the navigator div having focus for it to work. This could be a 0.5 effort.
(In reply to comment #11) Huh, I thought I already replied to this. But I guess better late then never... >Today, we seem to have two unrelated keyboard/focus models Note that with the patch posted above, there is really only one type of focus (the "fake" focus). I wouldn't however necessarily be opposed to switching to real focus (but I don't think it would necessarily bring any benefit, see below). >But the user could also use tab to move across the row, and >they would hit the menu naturally after just hitting one tab key. I don't think this is particularly intuitive given that it essentially creates a different keyboard interaction model for our navigator tree compared to other tree widgets. Tree widgets (and most other widgets) tend to only have one tab stop (i.e. you press tab into them, and another tab keypress will move you onto some other focusable item away from the tree). I think that this would particularly be unintuitive and confusing when you can't see the screen (and thus would not know that there is a button associated with each treeitem (I think it's better to just not communicate the existence of a button to screen readers, and just provide a different method to access the menu)). From an implementation standpoint, I'm not too sure if this would even work with ARIA. Since each item can only have one role, there wouldn't be a way to communicate to a screen reader that the button is both a part of the tree (a treeitem) and is also a button. What this means (assuming that you only communicate the button role) is that every time a user would tab to the button, they would "exit" the tree, which would (in my opinion) be quite odd and confusing. My reasoning for the menu keybinding would be that it would be roughly equivalent to bringing up the context menu on a native tree (e.g. in Eclipse) by pressing Shift+F10. I feel that this would be more familiar and intuitive since the actions menu is more or less a context menu for a given tree item. (Admittedly I chose a rather arbitrary keybinding in Shift+Space, but that could always be changed...)
Max, I suppose we are ready to discuss whether the selection model implemented by Libing for navigator has any accessibility holes. If not, can we close this bug?
Max has gone back to school, but I am freed up now from my Eclipse responsibilities for a bit, so I can review accessibility in the navigator. I'll take it for a spin tomorrow. Anything I should be aware of?
(In reply to comment #14) > Max has gone back to school, but I am freed up now from my Eclipse > responsibilities for a bit, so I can review accessibility in the navigator. > I'll take it for a spin tomorrow. Anything I should be aware of? Not necessarily, a lot has changed since the original discussion. We implemented a keyboard/focus model for the navigator, with extended selection, cursoring, space key select, etc. etc. So instead of tabbing through every navigator row, instead you tab into the navigator, and use cursor keys to move within it (more like a desktop or dijit widget). So I guess the question is...did we miss anything? It's probably best to check both the navigator, and git log to look at the different cases. Git log has buttons in rows that you can arrow key left and right to (grid style navigation). Navigator has the tree style where you arrow left and right for expand/collapse. One possible oddity is that it's possible to put the focus into one of the "actionable cells" (such as a git log button) which gives the button (rather than our widget) the focus and then the cursoring etc. reverts to browser behavior. But you'd have to switch from keyboard to mouse to have this happen...so there may be some bugs to fix in this realm but I don't see them as accessibility issues...
Sorry to take so long to get back to you - had problems with a JAWS update, and I needed to uninstall/reinstall to get back to normal. I tested keyboard accessibility with JAWS running, and unfortunately JAWS eats the arrow keys, so we need to tell JAWS that we want those keys, and the way we do this is by giving something role="application". I slogged through the newbie-getting-set-up-for-self-hosting process, and I'm testing role="application" on a couple of elements. The trouble is that role="application" makes JAWS ignore that it's in a table, so even though arrow keys expand/collapse and navigate, JAWS says nothing else. Also, when I select a link and navigate to a new navigator table/tree, it seems that the role="application" is lost and the arrow keys don't work again (but JAWS does know it's in a table). So I'll keep looking at this for a while longer to see what can be done.
thanks, carolyn! I'll assign this to myself marked 1.0 so we don't lose it. No rush for the 0.5 release.
Looking back at the older references, I see that http://www.w3.org/TR/wai-aria-practices/#treegrid talks about using the role "treegrid" with "readonly" set to true for non-actionable items and to false for actionable items. But looking at the dojo implementation of treegrid, I see roles of "grid," "row," and "cell" which look promising. So...that is probably where we should start. Carolyn, would you have time to try these two links and comment on the JAWS behavior (is it right/wrong)...then I can double check what these examples are doing for roles in their implementations. http://archive.dojotoolkit.org/nightly/checkout/dojox/grid/tests/test_treegrid.html http://codetalks.org/source/widgets/treegrid/treegrid.sample.html
talked to Libing. Moving bug to him since he has proximity to both Carolyn and the JAWS machine. I can definitely help though if needed. I think it's a matter of setting the proper roles either - when we create the DOM nodes .. or... - set them in grid handler Libing, do we have any client pages that use explorer without the selection/cursoring model? If so I guess we should have Carolyn check the accessibility of those as well (we may only need the roles when we are using selection model)
(In reply to comment #19) > talked to Libing. Moving bug to him since he has proximity to both Carolyn > and the JAWS machine. I can definitely help though if needed. I think it's > a matter of setting the proper roles either > - when we create the DOM nodes .. or... > - set them in grid handler > > Libing, do we have any client pages that use explorer without the > selection/cursoring model? If so I guess we should have Carolyn check the > accessibility of those as well (we may only need the roles when we are using > selection model) If explorer+selection renderer are used, it gets the selection model by free. As far as I know git repo and setting pages are not using selection model yet but the reason is that they are not using explorer either.
Moving to RC1 but I think it is still an M2 candidate.
(In reply to comment #18) > Carolyn, would you have time to try these two links and comment on the JAWS > behavior (is it right/wrong)...then I can double check what these examples > are doing for roles in their implementations. > > http://archive.dojotoolkit.org/nightly/checkout/dojox/grid/tests/ > test_treegrid.html > http://codetalks.org/source/widgets/treegrid/treegrid.sample.html Carolyn tried this, as did I. I also tried this: http://test.cita.illinois.edu/aria/grid/grid1.php In all of these samples, the custom navigation keys (arrow left/right, up/down) stop working when JAWS is running. Cursoring left/right actually reads individual letters in table cells. I thought this was a bug until I found this: http://stackoverflow.com/questions/6855708/conflicts-between-jaws-table-navigation-short-keys-and-custom-implemented-naviga I think we need to first figure out what the expected accessible behavior would be. I thought it would be to honor the cursor left/right and up/down keys and read the list items. But it sounds like this is not what we want, that there may be alternate keystrokes required to invoke cursoring?
This one works, insofar as the cursor keys still work with jaws and the cells are being read. http://test.cita.illinois.edu/aria/grid/grid4.php And is touted as a good example for tree/grid widgets to follow here: http://webaim.org/discussion/mail_thread?thread=4092
Libing and Carolyn are going to look at this.
Per discussion with Carolyn and Susan, seems that JAWS consumed the arrow keys for its own meaning. This is preventing the Orion selection model from behaving correctly from the first place. To satisfy both screen reader and none screen reader scenarios, the change will be a lot. Pushing this to 2.0 time frame.
This article might be helpful: http://www.accessibleculture.org/articles/2013/02/not-so-simple-aria-tree-views-and-screen-readers/
I think we need to just put in the semantic tags and move forward from there.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
Still a problem.
For places where this is used as a table, just need to make sure that the html table is marked up properly with headers (th, typically with scope="col") and a caption. For places where this is used as a tree, there are 2 choices (I'm not sure which will work best). Either: a) Give the html table element tree role, and then see how to apply the rest of the aria tree markup: http://w3c.github.io/aria-practices/#TreeView b) Give the html table element presentation role: http://w3c.github.io/aria/#presentation (read this whole section carefully) which should automatically remove the semantics from its thead/tbody/tfoot/tr/th/td children. (caption, too, I believe) and then see how to apply the aria tree markup.
