WCAG 2 Candidate Recommendation Implementation
October 14th, 2008 by Matthew RossThis site has been designed to achieve accessibility standards. However due to a combination of unrefined standards and misreporting by testing tools, it has previously been difficult to make a clear-cut assessment of compliance with existing standards.
Many years of work by the W3C has led to the development of the Web Content Accessibility Guidelines (WCAG) 2.0 which is now in the Release Candidate process.
We have submitted this site as an example Candidate Recommendation Implementation and have performed our own self-assessment here.
Conforming Pages
For the Implementation, we have submitted 5 pages as representative of site content and techniques:
- Home page: http://research.elabs.govt.nz/
- About this site page: http://research.elabs.govt.nz/about/
- Contact us form: http://research.elabs.govt.nz/contact/
- Article with tabular report: http://research.elabs.govt.nz/macron-support-in-open-source-web-applications/
- Sample page with user contributed content: http://research.elabs.govt.nz/nz-govt-feed-standard/
Our WCAG 2.0 Conformance Statement (Level AA) is on the page About this site.
Self-Assessment Process
We have used a number of tools to help us evaluate the compliance and good practice.
Firstly, all the pages validate as XHTML Transitional using the W3C validator.
We have also used the OpenWolf validator, which is a tool developed to support the previous New Zealand Government Web Standards, and the WAVE tool.
These tools remain useful in highlighting points that would have issues under previous standards - let’s say design stress points. Some of these are conformant under WCAG 2.0 while others now have specific Techniques for conformance.
Below, we explain some of these stress points and the rationale and or techniques for achieving conformance under WCAG 2.0.
Home Page
- Guideline 1.4.3 Contrast. We have evaluated contrast ratios using the Juicy Studio Luminosity Contrast Ratio Analyser. For the green font color #007070 on background #FFF we have a contrast ratio of 5.91. For the page header where we have font color #222 over a gradient background, the worst contrast is against background #53ABAC which gives a ratio of 5.90. The other worst ratio in use is the meta data section where font #666 is on background #F8F8F8 with a ratio of 5.41. These ratios are sufficient at Level AA. (A comment on the ‘At risk’ status of the 5:1 contrast level: we had to edit a number of our colors which were generating contrasts in the 4.7:1 range. While these were usable by an non-impaired user, the reworked contrast levels over 5:1 give a better result.)
- Guideline 3.3.2 Labels or Instructions. WAVE reports an error due to a missing <label> for the search form input field. However we have implemented a title attribute for the search input field as described in Technique H65.
- Guideline 2.4.4 Link Purpose. OpenWolf and WAVE report errors/warnings for repeated link text such as ‘Full article’ and ‘Comments’. However Technique H33 and Technique H80 respectively are implemented (default Wordpress functionality).
- Guideline 1.4.4 Resize text. We are defining font sizes using em units in an external style sheet as per Technique C36. (OpenWolf reports an error due to use of absolute units but that is because of the use of px units for layout.)
- Guideline 2.4.1 Bypass Blocks. From a literal reading of 2.4.1, it appears the site MUST have a skip mechanism. However Understanding Success Criterion 2.4.1 reveals that “small repeated sections such as… single links” are not considered to require the skip mechanism. A redraft of 2.4.1 would allow this scenario. Proposed redraft: “Where blocks of content are repeated on multiple Web pages, a mechanism is available to bypass the block.”
- Guideline 1.4.1 Use of Color. Following discussion with the WCAG team, we improved the contrast ratio of between normal text and links and added the underline visual cue for on focus as described in Technique G183.
- Access Keys. WAVE reports warnings due to the access keys that are implemented. While WCAG 2.0 no longer requires access keys it allows for their use, for example see Advisory Technique for 2.4.1. (Comments?).
About Page
- Guideline 3.1.1 Language of Page. Technique H57 is implemented specifying the language “en-nz” (this applies to the whole site). In specifiying the New Zealand dialect of English we can include vernacular New Zealand English without marking a change of language.
- Guideline 3.1.2 Language of Parts. In line with Guideline 3.1.1 above and our specification of New Zealand English, no further markup is required for the use of “Kia ora” on this page.
- Guideline 3.1.4 Abbreviations. All abbreviations (initialisms and acronyms) are expanded using one of the following: Technique G97, Technique H28.
Note: on the About page the conformance statement title, “WCAG 2.0 Conformance Statement,” is an example of a title (h4) where the abbreviation is expanded in the following block. This is common English usage and seems to me to be acceptable use although I’m not clear that it literally complies with Technique G97. Comments?
Contact Us Page
- Guideline 2.4.3 Focus Order. We provide no explicit tab order. The default order provides meaning and operability.
- Guideline 3.3.2 Labels or Instructions. All form fields have a label except the submit button as per Technique 44. Required fields are marked.
- Guideline 3.3.1 Error Identification. Input errors are described to the user in text.
- Guideline 3.3.3 Error Suggestion. Suggestions for error correction are provided.
The Contact Us form is an implementation cforms plugin for Wordpress.
Article Pages
http://research.elabs.govt.nz/macron-support-in-open-source-web-applications/
http://research.elabs.govt.nz/nz-govt-feed-standard/
Some changes were made to achieve conformance for these pages:
- Cleaning of alt text for images, including the check, cross, not applicable images in the Macron Support article.
- Adding the <h4> heading tag to head up each comment.
- A rewrite of the Ratings plugin to ensure it degrades gracefully and is usable without Javascript.


Anthony Hawkins says:
October 17th, 2008 at 4:26 pmre the abbreviations question … so you going for AAA?
Matthew Ross says:
October 18th, 2008 at 7:52 amThe focus has been on achieving Level AA. Because of user-contributed content, some aspects of AAA may be difficult to achieve (for example abbreviations in user-contributed content - or are such abbreviations ‘common usage’ for our audience?).
Now that the main conformance work has been done I might take another look at AAA issues.