AccessibleWeb@U — June 25, 2009

• Special thanks to Christine Tawatao and University Libraries for making the Allen Auditorium available for our meetings. The Auditorium is reserved for AccessibleWeb@U the fourth Thursday of each month, 11:30am to 1:00pm.
• Projects
  • Dylan looking into use of ARIA in pulldown menus. Hopes to be able to report by Fall
  • Dan interested in testing scripting packages, such as menus, with JAWS

---

Making Accessible Drupal Sites

Rick Ells UW Technology

About Drupal

• Standards Based; xhtml, css, PHP
• Large user community
• Many templates to choose from
• Many modules to choose from

Drupal Is Cool

• Centralized management
  • Templates and modules
  • Styles
  • Scripting
• Content creation, editing, and maintenance can be done without technical Web knowledge
• Changes in styles, layout can be done across the site without content maintainers involvement

More Cool

• Information management
  • Categories
  • Taxonomies
  • Keywords
• Navigation structures generated for you
• Easy to add Web2.0 features

Even More Cool

• Authentication, roles
• Workflow
• Customization based on default designs, templates, styles
  • Intercepts, overrides, and subthemes

Being Accessible

WCAG 2.0 Guidelines

• Perceivable
• Operable
• Understandable
• Robust

Web Content Accessibility Guidelines (WCAG) 2.0 http://www.w3.org/TR/WCAG20/

Accessible Design Efficiency

• Templates, stylesheets, modules can address many aspects of accessible design
• Content authors and editors do not have to know as much about?
  • Skip to content
  • Font sizing
  • Color choices
  • Labeling, Alt texts
  • Semantic markup
  • Page layout

Steps to Accessible Design

1. Install
2. Update
3. Select theme
4. Add modules
5. Build blocks
6. Apply your design

1. Install

• Installing Drupal http://www.washington.edu/computing/web/publishing/drupal.html
• SQL Database http://www.washington.edu/computing/web/publishing/mysql.html

2. Update

• Updates are essential
• Each time the administrator logs in Drupal will display messages of needed updates
• Do them promptly

3. Select Theme

Tables or tableless?

• Tableless layouts best, especially if fluid
  • Controllable with CSS
  • Reading order can be independent of layout position
  • Fluid sizing allows scaling by user as needed
• Table layout not so good
  • Imposes reading sequence
  • Presentation only somewhat controllable with CSS
• Nested tables bad
  • Navigation nightmare
• Many theme design philosophies, which is why so many themes are available

Managing Themes

Accessible Themes

Box_grey Theme, Blue Bars Theme, Blue Lake Theme, Celju Theme, Clean Theme, CWS Theme

The Eleven Most Accessible Drupal 6 Themes http://openconcept.ca/blog/mgifford/function_assessment_of_valid_drupal_6_themes

Theme Problems

• Non-nested use of h-elements
  • One h1 per page; main topic
  • h2; subtopics
  • h3; subsubtopics, etc.
• Inconsistencies among modules in how headings are done
• Deeply nested tables
• Not specifying default language

4. Add Modules

• Hundreds of modules are available
• Offer a wide range of functionality
  • Editors, games, feeds, tools
• Most are standards compliant
  • Problem: Inconsistent implementations among modules
• Frequently updated

Managing Modules

5. Build Blocks

• Blocks contain the code fragments for the different areas of your layout
• Blocks are placed in page regions
• Must be well-formed and strictly compliant to fit in context
  • Structured, semantic markup very desireable to get CSS to work
• How you add things like "Skip to Content"

Semantic Markup

• Use elements according to their logical type
  • Make headings with h-elements, not big bold paragraphs
• Properly nest h-elements
  • H1 is the main page topic, h2s are subtopics, h3s are subsubtopics, etc.
• Choose a content editor that makes semantic markup possible, even if you have to go into html mode sometimes

6. Apply Your Design

• Use subtheme, intercept, and override methods
  • Never modify original templates, stylesheets
• Customize templates
• Customize CSS
  • Layout adjustments
  • Color scheme
  • Font size
  • Contrast

Color Scheme

Color Selection

• Consider the colorblind; about 9% of men and 1% of women are colorblind in some way
• Wickline Colorlab makes it easy to see hour your color set will appear to people with different kinds of colorblindness — http://colorlab.wickline.org/colorblind/colorlab/

Color Scheme

Contrast

• 5:1 contrast ratio between text and background is recommended
• Paciello Group Color Contrast Analyzer can be used to quickly evaluate color combinations — http://www.paciellogroup.com/resources/contrast-analyser.html
• Minimum Color Contrast Ratio — http://www.joedolson.com/articles/2008/12/minimum-color-contrast-ratio-changed-in-wcag-2/

Maintaining Accessibility

Do

• Validate all modifications — be sure everything is strictly compliant
• Choose editor that makes semantic HTML
• Consider content flow in page structure
• Add aids such as "Skip to Content"
• Use semantic markup
• Use scripting libraries and methods that support accessibility

Don't

• Invent non-semantic elements (divs) when appropriate semantic elements are available
• Use fixed sizes
• Reduce contrast for artistic effect
• Put essential content exclusively in media
• Have visual media without captioning

Drupal Accessibility Activity

• Accessibility Group — http://groups.drupal.org/accessibility
• The Eleven Most Accessible Drupal 6 Themes — http://openconcept.ca/blog/mgifford/function_assessment_of_valid_drupal_6_themes
• Accessibility Best Practices in Drupal Theming — http://szeged2008.drupalcon.org/program/sessions/accessibility-best-practices-drupal-theming

Evaluating Your Drupal Site

• WAVE — http://wave.webaim.org/
• Functional Accessibility Evaluator — http://fae.cita.uiuc.edu/
• WebAnywhere — http://wa.cs.washington.edu
• Yellowpipe Lynx Viewer — https://addons.mozilla.org/en-US/firefox/addon/1944
• Wickline Colorlab — http://colorlab.wickline.org/colorblind/colorlab/
• Paciello Group Color Contrast Analyzer — http://www.paciellogroup.com/resources/contrast-analyser.html

Discussion

• Editors available for Drupal
  • A variety of editors are available as modules that are easy to add to Drupal.
  • FCKedit — http://drupal.org/project/fckeditor
  • YUI Ric Text Editor ‐ http://drupal.org/project/yui_editor

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.