Follow-up to [#]716612]

The Overlay is a complex UI component designed with JS / CSS. We should look at implementing WAI-ARIA to make the overlay as accessible as possible for users of WAI-ARIA compliant user agents / assistive technology.

Comments

mgifford’s picture

True. So can you document some of the places where ARIA alerts would be useful?

Cliff’s picture

subscribing

Everett Zufelt’s picture

Follow-up to #716612: Overlay is not accessible to screen reader users

We need to consider Overlay to be a modal dialog and follow the best practices for modal dialogs.

In addition to what already exists for Overlay we should:

1. Before Overlay child loads set role="application" on body of parent document.

2. Set role="dialog" on body of child document

3. Set role="document" on first container div (wrapping all child content).

This should make the dialog stand apart as a separate document from the underlying page. We also need to either move the toolbar into the Overlay iframe (preferred), or make the toolbar it's own modal dialog and provide skip links to allow screen-reader users to move between the two. The second solution is really terrible, since this is a completely foreign interaction pattern.

Everett Zufelt’s picture

Priority: Normal » Major
sun.core’s picture

Priority: Major » Normal

Sorry, but you can still disable Overlay to have a (mostly) ARIA-compliant site.

Everett Zufelt’s picture

Priority: Normal » Major

Please do not change issue priority without a strong rationale.

The entire Overlay currently needing to be disabled because it does not work as expected for all screen-reader users is pretty good rationale for Major priority. 0 screen-reader users can use overlay as expected (i.e. hiding the parent content and only exposing child / toolbar).

Furthermore, as an accessibility issue I consider this to be an issue that I have responsibility for. I expect that the priority will not change again, if it does I expect a strong rationale.

Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev

Bumping to D8.

yoroy’s picture

Is #3 still the game plan for this issue?

Everett Zufelt’s picture

@yoroy

I'm not sure that we really have too much of a game plan at the moment. I tell all clients and potential clients to disable the module. I am certainly interested in trying to find a solution that makes Overlay work smoothly for screen-reader users, but it is by no means trivial.

yoroy’s picture

Yeah, meant to ask if those action points are still open for exploration or did we exhaust those options already in previous issues?

mgifford’s picture

Issue tags: +aria

Tagging.

bowersox’s picture

Did anyone find a good pattern for modal dialogues? It seems like the solution here is to establish a good pattern for modals, if possible.

@Everett Zufelt, what do you know about using jQuery for modals and tweaking it to improve it?

bowersox’s picture

Note: It appears the work on accessible modal dialogs and pop-ups is happening in this issue:
http://drupal.org/node/1175830

mgifford’s picture

Status: Active » Postponed
Issue tags: +jQuery, +modal dialog

Postponed until there is a consistent way to apply modal dialogs in D8. This is likely going to come with jQuery 1.10.

nod_’s picture

You should take care of mentioning it's jQuery UI 1.10 :)

Also overlay is not what could be called a modal, it's more of an iframe overlay. It might be the case that we'll have to brutalize jQuery UI a little to achieve the same result as overlay. I'm happy to be proven wrong, just want to mention it if someone wants to work on that.

mgifford’s picture

Thanks @nod_ - fits with what I know.

mgifford’s picture

falcon03’s picture

Priority: Major » Critical
Status: Postponed » Active

Now that we have a consistent API for modal dialogs into core, it would be great to make Overlay use modal dialogs to solve its A11Y issues. Re-opening this issue and... Yeah, I am bumping it to critical: if you are blind, when you install Drupal the first thing you do is disabling Overlay since it is a nightmare to use it with a screen reader.

effulgentsia’s picture

Related: #1889150: Simplify overlay look, *only use for contextual operations*. Replacing Overlay with modal dialogs is likely to be much easier if they're only used for contextual operations.

falcon03’s picture

Title: Improve Overlay accessibility for ARIA compliant user agents » Improve Overlay accessibility by using modal dialogs

better title, I hope.

jessebeach’s picture

Content in a modal dialog has the unfortunate behavior of inheriting the styling and behavior attachments of its containing DOM. iFrames are insulated from their host DOM. This allows us to present admin forms within the admin theme.

I'm very curious about the potential of using Shadow DOM elements to render an overlay experience, but this will probably be something we do within the D9 timeframe.

For now, I think we're stuck with the Overlay as an iframe for what the overlay does. And many folks will need to disable it because it just doesn't work for them.

effulgentsia’s picture

Are the current Overlay accessibility problems all due to the IFrame? Is there anything to be gained by making it a jQuery UI dialog with an IFrame inside?

jessebeach’s picture

That's an interesting idea. Sun had mocked up something like this: #1889150-20: Simplify overlay look, *only use for contextual operations*.

I'm not sure how this solves usability issues. IT just seems like another div around an iframe. But I haven't tried it with the jQuery 1.10 dialog yet.

One of the accessibility issues that vinx.03 brought up to me is that the page focus isn't always set inside the overlay when it opens. I'm hoping to address that issue with #1913086: Generalize the overlay tabbing management into a utility library.

mgifford’s picture

Leveraging jQuery UI would likely help. I haven't had time to review the problems with Overlay in any depth (even though it's an old issue).

