- Which targets should you prescribe?
- Web Content Accessibility Guidelines (WCAG)
- Authoring Tool Accessibility Guidelines (ATAG)
This page describes the appropriate accessibility targets for websites, web applications and Content Management Systems (CMS), and gives sample text that you can cut and paste into an RFT. This text is designed to be used in conjunction with the sample texts describing general accessibility targets, an appropriate development process, how tenders will be evaluated, etc. These sample texts are given on the Writing an RFT page.
This covers all information and services delivered via the World Wide Web or using HTML, including websites and online applications. For an introduction to the accessibility issues that arise with websites and online applications, read About Web Accessibility in the NDA IT accessibility guidelines.
Which targets should you prescribe?
All Web design and content should meet the Web Content Accessibility Guidelines (WCAG).
If the procurement includes a Content Management System (CMS) of other tools for adding and modifying the design of content, then those tools should meet the Authoring Tool Accessibility Guidelines (ATAG).
Web Content Accessibility Guidelines (WCAG)
This is the international standard for website design and content. WCAG is often referred to as the “WAI guidelines” because it is the most prominent of the three sets of guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). It is the only standard that is referred to within Irish Government policy (see Legislation and Public Policy for more details). WCAG 2.0 is the current version of these guidelines - all earlier versions are deprecated. WCAG 2.0 should be used to specify accessibility requirements in all procurement projects. The NDA Web Guidelines are identical to the now deprecated WCAG 1.0 but are presented in a format that is easier to read and understand.They are mentioned here for reference purposes only.
Suggested text for an RFT
The website pages and page templates should be designed to meet all Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation 11 December 2008, Level A & Level AA Success Criteria. (http://www.w3.org/TR/2008/REC-WCAG20-20081211/). Where a supplier considers any Success Criterion to be inappropriate or unachievable for some component of the content or templates, this must be stated explicitly in the tender, together with an explanatory rationale.
Prior to tendering, suppliers should be satisfied that they can meet these guidelines. Prior to project completion suppliers will be required to provide an accurate Conformance Claim with WCAG 2.0.
About WCAG 2.0
The WCAG 2.0 defines how to make Web content more accessible to people with disabilities. It is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. WCAG 2.0 is comprised of four layers of documentation:
- Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust.
- Guidelines - Under the principles are guidelines. The 12 guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities.
- 1 Perceivable
- 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
- 1.2 Provide alternatives for time-based media.
- 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
- 1.4 Make it easier for users to see and hear content including separating foreground from background.
- 2 Operable
- 2.1 Make all functionality available from a keyboard.
- 2.2 Provide users enough time to read and use content
- 2.3 Do not design content in a way that is known to cause seizures.
- 2.4 Provide ways to help users navigate, find content, and determine where they are.
- 3 Understandable
- 3.1 Make text content readable and understandable.
- 3.2 Make Web pages appear and operate in predictable ways.
- 3.3 Help users avoid and correct mistakes.
- 4 Robust
- 4.1 Maximize compatibility with current and future user agents, including assistive technologies.
- 1 Perceivable
Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.0 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest).
Additional information on WCAG levels can be found in Understanding Levels of Conformance.
The Code of Practice on Accessibility of Public Services and Information Provided by Public Bodies cites Level AA with the WCAG as the conformance rating which Irish public sector bodies should achieve.
- Sufficient and Advisory Techniques - Each of the guidelines and success criteria in the WCAG 2.0 contain a wide variety of techniques. The techniques fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory. The advisory techniques go beyond what is required by the individual success criteria
The “Bobby test” or “Bobby approved” should no longer be referred to in RFTs or contract documents.
There has always been a lot of misunderstanding around the nature of “Bobby”, which is often referred to, incorrectly, as a Web accessibility standard. Bobby no longer exists, but when it did it was an accessibility testing tool, not a standard. It was designed to help an accessibility expert assess a website against guidelines such as the Web Content Accessibility Guidelines (WCAG) and others. It is only one of a large number of such tools and different developers may prefer different ones.
Web content requirements should therefore always refer to WCAG, not to Bobby.
Authoring Tool Accessibility Guidelines (ATAG)
This standard covers software tools used to produce websites and Web content. These include website design software (e.g. Dreamweaver), content creation software (e.g. Adobe Acrobat Suite) and Content Management Systems (CMSs). ATAG describes the requirements that these tools should meet in order to enable, encourage, and assist authors in producing accessible websites.
Suggested text for an RFT
<the authoring tools> should, as far as possible, meet all appropriate and achievable checkpoints from all priority levels (1, 2 and 3) of the Authoring Tool Accessibility Guidelines (ATAG) 1.0 from the Web Accessibility Initiative (WAI). It is essential that <the tools> fulfil at least the following criteria:
- Be capable of producing valid HTML and CSS code;
- For all images, oblige authors to either include a text
alternative or indicate that the image has no information content and add alt
- Enable authors to identify heading levels and lists and apply
- Enable author to identify the semantic structure of data
tables and apply markup accordingly.
About ATAG 1.0
There are 2 aspects to ATAG. First, requirements for ensuring that the web code and content produced using the tool will be accessible. Second, requirements for ensuring that the authoring tool itself will be accessible.
If you are procuring a website, you will not end up with a static resource that never changes. Over time, new content will be continually added and modified. You may also need to make fundamental changes to the structure and navigation from time to time. All these changes will involve producing new code and content, using various authoring tools. For example, a webmaster might use a tool such as Dreamweaver to modify the code. A press office may use a word processor such as Microsoft Word to write new content. This may then be converted to HTML or PDF using other tools and added to the website using the CMS. All of these are classed as authoring tools and they must enable, encourage, and assist your staff to produce accessible code and content. If they do not, then the website and its content will become inaccessible over time.
ATAG is divided into 7 guidelines:
- Support accessible authoring practices.
- Generate standard markup.
- Support the creation of accessible content.
- Provide ways of checking and correcting inaccessible
- Integrate accessibility solutions into the overall
"look and feel".
- Promote accessibility in help and documentation.
- Ensure that the authoring tool is accessible to authors with
Like WCAG, each guideline contains a number of checkpoints and each checkpoint is assigned one of 3 priority levels, with priority 1 being the most important. These relate to the 3 compliance levels: A, AA and AAA. Satisfying all the priority 1 checkpoints for a tool means the tool achieves level A compliance. Satisfying all the priority 2 checkpoints in addition to the priority 1 checkpoints means AA compliance. Satisfying the checkpoints of all 3 priorities means AAA compliance. In brief:
Priority 1 = A (termed “essential”)
Priority 1 & 2 = AA (termed “important”)
Priority 1, 2 & 3 = AAA (termed “beneficial”)
A note on using ATAG as a specification criterion in a tendering process
To a certain extent, ATAG 1.0 is based on WCAG 1.0 (Web Content Accessibility Guidelines), so in some areas it is out of date with current web technologies and practices on accessibility. There are almost no currently available Web authoring tools or CMSs that meet even conformance rating level A with ATAG. It is advisable not to set a sepcific requirement level of “AA” or “AAA” with ATAG for authoring software without first reviewing the content of these guidelines. Review the needs of your users and the nature of your website's functionality and content. Include functional requirements that are specific to these needs during your tendering process: do not state any mandatory requirements other than the four essential criteria listed in the suggested text.
For more information, go to the Authoring Tool Accessibility Guidelines (ATAG) website.