Requirements and Changelog for Improving the Accessibility of Your Web Site
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
- 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."
"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."
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."
(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.)
- 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.)
- 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
- 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
- location: Optimising Process
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
[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
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?
- Lack of an accessibility policy (that is, developers were not instructed
- 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.,
2005 Oz F2F):
- fix link text [easy]
- skip links
- labels on forms
- text in images without alternatives
- alt text for important images
- tables linearize properly
- div linearization
- links to nonHTML files are clearly labeled
- basic keyboard access (e.g., not get stopped in Flash, scripts)
- links & drop-downs (w/o Go button), @@)
- device-independence (e.g., hover & focus)
- colour contrast
- accessible alternatives to non-accessible content (e.g., old PDF) [hard]
- frame names & titles [infrequent]
- redundant colour [infrequent]
- headings marked up (& therefore probably CSS for presentation)
- nav needs to be replaced w/ accessible nav (replacing frames with whatever, replacing inaccessible scripting w/ whatever, replacing server-image map)
- layout needs to be replaced w/ accessible layout (tables --> css positioning)
- invalid markup throughout --> valid XHTML
- massive use of proprietary formats --> web standards
- uncaptioned undescribed rich media --> accessible rich media
- template-driven CMS --> accessible templates (decentralized content contribution)
- widespread missing alt equiv's --> filling in the info
- "text only" approach --> integrated accessible site
- messed up form order --> straightening out so works w/ screen reader
- way unnecessarily complex language for site --> clear choices & paths to tasks & short pick lists etc
- 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
Note: See "References" section above for meeting minutes and e-mail comments.
Notes from 2 Mar 2006 Meeting and FollowupSee 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 :(
See also: EOWG minutes 24 February 2006
- do include the sentence, "[While implementing... overwhelming]
- do include the sentence, "[In addition to helping identify... struggle
- do include the sentence, "[Developing and adopting... take a while
- Identifying the Issues: re-consider the content of the first paragraph. maybe better more often to fix the big barriers first before evaluating more
See also: EOWG minutes 27 January 2006
- [done] try title: improving the accessibility of your website
- [done] try explaining retrofit at top, then can use throughout
- 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
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
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