Making Accessible Overlay Window

Hello Friends,

Currently I am working on an eCommerce application, which requires to Pass through AA Accessibility guidelines.

My first task is Making Accessible Overlay window.

  1. This overlay window is done using jQuery.
  2. On Click link or button an overlay window will open.
  3. Once Overlay opens the screen reader focus should go to overlay window and reader travel text links etc.
  4. on click ESC it will quit
  5. User should navigate to close button through tab order. and on press enter oberlay should close and get’s it’s focus back to the link or button from where he clicked overlay to open.

Please advice Tow to Achieve this.

Thanks

Hi Pravatctc. Welcome to the forums. :slight_smile:

This is a good question to be asking … but all I can say it—Good luck!

I haven’t seen a convincing demonstration of this … but I may have missed something. If you really want accessibility, I’d suggest ditching all that jQ fanciness and having a logical progression of events like a new page when something has changed. Just my 2c, though. :slight_smile:

This is a good question for @Stomme_poes.

Hm. I remember reading a discussion from either Marco Zehe about this or Everette Zufelt. One issue was about whether to add application, dialog or other ARIA roles to the overlay. There were problems with all of them, especially if the overlay is a mixture of text and form controls, cause then you’re switching contexts (cursor mode and edit/forms mode).

So far whenever I’ve needed to do something like this, I’ve manually moved the focus around, but this wouldn’t have prevented using the SHIFT key to back out of the overlay with keyboard without closing it. Usually once you get focus in the overlay, having a close button that reacts to the letter “x”, the ESC key, or a form-like button you can hit ENTER, works pretty well: it will close the overlay and bring the user either back to where the focus last was, or the next focusable item after that. Sometimes you can do that naturally and sometimes you have to manually move the focus when the close button is hit.

I’d really like to hear from some guys, lemme send some twots.

I want to post some information I’ve been given by some folks:
By Graham Armfield of Coolfields:

Hi Mallory, I wrote this blog post late last year:
http://www.coolfields.co.uk/2011/12/specification-for-an-accessible-lightbox/

It obviously is talking more about an image lightbox but the principles are similar. There are also a couple of useful comments at the end.

I had a go at building an accessible one for a client a while back. It’s not perfect but I have some ideas on how to improve it that I’ll implement when I get a bit of time. You can see it at: http://harpcoventgarden.com/photos/

In that one it is purely driven by javascript - there is no ARIA at all.

Graham

If you try out his harp lightbox, you’ll notice it doesn’t restrict or trap the keyboard the way a true modal dialog window does, and also if you continue tabbing, you simply fall out of the lightbox and it closes. Interesting. Graham also pointed out this comment from his blog: http://www.coolfields.co.uk/2011/12/specification-for-an-accessible-lightbox/#comment-2613

Follow-up comment by Chris Lamb:

I’ve been quite happy with jQuery simplemodal. With two little exceptions:

  1. Having troubles making the focus properly move into the modal/lightbox. Possibly on account of…
  2. The script adding a tabindex of -1 to one of the modals containing divs

I like the way Graham’s solution moves focus to the lightboxes close button - then back to the original anchor when closed.
However I don’t like how some of the other features that you’d expect from a lightbox don’t work. For example:

  • Cursor left and right for previous and next photos
  • Esc/X/C keys to close the lightbox (what I’d consider to be the ‘other standard exit methods’ that are mentioned in WCAG2 2.1.2
  • click on greyed-out background to close lightbox.

Chris Blouch from AOL added this, about jQuery:

jQueryUI 1.9 just came out which is supposed to incorporate the a11y changes made as part of the AEGIS project. You can take a look at the modal dialog sample created before the release here:
http://access.aol.com/aegis/#goto_dialog
One tricky bit is that there are invisible objects in the tab order before and after the actual dialog content so if you tab out of the bottom you land on the tab stop and it moves your focus back to the top, and vice versa. It also has a few nice keyboard controls to move and resize the modal. If focus is on the title bar the arrows move it around. If focus is on the ‘grabber’ in the bottom right corner arrow keys stretch the dialog box.

These are good points. I’m going to look for examples by Filament Group or Paciello Group; they generally have pretty decent demos and tests, even for things that aren’t quite “there” yet.

Wow, that’s brilliant, Mallory. Great research! I’m going to look at these examples carefully.

Thank you very much guys. It’s really helpful discussion and I gained good knowledge, which will help to fix my accessible overlay issue. :slight_smile:

Thanks

Web-AIM has an example using haspopup:
http://webaim.org/presentations/2012/ariahtml5/hiddenlinks2

Though many of the other examples I have small issues with. They may still be tweaking those examples.