One of the most common questions that I am asked is “What’s the best way to check the accessibility of my organisation’s website?” It’s a question that all of us at Media Access Australia welcome as verifying if a website is accessible is a great starting point for developers to make online information available to people with disabilities.
In light of the recent Last Call request from the Evaluation and Repair Working Group for the Working Draft of Evaluation and Report Language (EARL) 1.0 Schema, it’s a good time to look at the issues around website evaluation and the techniques developers can use to perform their own website audit.
The EARL 1.0 schema
There is some debate as to what is the best way to evaluate the web accessibility of a website, but most will agree that a good place to start is the use of an evaluation tool, a program or online portal that will scan a website and report back on accessibility coding errors.
However, the tools are usually limited in what they can reveal. For example, an evaluation tool can do a good job in picking up missing ALT text, but may struggle to identify the quality of the ALT text description.
To improve the effectiveness of evaluation tools, the W3C is developing EARL for developers that wish to build their own evaluation tool. The W3C states that EARL is primarily designed for the development of:
- Web accessibility evaluation tools
- Web quality assurance and validation tools
- Web authoring and development tools
- Web content description and labelling frameworks
The EARL 1.0 schema vocabulary is based on RDF conventions, as discussed in a previous W3C column. The classes in the schema are defined as assertions and consist of the assertor, test subject, test criterion and test result. The assertor explains who or what ran the test, the subject is the particular code in the website that is being tested, the criterion is the accessibility requirement that the code is being tested against, and the result is whether or not the code passed the test.
The schema is highly technical in nature and outlines specific details across its classes and properties, along with some good coding examples. If you are interested in using EARL, you can get further information through the uses of EARL resource, and if you’d like to contribute to the schema, there’s not much time: the Final Call closes on 10 June 2011.
Evaluation tools
While EARL can provide developers with guidance as to how an evaluation tool can be created, there are already a number of evaluation tools available for use, but it can be difficult choosing one. Some tools are free, while others are expensive. Some will only review one web page at a time, while others will crawl the website and provide a detailed report.
Whatever the choice, it always remains that no evaluation tool can guarantee finding every accessibility consideration of the Web Content Accessibility Guidelines (WCAG) 2.0, and they should be considered as a starting point rather than the complete process.
TAW, WAVE and aChecker are amongst the tools that developers have reported as useful. In terms of commercial tools, several developers have recommended SortSite as being a good compromise between affordability and providing detailed results. Be careful though as some evaluation tools are still focused on WCAG 1.0 rather than WCAG 2.0.
In terms of their usage, most tools operate by allowing the user to put in a web address that is to be checked for accessibility issues. After a short time, a report will appear outlining the relevant accessibility issues. Developers then consider these results and work to correct the errors.
What’s next?
Given that there are no formal procedures outlined by the W3C for evaluation, it’s fortunate timing that just last month approval was granted for the creation of a WCAG 2.0 Evaluation Methodology Task Force (Eval TF). Although it’s very early days for the taskforce, it is expected that the created evaluation methodology will be broken down into modular components, for instance, to match the three sub-parts described in the objective section.
The individual components of the evaluation methodology will be developed as a W3C Recommendation, W3C Working Group Note, or other W3C/WAI resource. This will be decided after the development of an initial, more detailed set of requirements.
In the meantime, there are still a number of things that developers can do to continue the evaluation process. After using an evaluation tool, developers should consider visually inspecting the website for accessibility issues, and then test the website with some assistive technology such as the free NVDA screen reader. This will allow you to listen to how a blind person would use the website.
W3C News
RDWG call for participation
The WAI Research and Development Working Group (RDWG) are calling for participation to assist in the following areas:
- Increase accessibility considerations in research on web technologies, including mainstream research
- Suggest research questions that may contribute to web accessibility research projects
- Inform development of web accessibility solutions
- Decrease the number of potential barriers in future web-related technologies
Further information can be found through the RDWG charter and how to participate documents.
Online Web course
An online course has been added to the W3C website based on an Introduction to Mobile Web and Application Best Practices. The course includes a lot of new material concerning Web applications and is delivered over 8 weeks.
Dr Scott Hollier represents Media Access Australia on the W3C Advisory Committee and publishes the W3C Column monthly.
Top of page