[WG: Accessibility] Keyboard navigation and overlays

Wed Jan 11 11:00:11 PST 2012

If the overlay is part of a modal dialog, then, yes -- It should restrict the focus on the page to that dialog (you can't keep them from leaving the browser window).

Strange things can happen if one's business logic assumes the user must choose an option in a modal dialog and the user can really still interact with the rest of the page...

For an example of working focus control. Bring up a dialog from the ckeditor demo at:
http://ckeditor.com/demo
Activate the insert table toolbar button and see how focus is limited to the dialog box.

This can easily be done by managing tabindex values and putting in a javascript keyboard interaction handler for the dialog. The W3C ARIA documentation tells how to do this - it's not hard to do technically, but it is hard to well do unless one is aware of the issues and has thought it all out.

Another level of it is masking out the links, form controls, and headings from the rest of the page. This must be done or otherwise the links list dialog, headings list dialog, form controls list dialogs, etc. will confuse the screen-reader user as well. Usually this is done by putting the whole page content (minus the modal dialog) in a div and setting the content div to aria-hidden="true" when the modal dialog is present. For example:
<body>
  <div id="pageContent" aria-hidden="true">
       ... page content...
</div>
<div id="modalDialogs" aria-hidden="false">
  ... dialog content...
</div>
</body>

Of course, it is really important to mark up the modal dialog content appropriately, and test to make sure it is obvious to the user that they are in a modal dialog, how to answer the dialog, and especially how to close/dismiss it. Also, there are bugs where certain elements don't appropriately inherit the aria-hidden state and are listed in JAWS screen-reader finder dialogs. Also, some screen-readers don't yet support aria-hidden. This is why it is especially important to manage the tabindex and keyboard interactions as indicated in the ARIA docs. Also, consider using jQuery to disable any links and form controls on the page.

A flow chart for this would be something like:

1.       Store current page focus location

2.       Hide / disable page content

3.       Reveal modal dialog

4.       Set focus appropriately in modal dialog box

5.       Use javascript handler to manage focus and tabindex values appropriately

To close dialog:

1.       Reveal / enable page content

2.       Set focus to original element or appropriate new element if the page content changed as a result of the dialog.

3.       Hide / disable / remove dialog elements

-Brian

-Brian

From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Eli Cochran
Sent: Wednesday, January 11, 2012 1:43 PM
To: Fitzgerald, Kent
Cc: Joe Humbert (JIRA); accessibility at collab.sakaiproject.org WG
Subject: Re: [WG: Accessibility] Keyboard navigation and overlays

Kent,
Don't apologize. I know you sent this question to the list by accident but this is actually an awesome question for the whole list. It is also a great question for the accessibility working group. Copying them as well.

I would love to hear everyone's take on this.

- Eli

On Jan 11, 2012, at 10:21 AM, Fitzgerald, Kent wrote:

Sorry everyone, pesky outlook address book. Please disregard.

From: Kent Fitzgerald <kentfitz at umich.edu<mailto:kentfitz at umich.edu>>
Date: Wed, 11 Jan 2012 18:19:21 +0000
To: "Joe Humbert (JIRA)" <sakai-ui-dev-tracking at collab.sakaiproject.org<mailto:sakai-ui-dev-tracking at collab.sakaiproject.org>>
Subject: Keyboard navigation and overlays

Hi Joe,
Happy New Year!

Quick question for you. When an overlay is opened, should keyboard navigation be locked into the overlay until the overlay is closed? I.e. Only interact with objects in the overlay and browser elements.

Right now, if I open an overlay and tab through it, it doesn't cycle back to the beginning of the overlay, instead it goes to elements behind the overlay, like the top nav. I can then interact with those elements, even though the overlay is open.

Steps to reproduce: (using keyboard navigation exclusively)

  1.  Create + Collect
  2.  Add Content (Add content overlay opens)
  3.  Tab through the elements in the overlay
You can eventually get to elements behind the overlay and interact with them.

While it seems odd to me, I wanted to get your take on it before I filed it.

Thanks!
-Kent

P.s. Did Anthony add you to the re-created team calendar? I have an email in to him to make sure you were added, but he's traveling this week so asking you is quicker. :)

_______________________________________________ sakai-ui-dev-tracking mailing list sakai-ui-dev-tracking at collab.sakaiproject.org<mailto:sakai-ui-dev-tracking at collab.sakaiproject.org> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev-tracking
_______________________________________________
sakai-ui-dev-tracking mailing list
sakai-ui-dev-tracking at collab.sakaiproject.org<mailto:sakai-ui-dev-tracking at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev-tracking

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
project manager, CalCentral project
Educational Technology Services, UC Berkeley

"Software is hard" - Donald Knuth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20120111/a200107e/attachment-0001.html 