mdDialog tab order #2712
Comments
|
Which type of dialog? The alertdialog is focused so that users will be notified of its contents. Forwarding focus directly to the action button is not desirable for those types of dialogs. |
|
Also, which screen reader and browser? I'm not seeing focus on the body. If I tab out of the HTML page from the Custom dialog demo and all the way through the browser controls, I am able to tab onto the dialog wrapper. But given that this reads the dialog contents, I'm not seeing a problem. |
|
Chromevox and Chrome, and the confirm dialog is what I was looking at, but it applies equally to the others. Actually, it's perhaps gotten worse since I last checked. After focus goes to the address bar, my next tab focuses the body (you can tell by doing document.activeElement in dev tools) and chromevox does nothing, then the next tab after that focuses md-dialog (chromevox says "Lucky Day dialog"), then the next tab focuses md-dialog-content (chromevox reads the dialog), then the next tab focuses the first button. The body should not be focusable like this, and either the dialog or the content should be focusable, (or neither), but definitely not both. |
|
Sorry to say but Chromevox and Chrome are not a top priority, as the numbers reported by users who rely on AT are quite low. We prioritize Safari and Voiceover, IE and JAWS, and Firefox and NVDA over Chrome and Chromevox. |
|
This also happens in Firefox. I don't have a Windows machine to test NVDA, but the issue is with the tab order, as I explained above. The tab order is
then it loops. From a keyboard-only user's perspective, they press tab twice and nothing happens at all. (#5 and #6 above). The body focus seems to be Chrome-specific, but I think is still worth fixing for keyboard-only Chrome users. |
|
That is a valid point about dialogs needing visual indication of focus. Unfortunately there is nothing like that in the design spec, so we have to come up with something. Definitely a good idea, but it will take some time. That needs to be filed as a separate issue. If the body is being focused in a browser, that is not really in our control– The only relevant action item I see from this issue is that |
|
Actually both |
It's great that mdDialog now captures focus, but I noticed a bug with the new focus states. Now, when you have an mdDialog with, say, two buttons, this is what is focused after pressing tab
ntimes:Specifically, when you're tabbing from the address bar back into the dialog, you have to press tab three times before you get any visual feedback. And when using a screen reader, the dialog is read twice. I'm not sure that the whole dialog should be focusable anyway, because it's not actionable on its own.
This can be demonstrated on the demo page:
https://material.angularjs.org/#/demo/material.components.dialog
The text was updated successfully, but these errors were encountered: