Requirements and Changelog for Improving the Accessibility of Your Web Site

Page Contents

Changelog from first publication
About...
References
Changes & Notes
Archive Notes

Changelog from first publication

Changes 14 November 2011

Changed wording from WCAG 1.0 checkpoints and priorities to WCAG 2.0 success criteria and levels
Changed a few links to newer, more relevant resources
Websites -> websites and such

Changes 11 April 2006

made puncutation consistent
added under "Optimizing Your Retrofitting" an intro sentence: "The following tips on knowledge and skills, processes, and tools help optimize retrofitting; that is, make it more efficient."
Edited:
"The goal of evaluation before retrofitting is to define the accessibility barriers on your site and gather information to plan an efficient retrofitting project. Rather than thoroughly evaluating every page on your site, you can focus your evaluation on representative areas in order to get more valuable information with less effort. For example, templates, style sheets, and any elements that are the same across pages, such as navigation bars and footers, only need to be evaluated once and can then be skipped on pages where they are repeated. The priorities listed in the Prioritizing by Area section below also apply to focusing evaluation. Ensure that your evaluation covers each feature and functionality (for example, data tables, forms, scripts) from each developer or development group. Your evaluation can focus on specific points to help guide your retrofitting plan, such as determining if a particular accessibility barrier is widespread or isolated. For example, are all your data tables missing necessary markup, or just some? If only a few tables are missing markup, your retrofitting plan may need to add table accessibility to quality assurance (QA) processes rather than to training. However, if none of the tables are properly marked up, you may want to add that to your education plan. You might also find that tables from one development group are done properly, but from another development group have problems. This further clarifies where education is needed and not needed as part of your retrofitting project."
to
"
The goal of evaluating before retrofitting is to define the accessibility barriers on your site and gather information to plan an efficient retrofitting project. Rather than thoroughly evaluating every page on your site, you can focus on representative areas in order to get more valuable information with less effort. For example, templates, style sheets, and any elements that are the same across pages, such as navigation bars and footers, only need to be evaluated once and can then be skipped on pages where they are repeated. The areas listed in the Prioritizing by Area section below also apply to focusing evaluation. Ensure that your evaluation covers each feature and functionality (for example, data tables, forms, scripts) from each developer or development group.

Evaluation can focus on specific points to help guide your retrofitting plan, such as determining if a particular accessibility barrier is widespread or isolated. For example, if only a few of your data tables are missing necessary markup, your retrofitting plan would include adding table markup to quality assurance (QA) processes. However, if none of the tables are properly marked up, you would add data table markup to your education plan. If tables from one development group are done properly but from another development group are not, this further clarifies where education is needed."

About Improving the Accessibility of Your Web Site

(formally titled "Retrofitting Web Sites for Accessibility")

Purpose, Goals, Objectives

Answer the question: How do I tackle this big new thing -- that is, making my site accessible?
Help people who are overwhelmed by accessibility.
Explanatory material on retrofitting inaccessible Web sites, including information on approaches for fixing problems identified during a comprehensive evaluation of the accessibility of a Web site.
[have a report]

Audience for this Document

Web project managers
Web developers (programmers, designers, content authors, etc.)

Scenarios

I just received a directive from the sales department that we need to make our Web site accessible, whatever that means.
I just ran an accessibility evaluation tool and it gave me a boatload of errors. What do I do now?
I have this comprehensive evaluation report, now what do I do?
(Oh, and, btw, I have very limited time and money for retrofitting.)
...

Notes

Location in IA (information architecture)
- Location in Site Map: Under Managing Accessibility, Implementation Plan (at same level as Selecting Authoring Tools)
- Link to from: evaluation suite anno nav page (see also)?
- If/When later revise document, possibly link to under See Also link in http://www.w3.org/WAI/gettingstarted/Overview.html
"The only unique thing about retrofitting is prioritizing. Where do I start?" Shadi in EOWG minutes

Consider for next revision (or later version or related documents or other)

Headings & order: Consider changing the structure to eliminte (or at least reduce) the <h4>s.
- location: Optimising Process
  suggested revision: incorporate the H4 headings into the paragraphs
- location: Optimising Tools
  suggested revision: Drop H3 and make new H3s - Optimising Authoring Tools & Optimising Eval and Repair Tools
