Last modified: 2014-06-27 00:27:00 UTC
The dialog doesn't have the role=dialog. Dialogs don't keep focus inside the dialog (can be fixed with putting aria-hidden=true on the rest of the content of the page They don't restore the focus upon closing to where it was before opening the dialog.
(In reply to Derk-Jan Hartman from comment #0) > Dialogs don't keep focus inside the dialog (can be fixed with putting > aria-hidden=true on the rest of the content of the page So just aria-hidden=true on the main document and then leave the dialog iframe as it is?
Define "main document"? The dialog is technically a child of the main <body> and <html>, I assume we'll want to add it lower than that. We can't guarantee our dialog is the only thing next to that that is focus-able though. We should look into how jQuery UI is doing this. They're known for good accessibility.
With main document I mean every document parts but the dialog. If the dialog is a direct sibling of the body, then it means that all siblings of the dialog should theoretically be 'aria-hidden' and should not allow interaction with the keyboard.
'direct sibling' -> 'direct child'
(In reply to Derk-Jan Hartman from comment #0) > Dialogs don't keep focus inside the dialog (can be fixed with putting > aria-hidden=true on the rest of the content of the page Can you explain exactly how this changes the behaviour of the browser?
(In reply to Alex Monk from comment #5) > (In reply to Derk-Jan Hartman from comment #0) > > Dialogs don't keep focus inside the dialog (can be fixed with putting > > aria-hidden=true on the rest of the content of the page > > Can you explain exactly how this changes the behaviour of the browser? Basically (if the browser supports aria), it will stop making that part of the page 'visible' to the accessibility screenreader and it will not allow you to navigate into that part of a page. In accessibility mode, you have an 'accessibility cursor' that walks over all content of the page (including shadow dom). Everything that doesn't have 'display:none' or 'aria-hidden' is a place that you can navigate to and let it start reading. For a screenreader there is no difference between what we call a 'modal dialog' and a normal dialog (both have role=dialog). It can't know the difference, because there is nothing that will tell it so. So if you are implementing a modal dialog, then you need to set aria-hidden on everything but the dialog, to enforce that behavior. You should also consider setting tabindex=-1, on those areas to make it inaccessible to people using keyboard (tab) navigation, without using a screenreader. There is a very good document on this stuff I highly recommend everyone to read it. http://www.w3.org/TR/wai-aria-practices/#modal_dialog There is also an example here: http://accessibility.oit.ncsu.edu/training/aria/modal-window/version-2/ that might be useful
Change 139039 had a related patch set uploaded by Alex Monk: Accessibility: Set role=dialog on dialogs https://gerrit.wikimedia.org/r/139039
Change 139047 had a related patch set uploaded by Alex Monk: Accessibility: Restore element focus when a window closes https://gerrit.wikimedia.org/r/139047
Change 139039 merged by jenkins-bot: Accessibility: Set role=dialog on dialogs https://gerrit.wikimedia.org/r/139039
Change 139047 merged by jenkins-bot: Accessibility: Restore element focus when a window closes https://gerrit.wikimedia.org/r/139047
Is there anything further outstanding here?
(In reply to James Forrester from comment #11) > Is there anything further outstanding here? I need to figure out that aria-hidden thing.
Derk-Jan, I have been (unsuccessfully) trying to get hold of you on IRC. can you please explain which elements need to get aria-hidden?
<thedj > Krenair: you have trouble with aria-hidden ? <Krenair> thedj, yeah I didn't know which elements should get it <thedj > Krenair: easiest to imagine is this: You have a modal dialog (modal is key here) in a page. <thedj > now disable ALL styles. this is what a screenreader user 'sees'. <thedj > anything outside the modal-dialog, needs to get 'aria-hidden' true for the duration that the modal dialog is presented. <thedj > Krenair: in the context of mediawiki, that is actually a LOT, because we have a lot of messy children of '<body>' <Krenair> thedj, so every element directly under <body> except the modal dialog's ancestor needs to get aria-hidden? <thedj > Krenair: if it has content then yes. <thedj > i mean an empty div in theory would not NEED it, but it's probably easier to give it to that as well for simplicity.
Change 141456 had a related patch set uploaded by Alex Monk: Accessibility: Set aria-hidden attribute on elements while dialogs are open https://gerrit.wikimedia.org/r/141456
Change 141456 merged by jenkins-bot: Accessibility: Set aria-hidden attribute on elements while dialogs are open https://gerrit.wikimedia.org/r/141456
Iā¦ guess that this is now fixed?
Good work ppl, I'm glad to see that we have put effort in this. It is significant more effort than we have put in most other projects on the accessibility front. A very good step forward.
(In reply to Derk-Jan Hartman from comment #0) > They don't restore the focus upon closing to where it was before opening the > dialog. This part was reverted in Gerrit change #141940 I'm not sure it was valid in the beginning... Works for me.