Tuesday, November 10, 2009

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:

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
Posted by at No comments:
Subscribe to: Posts (Atom)