[WG: Accessibility] OAE Keyboard accessibility questions

[Richwine, Brian L]

Hi,

I pretty much agree with Eli on this one, and have a few additional comments. 

It would be good if the OAE UI group gave a thought to keyboard navigation of the whole of the OAE UI. Navigating the navigation bars and widgets is just a part of it. The user experience of non-mouse / keyboard only users would be pretty terrible if the only means of navigating the Sakai OAE UI was to treat the controls as one long linear list that could only be navigated bi-directionally using tab and shift+tab. There are many technologies which can help create a more efficient hierarchical navigation system not only for a given UI feature (such as a menu) but for a given page as a whole.

Many UI features (such as menus, tab panels, tree views, etc.) are recognized as such (if designed well) by sighted users who will probably come with mental models as to how to interact with them. Following standards as much as possible and being consistent across the Sakai OAE will help to make using these features easier and help to reinforce the users mental models. Without appropriate ARIA markup (and in some cases HTML 5 markup), non-visual users will probably not recognize that a given set of lists and links represents a menu vs. a tree view vs. a tab panel vs. etc., and won't know how to operate them. This is where marking up custom UI features with the appropriate ARIA roles will help non-visual users understand what they are navigating through. Additionally, marking up the various components of a UI feature with accurate state information (is the submenu open or closed?) helps the non-visual user understand what is going on and provides feedback to their actions.

It's important to follow standard keyboard interactions / behaviors when designing UI features. For details on how these interactions should behave, see the following resources:
  1). The WAI-ARIA Authoring Practices: http://www.w3.org/TR/wai-aria-practices/
  2). The DHTML Style Guide details keyboard interactions / behaviors for standard controls: http://dev.aol.com/dhtml_style_guide
  3). iCITA ARIA Examples site provides working models and detailed explanations of ARIA features: http://test.cita.illinois.edu/aria/index.php
  4). Specific example of ARIA Menu w/keyboard accessibility: http://test.cita.illinois.edu/aria/menubar/menubar1.php
  5). Freedom Scientific (creators of the JAWS screen-reader) have a document on their support of ARIA which can really help in understanding working with ARIA: http://www.freedomscientific.com/PDF/visionloss/manuals/DevDoc/JAWS-ARIA-Support.doc

Note that it is really important to test ARIA features with real screen-reader users and sighted keyboard only users to make sure they work! 

Other thoughts for navigating the whole page:
 * Important to being able to navigate a page is having an understanding of the page's structure and purpose. Appropriate use (meaningful heading text and appropriate hierarchy) of headings can really help non-visual users gain this understanding. Think of headings as forming an outline of the page. Screen-reader users can navigate easily from heading to heading and also pull up a list of all the headings on the page. The Sakai CLE interface uses hidden headings to make the page structure more obvious and more navigable for screen-reader users. NOTE: This form of navigation is generally not available to non-screen-reader users and will not be a help to many keyboard only users.
 
 * ARIA Landmarks (role="navigation", role="search", role="banner") and HTML 5 elements (<header>, <article>, <footer>, etc. ) can also be used to denote a page's structure. Currently, screen-reading software supports simple navigation by landmark, but not navigation by HTML 5 element type. ARIA Landmarks can also be given descriptions / labels so you can go further at describing the landmark. NOTE: This form of navigation is not available to non-screen-reader users and will not be a help to many keyboard only users.

* It is important to keep the needs of non-visual users for understanding and navigating the page in mind AS WELL AS sighted keyboard only user's needs in mind. They are not the same.

To summarize: Settling on a well thought out mix of the following structural markup and navigation techniques and writing a style guide on how to implement them consistently will help all users:
  * "Skip navigation" links
  * ARIA Landmarks
  * Headings 
  * ARIA roles, states, and conforming JavaScript controller logic for interactive UI features (menus, etc.)

-Brian  

-----Original Message-----
From: Eli Cochran [mailto:eli at media.berkeley.edu] 
Sent: Sunday, July 31, 2011 12:42 AM
To: N. Matthijs
Cc: Eli Cochran; Richwine, Brian L; Chris Roby; Colin Clark
Subject: Re: OAE Keyboard accessibility questions

Hi guys,
Tricky question. 

My preference is that the tab key jumps the user from major structure to major structure and then the arrow keys are used to move within the structure. This allows for the tab key to be used for gross movement and the arrow keys for refining the selection. 

However, I've always been a bit torn about this for navigation menus. 

Menus should be implemented as lists of links so that they can be found by a screenreader. And the default keyboard behavior for links is that the tabkey will jump from link to link. This is expected behavior, so messing with it seems wrong unless there is an easy way to communicate the _improved_ navigation to the screenreader user.

Then again, a savvy screenreader user is going to be reading the links out of context of the rest of the content on the page. I think that you guys have seen screenreader users do this by calling up a menu of all the links on the page. So perhaps we should be more worried about the sighted keyboard user. In that case, I would make each menu tabbable and then each menu item accessed through the arrow keys. 

I hope that this helps. 

I'm cc'ing Colin Clark to see if he has an opinion. And I'm curious to hear what Brian and Mary say. I can also ask Lucy Greco hear at Berkeley on Monday.

- Eli 
 


On Jul 29, 2011, at 9:54 AM, N. Matthijs wrote:

> Hi Eli and Brian,
> 
> One of the next tasks we'll be tackling in the next 2 weeks is making 
> some of our core UI components keyboard accessible and screenreader 
> friendly (SAKIII-3709).
> 
> There's 2 JIRA tickets that I'd like to get your input on.
> SAKIII-3661 is around making our top navigation and the dropdowns that 
> come with it keyboard accessible. I was hoping to find out what the 
> best user experience for this would be. Is it removing tabindex of all 
> links and make the whole top nav bar selectable via tab, and then use 
> the arrow keys inside of the top navigation, or should we just make 
> all of the links in there selectable via tab?
> 
> We have the same question for SAKIII-3098, which is about making the 
> left hand navigation keyboard accessible.
> Should we make the entire navigation selectable via tab and then use 
> the keyboard arrows to move around or should we be doing something 
> else?
> 
> Any input would be extremely useful,
> 
> Thanks,
> Nicolaas
> 

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

Eli Cochran
project manager, CalCentral project
manager of user experience design
Educational Technology Services, U.C. Berkeley

"Progressive Enhancement: An escalator can never break, it can only become stairs."
    - Mitch Hedberg