Wednesday, April 29, 2009

Visual Cues for Keyboard Users, Higher Education Web Pages

AccessibleWeb@U - April 29, 2009
Present: Terrill Thompson, Bill Corrigan, Wendy Chisholm, Chris Whip, Dylan Wilbanks, Ryan Benson, Karen Rosenstiel, Rick Ells

Quick Items

  • We need a larger meeting room for our monthly AccessibleWeb@U meetings. MGH 015L is central, well equipped, free thanks to UW Technology, and usually available, but attendance has been up and we need more space. If you know an appropriate room we can reserve, or if your department is interested in sponsoring the AccessibleWeb@U meetings, please send a message to the rells@u.washington.edu or to the accessibleweb@u.washington.edu list.
  • May's AccessibleWeb@U topic will be "Creating Accessible Sites With Drupal." If you are interested in the topic and want to participate in the discussion as we develop the talk, send email to rells@u.washington.edu.

Visual cues for keyboard users

Ryan Benson demonstrated CSS methods for highlighting links when they have focus to help keyboard-only users know where they are on a page.
  • Most designers have some kind of highlighting when mouse users hover over a link, but do not provide highlighting for keyboard who tab to a link
  • CSS style could be
    a:hover, a:visited:hover, a:focus, a:visited:focus, a:active,
    a:visited:active { whatever style makes anchor clearly visible }
  • Highlighting effect for hover and focus can be different since hover is for mouseovers and focus is for keyboard users who tab through anchors.
  • IE behavior for focus different

    • Focus works on most browsers, active is what works on IE


  • Border of an anchor that wraps looks broken - border is open at end of one line and beginning of next line

    • Could add more padding so that the text can wrap within the anchor
    • Could enclose anchor in a div and put the border on that


  • Dan Comden prefers use of a border instead of a background for the focus effect because other access technologies use a border to highlight your location on a page.
  • Keyboard users could have their own stylesheet with styles for their particular needs

    • Wayne Dick offers stylesheets for people with disabilities http://www.calstate.edu/Accessibility/webaccessibility/evaluation/lowvis.css


  • How visible should the border be

    • Strong or dark color?
    • Subtle color?
    • Looking for an effect that is not jarring to non-keyboard users but works well for people who are keyboard users


Longitudinal Research Project Looking at Home Pages of Higher Education Institutions - Terrill Thompson

Terrill is looking at Higher Education home pages as a followup to a study he conducted in 2004-2005.

Issues

  • Alt tags for images; Menus built with images that have no alt text become unnavigable if images cannot be displayed

    • DreamWeaver now prompts for alt text
    • Evaulation Method: Used Web Accessibility Toolbar (WAT) on IE http://www.paciellogroup.com/resources/wat-ie-about.html to generate a list of images and their alt texts; critiqued the use of alt texts for meaningful texts, proper use of null texts. (A similar toolbar is available for FireFox at http://firefox.cita.uiuc.edu/)
    • Survey of alt text usage in 2004-05 was 27% proper; current survey found rate of proper use has risen to 41%


  • 'Skip Navigation' link

    • Western Washington University (http://www.wwu.edu/) has a 'Skip to News' link
    • Skip-to's usually are styled to become visible when they have focus
    • How many skip links do you want (Skip to menu, skip to content, skip to news)? Too many skip-tos become a menu to the page content structure.
    • Many people do not know that some browsers have skip navigation built in (such as skipping to headings)

      • Good heading structure helps meets the need for people finding different parts of the page, even if there are no skip-to links


    • Evaluating Coded Navigation (navigation within the page)

      • Used WAT to show internal links, display heading structure
      • In 2004-05 7% had skip to content; In current survey 19% of home pages had skip to content
      • 'Skip to Main Content' is apparently the preferred phrasing
      • In current survey 45% of sites are correctly using html headings (using headings in logical structure way)




  • Navigation

    • Evaluation - Using IE, mouseover controls to see if there are dynamic behaviors, is there a visible effect to help mouse users, is there a visible effect for keyboard users
    • Menus created with Javascript may not be identified as links in assistive technologies
    • In original study, 78% if pages were keyboard accessible; in this study 65% were keyboard, if visual focus is not considered
    • 13% of sites provided visual focus for keyboard users
    • 39% of home pages have dynamic scripted menus; often implemented without evaluation of accessibility impacts


  • Use of Flash

    • Can be accessible, if you know what you are doing

      • Go to an object, press Shift-F11, enter label


    • JK Rowling site: http://www.jkrowling.com/accessible/en/ Entirely done with Flash. Nice accessibility features

      • sounds have accompanying texts
      • clues of what to do next
      • accessibility tools, gives keyboard controls for JAWS, WindowEyes
      • exploration model, lots of stuff that you can explore


    • Not so good Flash example

      • Lower Columbia College http://lowercolumbia.edu/ Has nav with buttons buttons to advertise events, but does not say what ad you get to if you click a button. Lots of buttons, no labels


    • In this study, 38% of home pages included Flash; only one site labelled the objects (Lane Community College http://www.lanecc.edu/) but the pages lack a heading structure


Summary

  • Fewer than half of web pages are accessible by any measure
  • Accessibility is improving in some areas (alt texts, headings, validation)
  • Accessibility is getting worse in other areas (navigation)

Discussion

  • Navigation accessibility problems often appear when site uses packaged menu scripts and (1) selects a package not designed for accessibility, (2) improperly configures the menus even if it is, or (3) breaks the accessibility features as the menus are evolved over time.
  • AccessibleWeb@U could hold sessions on accessible menus, accessible use of Flash and SilverLight, and creating accessible sites with content management systems.