Page MenuHomePhabricator

OOjs UI: Dialogs are not accessible
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65474

Details

Reference
bz65473

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:22 AM
bzimport added projects: OOUI, Accessibility.
bzimport set Reference to bz65473.

(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

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.