> EOWG Home Page

Requirements for Before/After Site

This is an outdated draft. The latest version is available at http://www.w3.org/WAI/demos/bad/.

Purpose

• Demonstrate typical accessibility problems encountered on Web sites and how they can be corrected
• Demonstrate how an accessible Web site can look at least as good as an inaccessible one
• Demonstrate effective use of an evaluation process & report, with reference to the bad site
• Demonstrate effective planning for repairing a site
• Increase awareness of and encourage people to use the Evaluation Resource Suite and the Retrofitting document
• Increase awareness of the techniques documents and online curriculum
  

Audiences (and their specific purposes)

• Web designers and developers, so that they can see well-designed pages that work well in accessible as well as in inaccessible mode
• Evaluators of Web site accessibility, so that they can see how a precise evaluation should tie in very closely to every element of the bad site
• Web accessibility trainers, so that they can have clear examples of bad and good sites to show trainees
  
• Regulators, managers, and other decision-makers, so that they can see the feasibility of the accessible site
• People with disabilities and other advocates, so that they can advocate for the difference and the feasibility of the accessible site
  
• Authoring tool and evaluation tool developers, so that they can see what their tools should be producing or checking
  

Approach

• Work on it through a task force
  
• Get EOWG review of requirements
  
• Gather existing old & partial bad/good sites
• Develop more extensive list of requirements for how to present the resource, and barriers to demonstrate
  
• Code it
• Explain it
• Prepare an evaluation report
• Prepare a retrofitting plan
  
• Make sure it is extensible if additional bad/good transformation sites become available in the future
• Make sure that EARL reports can be added in the future
  
• Get EOWG review of draft site
• Edit
• Release

Scope

• Keep the "bad" and "good" sites limited in scope, no more than 4 pages each, and don't try to show all barriers
• Keep the narrative explanation focused and concise
• Do only one "demo" site at first, though make sure that the series can be expanded with later contributions

Name

This section needs more brainstorming...

• Would be better to have something more appealing than "Before/After Web Site Demo" or "Bad/Good Site"
• Need brainstorm on this "Site Transformation"? "Transforming Your Site"? "Web Accessibility Makeover"?
• Or... transforming your site for accessibility
  

Structure

1. Overview Page
   1. describes purpose and contents of resource suite
   2. gives very brief outline of the process, with annotated pointers to the sub-pages
   3. provides pointers to related WAI resources (e.g., Evaluation Resource Suite; Retrofitting Web Sites for Accessibility; etc.)
2. Bad Site ["Inaccessible Site"] -- four pages in all, as follows, in HTML
   1. Navigation Page (NAV)
      • Frames use fixed pixel sizes to define layout
      • Links are not structured using lists or other elements
      • Links are actually javascript functions (instead of using events)
      • Roll-over effect is provided through the scripts (not through CSS)
      • Client-side image map w/ no alt or areas
        
   2. Welcome Page (HME)
      • Company logo has wrong alt attribute (for example explaining the contents of the logo)
      • Name of the Web site as text-image and not marked as h1
      • Pictures without alt attributes or longdesc descriptions
      • News items with "click here" type of links
      • floating DIVs for layouting with absolute sizes and bad reading order
      • News items do not linearize well through the DIVs structure
      • Page has invalid HTML code (missing DOCTYPE etc)
   3. Data Page (DAT)
      • One or two tables with different complexity
      • Table markup is wrong (for example no headers, summaries, etc)
      • Incorrect usage of TDs that render visually but not on some ATs
      • One or two Figures/charts with no alt or longdesc attributes
      • (Wishlist: sound or video file explaining content but has no transcription/captions)
   4. Forms Page (APP)
      • Misused labels (for visual effect or for one of a group of controls not marked as fieldset)
      • Input controls aligned using fixed size layout table
      • Input controls and captions do not linearize well
      • Submit is done through javascripts functions
      • Error messages ask to fill inputs marked with red
      • Error messages are difficult and confusing
3. Evaluation Report on Bad Site
   1. Would reference the Evaluation Resource Suite
   2. Would be formatted according to the Template for Accessibility Evaluations
   3. Content could include: moving up to XHTML once CMS supports it
      
4. Retrofitting Plan for Bad Site
   1. Would reference Retrofitting Web Sites for Accessibility, the techniques documents and the online curriculum
      
   2. Would list a brief retrofitting plan for the site, listing priorities, order of repairs, etc
   3. Content could mention stages, including later move up to XHTML
      
5. Good Site ["Accessible Site" or "Retrofitted Site"] in HTML
   1. Would be the same set of pages and same default appearance as the "bad site" above
   2. Would implement all the recommendations in the retrofitting plan, above

Editors: Judy Brewer, Shadi Abou-Zahra

Last updated: 1 July 2005