Using Free Voice Browsers to Evaluate Web Sites

January 28, 2010

Topic: Using Free Voice Browsers to Evaluate the Accessibility of Web Sites
Speaker: Wendy Chisholm, Technology Research Consultant, DO-IT
Date: Thursday, January 28, 2009
Time: 11:30a.m. - 1:00p.m.
Location: Allen Auditorium

Wendy Chisholm demonstrated the use of two free voice browsers, WebAnywhere (http://webanywhere.cs.washington.edu/wa.php) and NVDA (http://www.nvda-project.org/) to evaluate the accessibility of Web sites.

• NVDA
  • Non Visual Desktop Access (http://www.nvda-project.org/)
    • Documentation is at http://www.nvda-project.org/wiki/Documentation
  • Runs on Windows
  • Free to download
  • Using FireFox 3, has support of ARIA
    • On sites that use ARIA, Firefox and NVDA can communicate on what is on the page
    • ARIA - Accessible Rich Interface Application (http://www.w3.org/WAI/intro/aria)
      • Useful when using Javascript to define roles
      • By using ARIA in setting up a Javascript-based menu, can have standard interaction practice (moving around in menus with arrow keys, leaving menu with ESC, etc.).
  • NVDA is in active development
    • ARIA features are comparable to those in JAWS and WindowEyes
  • Users have many different techniques for using a voice browser on a page
    • Can configure NVDA to set how much information it should give you about each element you visit (clickable, etc.)
      • Useful to get maximum information when you are developer, but may want less info when just browsing
    • At any time a user can hear the headings on a page; each time you press H you go to the next heading
      • Page developers can negate the headings feature; often headings are created just visually, not as h-elements, so not recognizable as headings
    • Can jump down through lists on a page; press L to go to next list
    • For sighted users (such as people with dyslexia) using mouse, NVDA speaks elements as the user mouseovers them
    • Text must be in markup to be read; NVDA cannot read text in graphics
  • Reads ALT tags on graphics
  • Does not seem to have a way to highlight element that currently has focus
  • Can select among various voices for the voice synthesizer
• WebAnywhere
  • Located at http://webanywhere.cs.washington.edu/wa.php
    • Can be used from anywhere you have a Internet connection to view most sites
    • WebAnywhere is a proxy; your connection to a site is routed through WebAnywhere, processed, and the result passed to your browser
    • WebAnywhere can't do Flash, yet
    • WebAnywhere can only communicate with what the browser gives it through the DOM
  • Wendy is working on the team continuing to develop WebAnywhere
    • Feature set is fairly simple
    • No ARIA support yet
  • Designed to make it very obvious where you are on a page
    • Creates high contrast, large font experience
    • Very nice for demonstrating to people what is happening when a person is browsing a Web page with a voice browser
  • Most of the WebAnywhere features are in NVDA, but NVDA has many more features
• General Discussion
  • On search fields that offer multiple scoped searches, why do we always put radio buttons for selecting which search below the search field; to use it you select which search and then put text in the search field, but the code is in the opposite sequence
  • Enough people are using headings within their Web pages that it is becoming a common way to navigate people using screen readers navigate pages
    • Most Web design is based on Graphical User Interface (GUI); we do not have a Audio User Interface (AUI) set of concepts articulated yet (We need a grad student to pull together a AUI)
  • NVDA is rapidly gaining popularity; the hope is that people will use NVDA use it instead of JAWS, which is expensive.
  • VoiceOver on Apple stuff
    • VoiceOver on the iPhone is very good, one of the best AUIs out there; http://www.apple.com/accessibility/iphone/vision.html
    • VoiceOver on Macs is also very good; http://www.apple.com/accessibility/voiceover/
• New Toolbar
  • E.A. Draffan invites us to try the JISC TechDis Toolbar; http://access.ecs.soton.ac.uk/ToolBar/
  • Available as a downloaded app or as a temporary toolbar you can load anytime by going to a URL
  • Speaks with a Scottish accent

Evaluating Content Management Systems

October 22, 2009 AccessibleWeb@U meeting notes, prepared by Rick Ells

Following the morning's presentation by the Content Management System Working Group at the Web Council meeting, it seemed appropriate for the topic of today's AccessibleWeb@U meeting to be a quick assessment of the accessibility of UW sites discussed in the presentation.

Criteria

Evaluations were done with the FireFox browser equipped with the Web Developer Tools add-on (WDT). In addition, the UW HTML Tidy Web Interface and the Paciello Color Contrast Analyzer were available.

Criteria	Explanation	Procedure (most involve using Web Developer tools)
Presence of Skip to Content or similar method	Help non visual or mouse only visitor get directly to page content	By tabbing and by inspection of page HTML
Use of semantic heirarchical headings to identify page topic, subtopics, subsubtopics, etc.	Voice browsers often can use headings to navigate page	WDT: "Outline -> Outline Headings" and "Information -> Display Element Information"
Linearization,. does sequence of page content make sense to a person encountering the content linearly?	When using a voice browser or navigating a page without a mouse, the sequence in which content will be encountered can determine whether the page is usable.	WDT: "CSS -> Disable All Styles" Turn off CSS and evaluate what displays
Use of semantic markup to enable more meaningful interpretation of content	Semantic element types (paragraph, heading, list, etc.) can be used to better present and navigate through the content.	Visual inspection of content HTML. WDT: "View Source"
Keyboard navigable - Can you effectively navigate the page content without using the mouse	A person with limited dexterity or poor (or no) vision will not be able to use the mouse. Can they still use the site?	Set aside the mouse and try to navigate through site content just using the tab, arrows and space keys
Focus highlighting to make it apparent which element has focus is on the screen	A person navigating without a mouse has to tab to the link they want. Without focus highlighting, knowing where the focus is can be difficult.	Tab through the pages trying to identify where the focus is
Menu functionality without using mouse	Menus that require use of the mouse to select are unusable by people who have vision limitations or dexterity problems	Attempt to navigate menus using tabs, arrow keys, and cursor
Validated HTML	Syntax errors in HTML can produce unpredictable behaviors in assistive and adaptive technologies, not to mention CSS and scripts	Process page with a validator or HTML Tidy
Alternative text associated with graphics, particularly when graphics are used as buttons	Alternative text is displayed or read when the graphic itself cannot be displayed or seen. Purely decorative images can have empty ALT attributes (alt="")	WDT: "Images -> Display Alt Attributes"
ALT Text and Visible text congruence	Voice controlled browing is becoming common. If the text on a graphical object (for example, "Contribute Today") is different from the ALT text for the object ("Give by Friday") the user has no way to go directly to that object.	WDT: "Image -> Display Alt Attributes" and compare text in the graphic to ALT text
Contrast of color combinations	Contrast between text and background should be at least 4:1 for it to be readable by most people. A higher contrast is even better	Evaluate with the Color Contrast Analyzer

Our Procedure

At our October 22 meeting we visited seven Web sites mentioned in the panel presentation, walking through the above criteria with each. The sites visited were the following:

• http://www.uwb.edu/ - University of Washington Bothell home site (CMS: Kentico)
• http://www.foster.washington.edu/ - Foster School of Business home site (CMS: Sharepoint)
• http://wiaproject.org/ - World Information Access project (CMS: WordPress)
• http://ethnomed.org/ - EthnoMed site - Integrating cultural information into clinical practice CMS: WordPress)
• http://www.rad.washington.edu/ - Department of Radiology home site (CMS: Plone)
• http://engr.washington.edu - College of Engineering home site (CMS: Drupal)
• http://f2.washington.edu- UW Finance & Facilities home site (CMS: Drupal)

Important!

The critiques below relate to specific implementations done on the CMS systems, not necessarily to the CMSs themselves. Most CMSs offer many themes, skins, CSS stylesheets, and templates that have widely varying degrees of accessibility. All of these sites reflect a large amount of careful, professional work, often done under considerable time pressure, and we have deep respect for their work. The goal here is to highlight the issues in selecting among all those alternatives for your CMS.

How Did We Do?

• General observations
  • Implementations of Skip-to-Content links varied greatly. The Engineering, Radiology, EthnoMed, and Bothell sites had Skip-to-Contents (EthnoMed and Radiology also defined access keys). The WIA and Foster sites did not have any Skip-to-Content implemented in their headers.
  • Use of semantic heirarchical headings was spotty. The WIA and Engineering sites made good heirarchical use of headings. The Facilities site was inconsistent in its use of headings across pages within the site, with some pages have good h1-h2-h3 heirarchies, some having all h1 headings, and some having no headings in their content.
  • Linearization was good (you could generally view the content only and make good sense of what was going on) but the sites tend to have large amounts of navigation in their headers that would have to be tabbed through if no Skip-to-Content link is provided. The Foster site uses tables for layout, but only at a simple level, providing reasonable linearization.
  • Use of semantic markup varied. The Drupal, WordPress, and Kentico sites made reasonable use of a variety of semantic types. The Foster site pretty much only used tables and unordered lists, with most other content being enclosed in divs identified with the site's own arbitrary system of id and class names.
  • Keyboard navigabiity varied greatly, with several sites have black holes that would swallow anyone trying to use the site without a mouse. In the Foster site, scripting relies on mouseover events. No allowance is made for onfocus events. The EthnoMed and Radiology sites had a common problem: As you tab into the page you reach the Search button. When you trying to tab beyond the search it evokes the search producing a Live Search pop-up box that you can't get out of with just keyboard commands. Search should only be evoked with a Return, not with a Tab.
  • Focus highlighting is turned off on the WIA and Bothell sites (which is done with outline:0 or outline:none styles on anchors), making them difficult for people navigating without a mouse or by voice command to know where they are on a page. The other sites all had focus highlighting on.
  • Menus were variable. Those menus built with simple links worked well. Menus involving scripted or CSS pulldowns had shortcomings. Engineering's menus are almost keyboard navigable, but not quite. Engineering and Foster both have menu systems that work for mouse users but not so well for no-mouse people. Both however have maintained consistent structure within each of the topics so that the items in the left nav of a topic page are the same was in the pulldown menus for the topic. Both sites can therefore be navigated nicely without using a mouse. In that sense you could consider their approach a good example of progressive enhancement methods.
• Recommendations
  • The importance of Skip-to-Content links: Evaluating the sites did make clear the fundamental importance of Skip-to-Content links as the first links on the page. Many of these sites have large sets of navigation links in their headers (one has more than fifty links in its system of pulldown menus). A keyboard user would have to click through all fifty ON EVERY PAGE to find the page content.
  • Focus highlighting is important: Turning off highlighting makes it hard for keyboard and voice command users to know where they are on the page. We are designing dynamic interfaces here, not hardcopy books.
  • We can do better on menus: Good accessible menu systems are available out there that we can use in our CMSs. A good example of a progressive enhancement menu system that works well without a mouse is the Yahoo User Interface library's "Website Top Nav With Submenus Built From Markup" at http://developer.yahoo.com/yui/examples/menu/topnavfrommarkup.html