Building an Acessible Site From the Ground Up

AccessibleWeb@U Meeting Notes, March 25, 2009

• Building an Accessible Site From the Ground Up
  
  • Goal is to create a new Web site for the Development & Behavioral Pediatrics, currently at http://depts.washington.edu/dbpeds
  • Current site was developed by Dr. Samuel Zinner
    
    • The site built on SimpleSite, which is going away, prompting the need to build a new version.
    
    
  • Want an improved site
    
    • More usable
    • More visually pleasing
    • More compliant to ADA
    • Take into consideration people with cognitive disabilities
    • Sites Dr. Zinner likes
      
      • http://youthhood.org/
      • The http://dictionary.com/ family of sites
        
        • In set of sites, each has a different color
        • Each page is entirely viewable without scrolling
        
        
      • http://cshcn.org/ - Children with Special Needs
      
      
    
    
  • Development work on the site will be done by Yuka Tsukamaki and Preethi Dutta, graduate students of the U.W. Information School, as part of the Capstone program (http://www.ischool.washington.edu/msim/capstone/)
    
    • Working with Yuka and Preethi are Faye Louie (CHDD) and Seiya Urae (Medicine)
    
    
  • The current site has many links in the left column. Key features of the site are the following:
    
    • Clinics and Activities
    • Schedules
    • Advocacy Opportunities
    • Training Modules at other sites
    • Featured Articles
      
      • Commenting on how press has spun stories, linking to more valid articles
      
      
    • Resources for Community
    • Screening & Surveillance Tools
      
      • Want to teach physicians better earlier screening and identification
      • Some are copyrighted, protectd by password
      
      
    
    
  
  
• Discussion
  
  • Find out how the current site is being used
    
    • Catalyst system gives you number of site visits but not page stats
    • People not necessarily going through home page
    • 2/3 of School of Public Health site visits do not go through home page
    
    
  • Could add Google Analytics (http://www.google.com/analytics/) to the current site to collect data until the new site is built
    
    • Requires adding Javascript at the bottom of each page you want to collect visit data on.
    • Goal is to find out who actually is visiting the site and what they are looking at
    • Google Analytics not only gives page visit counts but also gives breakdowns of who is visiting
    • Who is your real audience at present? How does the current audience compare to the audience you want to reach?
    
    
  • Evaluate your content
    
    • What are the unique things people might look for on your site?
    • How good is your site technically. For example, are there dead links?
      
      • Xenu's Link Sleuth (http://home.snafu.de/tilman/xenulink.html) is a free tool that can check links
      
      
    • How well written, edited, and polished is your content
      
      • Is the style consistent throughout the content?
      • Is there consistent voice and role in the writing?
      
      
    
    
  • Define the purpose of site
    
    • Be clear about priorities and audiences
      
      • Work on a statement of Priorities and Audiences; put it in writing, pass it around
        
        • Clarify what parts of content are for the department and what parts are for outside audiences (audiences, therapists, parents)
          
          • Separating departmental/staff content from content for outside audiences might be a basic concept in your design
          
          
        • What types of user needs do you most want to support
        • Articulate priorities and rank them relative to each other
        
        
      
      
    
    
  • State any considerations
    
    • Do HIPAA health information privacy laws apply (http://www.hhs.gov/ocr/privacy/)?
    • Intellectual property ownership
      
      • Is any content on the site copyrighted? Do you have permission to distribute the content (you do not need permission to just link to things on other sites)
      
      
    • Privacy
      
      • Doctors' schedules; can they be public?
      • Doctors' contact information; can it be public?
      
      
    
    
  • Assess the resources available to maintain the site
    
    • How much manpower will be available to maintain the site once it exists?
      
      • About four people maintain the content of the current site. All four have lots of other things they are involved in.
      
      
    • What implications does the amount of manpower have on what you want to try to do in building the site?
    
    
  • Consider a Content Management System
    
    • Drupal (http://drupal.org/) is used by many groups at the UW, including Facilities
      
      • Free, has a good, active support community
      • Relatively simple to install, comes with a variety of designs (themes) which can tweaked easily
      • Drupal can be installed and run on the depts.washington.edu server
        
        • Instructions are at http://www.washington.edu/computing/web/publishing/drupal.html
        • Requires MySQL, which is also available on the depts server (http://www.washington.edu/computing/web/publishing/mysql.html)
        
        
      • Drupal is not a centrally supported service. Once it is up your are on your own to maintain it
        
        • Periodically updates must be installed
        
        
      • Several groups on campus can do Drupal themeing
        for you (for a fee)
        
        • UW Creative + Communications; http://www.washington.edu/admin/pubserv/
        • UW Creative; http://www.uwcreative.com/
        
        
      
      
    
    
  
  
• Designing a Web site for people with special needs
  
  • Good accessible design resources at on the UW IT Accessibility site at
    http://www.washington.edu/accessibility/
  • Topics
    
    • Font size
      
      • Flexible web page designs (sizes and dimensions are set with relative measures such as percents and em-spaces) allow the user to adjust the font size to what is comfortable for them
      • Fixed font sizes, especially if the size is small, can be a big obstacle
      
      
    • Colors
      
      • Be wary of red/green color combinations; 10% of men are red/green
        color blind. You can check color combinations with VisCheck (http://www.vischeck.com/)
      • Provide sufficent contrast (at least 5:1) of words on their background. You can evaluate the contrast of color combinations with the Colour Contrast Analyzer (http://www.visionaustralia.org.au/info.aspx?page=628)
      
      
    
    
  • Basic steps
    
    • Choose a version of html or xhtml and stick to it
      
      • We suggest XHTML
      • Write to the standard, not to a specific browser
      
      
    • Write compliant code; code that is correct according to the version of html/xhtml you are using. Validate your code frequently as you work on it.
    • Use semantic markup; XHTML has predefined logical element types such
      as paragraph, h1 headings, and ordered lists. Using these elements as they are intended to be used means each block of text has a declared logical type that can be help assistive software interpret the page and present it intelligibly to the user.
    • Use a simple page structure; pages are made up of a number of divisions such as header, left-column, content, right-column, and footer.
    • Separate content from presentation; put page content into semantic xhtml and control presentation on the page with CSS stylesheets
    
    
  • Methods
    
    • Avoid opening in new window
    • ALT tags on each graphic, alt="" (an empty ALT) for non meaningful graphics
    • In forms, use LABEL to relate titles to form fields
      
      • See
        http://www.webaim.org/techniques/forms/controls.php
      
      
    
    
  • Cognitive disabilities
    
    • General information is available from WebAIM http://www.webaim.org/articles/cognitive/
    • Spacing between lines can help readability; tight text and long text
      lines can make reading difficult
    • Addressed in Web Content Accessibility Guidelines v.2 (WCAG2)
      http://www.w3.org/TR/WCAG20/
    • Use of language; use simple language with words with few syllables
      
      • Good guidelines on simple writing are on the Plain Talk Web sites
        
        • http://www.accountability.wa.gov/plaintalk/ptguidelines/ and http://www.plainlanguage.gov/
        
        
      
      
    • Use ABBR element (http://www.w3schools.com/tags/tag_abbr.asp) to spell out what an abbreviation stands for, text appears when you hover over the abbreviation
    • Different parts of site may be developed for different audiences, with different vocabularies
    
    
  
  
• Search engine optimization
  
  • Meta elements (http://www.w3schools.com/tags/tag_meta.asp) in Head of a Web page helps searches recognize what the page is about, but you want to have the right vocabulary and not too much of it
    
    • Google Search penalizes pages with too many Meta words, particularly if they repeat
    
    
  • Recognize that Headers (h1, h2, h3, etc.) have significance to assistive technologies, which will interpret
    them as the topic, subtopic, subsubtopic, etc. of the page content
    
    • Voice browsers allow the user to navigate the page by the headers. Logical headers help the user go quickly to the content they are looking for
    
    
  
  
• Common problems
  
  • Pages do not have navigation; not clear who owns it, what context it is in
    
    • Have information in page, such as in the header
    • Identification does not have to take up much space; a linked logo in an upper corner may be sufficent
    
    
  • Important to have consistent layout so people have an idea of what to expect
  • Important information is only in graphics, such as PowerPoint slides; have the information in the page HTML too.
  • When people print a page, is it readable; have a print stylesheet that formats it for hardcopy use
    
    • Be sure the printout has the URL of the page
    
    
  • Drop down menus can be inaccessible
    
    • There are methods for doing drop-down menus that are accessible and methods that are not accessible
      
      • Generally the most accessible drop-down menus use progressive enhancement coding techniques, such as the Yahoo User Interface (http://developer.yahoo.com/yui/menu/)
      
      
    • How do people with cognitive difficulties work with menus is an open questions; research needed!
    
    
  
  

WebAIM Screen Reader Survey

Many of you know WebAIM (Web Accessibility in Mind) as one of the most complete and best maintained sources of good information on accessible design topics. In December and January, WebAIM conducted a survey of preferences of screen reader users relating to Web design and Web technologies. The survey collected 1121 responses from people with various disabilities. See WebAIM: Screen Reader Survey Results I found the results to be quite useful:

• Headings really are important: "It is clear that providing a heading structure is important to screen reader users with 76% always or often navigating by headings when they are available." 90% of the expert users used headings always or often.
• Site maps were not particularly useful: "The majority of respondents seldom or never use site maps."
• Pop-up windows are difficult for less proficient screen readers to deal with. More proficient users had much less difficulty.
• Photos should be identified as such in their alt text, rather than just described with brief text: "It was very clear that the vast majority of screen reader users prefer to have photos identified as such. Interestingly, those that do not have a disability were three times more likely to prefer the briefer alt text than those that do have a disability."
• Flash is difficult for screen reader users: "71.5% of screen reader users reported that Flash is difficult while only 14.2% reported that it is easy."
• Frames are not that big of a problem. "While the majority (58%) of users reported that frames are easy, those that are blind were 3 1/2 times more likely to indicate that they are easy than those with no disability."

Clearly, Web accessibility evaluator's rules of thumb (i.e., Frames are not accessible) can be simplistic or misleading . I encourage everyone to read through these results carefully. And I would like to send a hearty thanks to WebAIM for conducting the survey!