Community
Participate
Working Groups
Need an accessibility checkup on the Orion dialogs. I have known issues right now (enter and esc keys, focus) so it's not ready yet, but once I think it's right, we should check it.
I'll have a look. Please ping me when you think it's right. Here's the recommended design patterns (including keyboard interaction and some examples) for dialogs (modal followed by non-modal): http://www.w3.org/WAI/PF/aria-practices/#dialog_modal Also, here's a slide deck (from a web accessibility talk) that walks through adding aria to a simple modal dialog: http://cms_apps.ncat.edu/openconf/modules/request.php?module=oc_program&action=summary.php&id=38 (starting at about slide 25, but feel free to view the general aria slides leading up to the example... <grin> I am trying to leverage all "teachable moments" these days, just in case I am abducted by aliens tomorrow </grin>).
FYI, Anton will likely be going through the same or similar steps with the new "gear" settings dialog, so you may want to coordinate with him. Initial thoughts on that are captured in bug 397760.
Carolyn, I have fixed all the focus and keyboard things I wanted to do, and just did a pass to ensure that focus traversal, keyboard support on buttons, etc. was to my liking. I'm ready for a checkup now. Dialogs launched from the navigator are probably the best place to start. Szymon is still working on git dialogs. Examples: Find File Named (Ctrl+Shift+F) from any page SFTPConnection (navigator actions->SFTP from... and SFTP to...) Directory Prompter (navigator actions->move to->choose folder) Import Dialog (navigator actions->Import local file) The SFTP connection dialog as an inner popup dialog that is worth checking, because it is more of the popup style that we use. I admit I did not yet have a teachable moment with those links, still grinding for M2, but I will read them after this checkup sometime during RC1.
should mention, please check on the next deployed build (after today) as I just released changes.
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
Reopening. The Orion dialogs were recently merged from 3 dialog classes down to 2. All of the dialogs need to be tested for keyboard and screen reader accessibility. Here's the latest ARIA Authoring Practices Guide link about dialogs: http://w3c.github.io/aria-practices/#dialog_modal (Also, in the ARIA Spec: http://w3c.github.io/aria/aria/aria.html#dialog) The guide discusses the required Keyboard interaction, such as focus moving to the dialog when it opens, and back to the trigger element when it closes; trapping Tab and Shift+Tab within the dialog; make sure ESC or clicking outside the dialog closes; make sure there's a button to close or cancel. The Guide also discusses the Roles, States, and Properties needed to make a dialog work with a screen reader. This video may be helpful: https://www.youtube.com/watch?v=JS68faEUduk
See also: Bug 400138
Are we allowed to use "polyfills/prollyfills"? https://github.com/WICG/inert https://github.com/GoogleChrome/dialog-polyfill
Providing the license is ok, we can use any sort of library we want. Ask Mike R.
(In reply to Steve Northover from comment #9) > Providing the license is ok, we can use any sort of library we want. Ask > Mike R. Could we not just update our code to "do the right thing" rather than require a library to do it for us? If the answer is "no", then yes, we can open a CQ for the polyfill library.
The "right thing" is complicated. ;) Mostly interested in the "inert attribute" polyfill, here. (the one for <dialog> could maybe be used after more browsers implement dialog element natively). The reason "it's complicated" is that screen readers can navigate to anything that isn't marked with either html hidden, display:none, visibility:hidden or aria-hidden="true". So even if you trap the tab key in the dialog, a screen reader user can still type b to go to any button, c for combo, e for edit, p for paragraph, t for table, etc. So in order to open a modal dialog that a screen reader user could not accidentally navigate out of, you would have to: - set aria-hidden="true" on all of the dialog's sibling elements so that screen readers will prune them from the accessibility tree (the browser constructs an accessibility tree that is parallel to the DOM tree) - and (because aria-hidden doesn't prune active elements) you need to traverse the entire tree and set tabindex=-1 on everything outside of the dialog that could be focusable (i.e. links, form elements, contenteditable, etc)... and then undo all of those changes when the dialog is closed. "inert" prevents an element and all of its children from receiving events. You would put it on the dialog's siblings (assuming the dialog is a child of body), and remove it when the dialog closes. Chrome already has "inert" behind a flag: https://www.chromestatus.com/feature/5703266176335872 chrome://flags#enable-experimental-web-platform-features Firefox request (feel free to vote <g>): https://bugzilla.mozilla.org/show_bug.cgi?id=921504 Edge request (feel free to vote <g>): https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/31606522-support-the-inert-attribute Webkit/Safari: https://bugs.webkit.org/show_bug.cgi?id=165279 Caniuse: https://github.com/Fyrd/caniuse/issues/3090
