Note: This document is a draft [see change log in progress] and should not be referenced or quoted under any circumstances. This document is under development by the Education and Outreach Working Group (EOWG), and will be offered to other W3C groups and the public for review.
Introduction
- short description of the content and scope of the document
- information about how this document relates to other WAI resources (e.g. Evaluation Suite)
- possibly overall concepts and considerations in sub-headings as necessary (for example, why text-only sites are often not a good solution)
Fixing the Cause of the Barriers
This section talks about repairing parts of the Web site that cause accessibility barriers rather than repairing the output these parts produce. This is typical for dynamically generated Web content but also applies to some static content (provided there is some sort of commonality in the development).
Settings and Configuration of Authoring Tools
- looking for accessibility features in authoring tools (especially editors and content management systems)
- note that these are sometimes not turned on by default or need to be installed separately
- link to the document Selecting and Using Authoring Tools
- suggest adopting and using more up-to-date software that have better suport for accessibility
Templates and Web Server Configuration
- impact of templates and importance of understanding how they are fitted together to generate content
- server-side configuration and customized error messages as part of the Web site or application
- server-side scripts and applications can sometimes be easily modified to generate better content
- database and other infrastructure (e.g. application server) also need to support accessibility
Enhancing and Upgrading Page Markup
- rolling in CSS as linked resources rather than hard-coded within the HTML markup of the Web pages
- mentioning that code snippets are often repeated several times throughout a Web site (e.g. navigation bars)
- making use of patterns and habits for coding structures (tables, lists, etc.), images (icons, buttons, etc.), and scripts
- cleaning up and enhancing page code (possibly making it valid) using validators and tools such as "HTML Tidy" etc.
Raising Awareness and Training Developers
- main focus on content authors as they are usually biggest contirbutors to Web sites after they are launched
- reiterating how authoring tools and evaluation tools can simplify the tasks of the developers
- highlight the need for raising awareness amongst developers and link to Planning Web Accessibility Training document
Prioritizing Content for Repair
- This section describes some approaches to prioritize the content for repair. It highlights some aspects under which priorities can be set. These factors can be cascaded depending on the amount of content to repair. An example of cascading these factors could be: first take all the frequently accessed pages and start with the barriers that have the highest impact on accessibility.
Accessibility Barriers with Higher Impact
- link to the Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 and describe the priority levels
- some repairs may have a higher impact on the overall accessibility even though their relative WCAG priority may be lower (for example fixing frames, navigation bars, drop-down menus, etc)
- discourage from repairing content for specific disabilities but to look at the requirements as a whole
Content that is Frequently Accessed
- use server logs to track the frequency under which pages are accessed and start with the most popular ones
- use server log tools to identify paths that users commonly take through the Web site as well as other information
- usability studies can clarify how a Web site is used and to give feedback on the information architecture
Content that has Significant Importance
- some pages may have "special importance" for disabled users (for example search facilities, site index, contact page, etc)
- data tables, charts, forms, or other parts of the site may contain the most vital information for all users
- social responsibility that may apply to specific sections of a site (for example "job announcements" etc)
Logical Groups of Related Resources
- sequence of pages required to commit a transaction, for example all pages required to purchase a product
- articles, data, or information that spans more than one page (for example results of the latest poll)
Evolving and Extending Accessibility Features
Once the most important barriers are removed, experienced developers (with respect to Web accessibility) may want to start thinking of enhancing the accessibility features on their Web site. This mainly includes implementing some of the WCAG checkpoint that have lower priority and possibly carrying out usability studies with disabled users. Mention the benefits of using advanced technologies such as XHTML, SVG, or advanced CSS features (Level 3?) that provide more possibilities to accommodate accessibility requirements.