How easy would it be to set up a demo site of the two for folks to compare? Right now SimplyTest.me isn't working for D8 demos so that's a bit of a pain. It's become such a critical resource.

jessebeach’s picture

I tried to wrap the overlay in a dialog and it's very messy. I'm also not convinced that this extra layer of wrapping gives us any benefit.

falcon03’s picture

@jesssebeach: did you try wrapping the whole overlay iFrame in a dialog or deleting the iFrame at all and using modal dialogs?

If we cannot refactor the overlay to use core modal dialogs, I think that overlay should do what JQuery UI does to make dialogs accessible.

casey’s picture

If you wrap the overlay iframe in a dialog, the overlay cannot contain "sub"-dialogs that can be dragged outside the overlay. This is one of the reasons I used a fullscreen iframe.

jessebeach’s picture

That's a great point, casey.

falcon03’s picture

Issue tags: +JavaScript, +jQuery UI

@jessebeach: so it seems that using dialogs for the overlay is quite hard... Maybe another solution to increase overlay accessibility would be to make the overlay module behave as a JQuery UI dialog. We should ensure that:

  1. Tthe cursor is moved inside the overlay when it appears;
  2. Overlay uses the same ARIA Roles of Jquery UI dialogs;
  3. the toolbar is shown inside the overlay, if it is supposed to show inside it;
  4. the "Close overlay" link becomes a button;
  5. Tabbing is constrained to the content of the overlay (from what I can understand this should be already happening);
  6. Screen readers are able to announce when the content of the overlay changes;

We could find out other overlay A11Y issues implementing these improvements, but if converting overlay to modal dialogs is hard this can be the way to go... I'd like to see this issue fixed for D8! :-)

webchick’s picture

Priority: Critical » Major

This can't really be a critical task, unless we've had a particular accessibility regression. Obviously Overlay was accessible enough to ship D7 in the first place.

That said, the hit list at #29 looks excellent.

jessebeach’s picture

Status: Active » Closed (won't fix)

We're addressing #1 (Tthe cursor is moved inside the overlay when it appears) and #5 (Tabbing is constrained to the content of the overlay) and #6 ((Screen readers are able to announce when the content of the overlay changes)) in #1913086: Generalize the overlay tabbing management into a utility library.

I opened #1964894: Apply the same (or near the same) ARIA attributes to the Overlay that jQuery UI Dialogs use to address #2 (Overlay uses the same ARIA Roles of Jquery UI dialogs).

I opened #1964880: Convert the Overlay close button from an anchor element to a button element. to address #4 (the "Close overlay" link becomes a button).

Regarding #3 (the toolbar is shown inside the overlay, if it is supposed to show inside it), the toolbar is not shown within the overlay, so this isn't an issue.

I'm tentatively closing this issue as won't fix since we have actionable followups for the main improvements.