Community
Participate
Working Groups
Open the wrench menu, put focus on it and start tabbing, the focus can leave the drop down. This also happens in the git page dropdown (i.e References) and in the edit page menus. There are two options to fix this: 1) we can trap the focus in the drop down 2) we can dismiss the drop down
The handling needs to be done by trapping the 'blur' on the last element within the 'dialog'... Car and I have determined that we'll take two different approaches based on the 'type' of the container being traversed: 1) Menus / Dropdowns (File/Edit... and Help etc) will *not* trap the focus but instead move to the next tabbable (NOTE: we need to also have Arrow key navigation in place for the menu structure to allow this). 2) Dialogs (things that go away on ESC but contain 'controls' (text fields, buttons, checkboxes...) *will* trap the Tab until ESC is hit.
> The handling needs to be done by trapping the 'blur' on the last element within the 'dialog'... Also on the first element when using shift+tab to traverse backwards. > 2) Dialogs (things that go away on ESC but contain 'controls' (text fields, buttons, checkboxes...) *will* trap the Tab until ESC is hit. Yep. We also agreed that mouse click will still close the 'dialog'. There's a "tooltip dialog" pattern that is being reviewed/rewritten for the ARIA Practices Guide that may have some useful info. Discussion is here: https://github.com/w3c/aria-practices/issues/85 The old guidance is here: https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#dialog_tooltip And the old examples page is here: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_TooltipDialog.html If we end up using any of this and have anything interesting to contribute back, I am sure they would welcome the input.
I'm in the process of tracking down and fixing these. Things to look out for in the code review: 1) I'm not sure whether the changes in 'section.js' should be inside the if that checks if the firstTabbable is an INPUT (i.e. I added the code to fix the Repository and Reference dropdowns but I' afraid of interferring with sections that aren't in dropdowns). I've avoided making the changes in dialog.js since *some* of these dialogs work OK but others don't. The OpenResource dialog correctly traps tabs if it's opened with previous results but *only* until new search results come in, then it's busted.
I"ve created a branch 'emoffatt/DialogTabTrap' for this work but have yet to push the first instance...
Note that for many of the parameter mini-dialogs like adding a new Git Repository fro the edit page the ESC only works when the focus is in the default input field...
GitHub Pull Request 37 created by [emoffatt] https://github.com/eclipse/orion.client/pull/37
For what it's worth, the "inert" attribute could/would/should be a useful improvement to our modal dialog focus handling "someday": https://twitter.com/rob_dodson/status/868296999375847424 And/or we could use this inert polyfill (scroll down to read the README.md): https://github.com/wicg/inert This is because modals are tricky to get right for all users (keyboard, mouse, screen reader...): https://robdodson.me/building-better-accessibility-primitives/
Can this be closed now?
