Last modified: 2014-06-27 00:27:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67473, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65473 - OOjs UI: Dialogs are not accessible
OOjs UI: Dialogs are not accessible
Status: RESOLVED FIXED
Product: OOjs UI
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: Normal normal
: ---
Assigned To: Alex Monk
: accessibility
Depends on:
Blocks: 367
  Show dependency treegraph
 
Reported: 2014-05-19 08:56 UTC by Derk-Jan Hartman
Modified: 2014-06-27 00:27 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Derk-Jan Hartman 2014-05-19 08:56: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.
Comment 1 Alex Monk 2014-06-04 21:36:18 UTC
(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?
Comment 2 Krinkle 2014-06-04 22:38:52 UTC
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.
Comment 3 Derk-Jan Hartman 2014-06-05 08:42:34 UTC
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.
Comment 4 Derk-Jan Hartman 2014-06-05 08:43:11 UTC
'direct sibling' -> 'direct child'
Comment 5 Alex Monk 2014-06-10 18:50:06 UTC
(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?
Comment 6 Derk-Jan Hartman 2014-06-10 20:27:59 UTC
(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
Comment 7 Gerrit Notification Bot 2014-06-11 23:52:27 UTC
Change 139039 had a related patch set uploaded by Alex Monk:
Accessibility: Set role=dialog on dialogs

https://gerrit.wikimedia.org/r/139039
Comment 8 Gerrit Notification Bot 2014-06-12 00:35:32 UTC
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
Comment 9 Gerrit Notification Bot 2014-06-18 01:20:27 UTC
Change 139039 merged by jenkins-bot:
Accessibility: Set role=dialog on dialogs

https://gerrit.wikimedia.org/r/139039
Comment 10 Gerrit Notification Bot 2014-06-18 02:32:53 UTC
Change 139047 merged by jenkins-bot:
Accessibility: Restore element focus when a window closes

https://gerrit.wikimedia.org/r/139047
Comment 11 James Forrester 2014-06-18 02:38:29 UTC
Is there anything further outstanding here?
Comment 12 Alex Monk 2014-06-18 16:51:20 UTC
(In reply to James Forrester from comment #11)
> Is there anything further outstanding here?

I need to figure out that aria-hidden thing.
Comment 13 Alex Monk 2014-06-19 16:40:21 UTC
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?
Comment 14 Alex Monk 2014-06-22 00:19:57 UTC
<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.
Comment 15 Gerrit Notification Bot 2014-06-23 16:15:49 UTC
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
Comment 16 Gerrit Notification Bot 2014-06-23 18:38:16 UTC
Change 141456 merged by jenkins-bot:
Accessibility: Set aria-hidden attribute on elements while dialogs are open

https://gerrit.wikimedia.org/r/141456
Comment 17 James Forrester 2014-06-23 18:40:26 UTC
Iā€¦ guess that this is now fixed?
Comment 18 Derk-Jan Hartman 2014-06-23 20:08:56 UTC
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.
Comment 19 Alex Monk 2014-06-27 00:27:00 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links