Consider changing the order:
- move "Acquiring Knowledge and Skills: up above Evaluating, and at the same level.
- change "Processes" to "More Tips" and move after Prioritizing
- <h2>Optimizing Tools
Consider:
location: Prioritizing the Repairs
suggested revision: We need to add something about the fact that there is no point in addressing issues on individual pages if the target activity is not kept in mind. If there is still a key page on a critical activity pathway that cannot be completed, then most of the effort in fixing related pages is wasted. We don't seem to make this point strongly/clearly enough
Consider: Pretending being an organisation that received a evaluation report from a accessibility evaluation service, with all accessibility problems listed and described I was puzzled with the section: "Evaluating to Identify the Issues
It is usually most efficient to first identify all of the accessibility barriers on your site."
It should be clear that above mentioned situation also can be the case.
"PWDs wouldn't want to do that" myth debunking - add near the important & frequently-used bit
Content important for PWDs. Add something like below to prioritizing by areas -- careful to word so as to avoid the "PWDs wouldn't be interested in that" myth
[content of particular relevance for people with disabilites]:
- Content that is particularly important for equal opportunity, such as job openings, [??, and legal information (such as terms and licenses)]
- Pages and functionality that might be particularly useful for people with disabilities, such as search, contact page, and site map
More on tools, perhaps:
<Some tools can be configured for improved accessibility support>
[Also, some things can be optimized for increased accessibility support on a specific Web site. For example, [???].]
[Check your authoring tool help to figure it out. |or| Ensure that your tool is configured for maximum accessibility support.]
General advice applies broadly: consider adding something about this applying to for small and large sites, probably in the introduction
Start from scratch or fix existing?: Consider addressing that question (answer: often two paths - fix some stuff right away and other stuff in redesign)
Development environment, Web server issues
- Configuring your Web server -
- server-side configuration and customized error messages as part of the Web site or application (e.g., better than generic error #)
- 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
Mentioning intranet: consider something like: "For example, if customers told you about an accessibility barrier that prevents them from using your external Web site, you probably want to fix that first. If you are legally required to meet a certain level of accessibility in your internal Web site ("intranet"), your target will be at least that level."
Identifying cause of problem. Want any of this in there?

[e]Determine the source of accessibility problems in your Web site in order to correct them now and avoid them in the future.

[Is the accessibility problem throughout your entire Web site, or just certain areas? Is the accessibility problem just a quality assurance (QA) issue (for example,just a few alt text equivalents are missing from images ("alt text"), or is is systemic (all image are missing alt text)?]

[What is the cause of the accessibility problem:
- Lack of an accessibility policy (that is, developers were not instructed
  to make the site accessible)?
- Lack of effective authoring tools?
- Lack of knowledge of the issues and solutions?
- Lack of skills to develop accessible solutions?
- Lack of sufficient evaluation and testing?
[Consider the following questions to help identify relevant sources of accessibility barriers on an existing Web site:
- [Do the authoring and development tools support accessibility?
- [Does an accessibility policy exist and is it being implemented?
- [Do the developers have sufficient skills in Web accessibility?
Example of main pages: Perhaps something like "For example, for an e-commerce site, this could include product search from the home page, through entering shipping and payment data."
Intro: Consider if people already have an evaluation report, that they know that this document is for them. Perhaps add to introduction.
Why text-only sites are not a solution: mention and point to resource (when it's done)?
Selecting accessibility consultants [it has a better title now]: link to when done
Priorities v. effort graph: add image like @@
"Where do I start? What should I do first?": Answer this more specifically, provide more detailed direction on retrofitting - list of what to look at doing first, e.g., (from Dec 2005 Oz F2F):
1. fix link text [easy]
2. skip links
3. labels on forms
4. text in images without alternatives
5. alt text for important images
6. tables linearize properly
7. div linearization
8. links to nonHTML files are clearly labeled
9. basic keyboard access (e.g., not get stopped in Flash, scripts)
10. links & drop-downs (w/o Go button), @@)
11. device-independence (e.g., hover & focus)
12. colour contrast
13. accessible alternatives to non-accessible content (e.g., old PDF) [hard]
14. frame names & titles [infrequent]
15. redundant colour [infrequent]
another batch:
1. headings marked up (& therefore probably CSS for presentation)
2. nav needs to be replaced w/ accessible nav (replacing frames with whatever, replacing inaccessible scripting w/ whatever, replacing server-image map)
3. layout needs to be replaced w/ accessible layout (tables --> css positioning)
4. invalid markup throughout --> valid XHTML
5. massive use of proprietary formats --> web standards
6. uncaptioned undescribed rich media --> accessible rich media
7. template-driven CMS --> accessible templates (decentralized content contribution)
8. widespread missing alt equiv's --> filling in the info
9. "text only" approach --> integrated accessible site
10. messed up form order --> straightening out so works w/ screen reader
11. way unnecessarily complex language for site --> clear choices & paths to tasks & short pick lists etc
another list of top "Tips and Techniques for Accessible Web Applications" is at http://uxprofessionals.com/2008/11/04/accessible-interface-design-part-2/

References

latest draft
[note] version 8 March 2006
[done] EOWG f2f Minutes 2 March 2006
[done] EOWG f2f Minutes 27 February 2006 (incomplete due to network outtages), version with notes from meeting [in brackets mostly]
[note] version 27 February 2006
[done] EOWG minutes 24 February 2006
[note] internal draft 6 February 2006
[note] version 27 January 2006
[done] EOWG minutes 27 January 2006
[done] email fron Barry 27 January 2006
[done] email from Liam 27 January 2006
[done] email from Sailesh 26 January 2006
[done] 20 Jan 2005 e-mail from Liam
[done] 13 Dec 2005 Oz F2F minutes
[note] version 17 August 2005
[done] EOWG minutes 17 June 2005
[note] version 15 June 2005
[done] EOWG minutes 20 May 2005 - includes discussion of title
[note] version 7 October 2004

Changes & Notes

Note: See "References" section above for meeting minutes and e-mail comments.

Notes from 2 Mar 2006 Meeting and Followup

See EOWG f2f Minutes 2 March 2006

Notes from 27 Feb 2006 Meeting and Followup

[done] We thought that "Ensure that everyone involved in Web development knows that accessibility is a requirement (even if you do not yet have an official policy). Include accessibility in development guidelines, quality assurance processes, project sign-offs, etc." would be covered in the Implementation Plan; however it's not. @@
[done] changed order & headings of several sections
[done] changed "adding [change to clear links] alt text for images requires some knowledge of the content and minor skills with the authoring tool. " to "
[done] changed from listing CSS to: "In addition to accessibility expertise, you may need other Web development skills."
[done] for " [look at how this fits together with skills - perhaps move there]", moved to right under skills.
[done] edited down "[Ensure that you have the necessary knowledge and skills to repair the accessibility barriers on your site. | Chances are you will need to acquire some knowledge in order to be able to repair the accessibility barriers on your site.] You might need to acquire additional skills through training existing staff, hiring additional staff, or engaging a consultant." to "You might need to acquire additional knowledge and skills in order to repair the accessibility barriers on your site. It is often best to combine [educating|training] existing staff with bringing in outside expertise, either hiring additional staff or engaging consultants."
[done] added "While the "[Combining Expertise to Evaluate Web Accessibility]" document focuses on evalaution, similair expertise is needed for repair."
[done] added text to tie in authoring tools & eval tools with retrofitting
[done] other things from version with notes from meeting [in brackets mostly] that were in brackets and I forgot to list here :(

Notes from 13 Dec 2005

Suggestion:

Publish first version with general guidance only
Consider doing second version with some detailed guidance -- that is, list of issues to address without much supporting info
Once supporting info is available from WCAG 2.0, update to point to it

Notes from discussion:

On providing detailed guidance:
- linking to WCAG 1.0 techniques is not a solution as they are often no longer best practice
- linking to external resources is not viable (too problematic)
- should be able to link to WCAG 2.0 techniques down the track
- As an interim solution: It useful to provide a brief description of these common issues without providing techniques - far from perfect, but better than nothing.
In order to publish a first version as soon as feasible, publish the general guidance without the detailed guidance list of issues or techniques.

Notes from 17 June 2005

From discussions on the version of 15 June 2005.

[open] provide more guidance for immediate "fire fighting": often retrofitting will happen upon an urgent customer request or other high priority incidents, this document can serve as guidance on what steps to take in such cases.

Notes from 20 May 2005

From discussions on the version of 7 October 2004.

[done] address overlap with implementation plan: Overlap of the approach (and hence content) with the document "Implementation Plan for Web Accessibility"
[done] address overlap with selection eval/author tools: Overlap of the content with section 2. "Considerations for Selecting Web Accessibility Evaluation Tools" of the document "Selecting Web Accessibility Evaluation Tools".

intro: positing this in a sequence, provide context - retrofitting is something that relies on information that comes out of an evalaution. perhaps you already have an eval report, or perhaps that's something you need to line up

note the wai report template includes"[recommended priorities for addressing inaccessible features of site]" & "[provide recommendations for addressing non-conformant checkpoints]"

status check
- what do you have? what are teh gaps?
step back
- why screwed UP? systemic
- people questions, expertise
midway through
- test & get feedback partway
followup

From previous version of requirements

Audience for this document

Primary audiences: Web project managers, quality assurance managers, service procurers

Secondary audience: Web developers (programmers, designers, content authors, etc) who want to comply with Web accessibility standards

Approach

Highlight prerequisites such as role identification, policy development, and assessment. See Implementation Plan for Web Accessibility for similar approach.

Describe different strategies and methods for retrofitting Web sites

Site Navigation