[contents]
Abstract
The purpose of this document is to support developers of web accessibility
evaluation tools by identifying typical features of those tools and how to classify them according to
different combinations of those features.
Status of this document
This section describes
the status of this document at the time of its publication. Other documents may supersede this document. A
list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Table
of contents
- Introduction
- Audience of this document
- Document conventions
- Complementary resources
- Typical features of an accessibility evaluation tool
- Example profiles of evaluation tools
- References
- Acknowledgements
- Appendix A: Customising results to different
audiences
- Appendix B: Integrating the evaluation
procedure into the development testing workflows
1. Introduction
There is a wide variety of accessibility evaluation tools
to be found on the web. This document intends to support the tool developers to identify their key
characteristics. To do that, this document:
- describes to developers of web accessibility evaluation tools their typical
features and briefly presents different perspectives on these features;
- describes typical profiles for web accessibility evaluation tools according
to different combinations of the aforementioned features;
- supports developers of web accessibility evaluation tools to understand the different types of
web accessibility tests: automatic, semiautomatic and manual; and
- supports developers of web accessibility evaluation tools to understand how to use WCAG 2.0
success criteria, sufficient techniques, advisory techniques, and common failures for web
accessibility testing.
1.1. Audience of this Document
This document is targeted mainly to
development managers and developers of web accessibility evaluation tools. Under this scope, we will not
distinguish between commercial and open source developers, although there are use cases that could be more
relevant to one group than to the other.
A secondary audience of this document are users of
accessibility evaluation tools like accessibility experts or web developers.
Examples of tools that
are within the scope of the document include:
- Industrial/commercial and open source tools, which test complete web sites or web
applications.
- Focused tools, which test a concrete aspect of accessibility, for instance, testing contrast
of images, accessibility of forms, ARIA implementation, etc.
- Tools that support research with users or developers of specific aspects of
accessibility.
1.2. Document Conventions
The keywords must, required, recommended,
should, may, and optional in this document are used in accordance with RFC 2119 [RFC2119].
1.3. Complementary resources
2. Typical features of an accessibility evaluation tool
In this section, we will
describe typical features and functionalities of accessibility evaluation tools. We have tried to be as
complete as possible, but it may be that some features of existing or future evaluation tools were
omitted.
It is very important that you analyse and describe for your own development process and for
your customers which of those features are supported in your tool and declare any limitations of your
tool.
2.1. Types of document formats analyzed
Although the vast majority of web documents
are HTML documents, there are many other types of resources that need to be considered when analysing web
accessibility. Of particular importance are resources like CSS stylesheets or Javascript scripts, which
allow the modification of markup documents in the user agent when they are loaded or via user interaction,
as many accessibility tests are the result of the interpretation of those resources.
In general, we
can distinguish these types of formats:
- Markup documents. These are normally HTML(5) or XML documents. Processing
these documents requires the ability to build a Document Object Model (DOM) according to the
different specifications, which can then parsed and analysed.
- Style resources. These are presentation modifiers conformant to the different
CSS specifications, which are processed by the user agents. The interpretation of stylesheets is
critical for many accessibility techniques.
- Script resources. These are components that modify at a defined point
documents and styles, be it because of user interaction or because of other functional
requirements of an application (e.g., because of dynamic updates or modifications). Nowadays these
resources play a critical role in mobile web and web 2.0 applications. Ignoring these resources
may lead to missing accessibility problems or to report non-existing errors.
- Multimedia resources. These are images, movies or audio tracks that are
inserted into the application. From the accessibility standpoint, the interpretation of those
resources is very important, especially for issues like colour contrast, colour blindness, or
media alternatives, for instance.
- PDF documents. Many reports and administrative information is available in
this format, especially in government websites.
- Resources with other proprietary or open source formats. Although not very
frequent on the web, you may encounter other formats like office documents, flash movies and
applications, etc. Depending on your customers, you may need to be able to parse and evaluate this
type of resources.
Most of the accessibility evaluation tools concentrate on the markup validation, but the most
advanced are able to process many of the types described above.
2.2. Crawling of sites
A
typical difference between commercial and open source tools is the capability to crawl web resources. That
means that the tool incorporates a web crawler [WEBCRAWLER] able to extract
hyperlinks out of web resources. It must be kept in mind that, as seen in the previous section, there are
many types of resources on the web that contain hyperlinks. The misconception that only HTML documents
contain links may lead to wrong assumptions in the evaluation process.
A web crawler defines an
starting point and a set of options. The critical features of a web crawler are related to its
configuration capabilities. Among them, we can highlight:
- Types of documents extracted.
- Capability to define inclusion and exclusion filters. Sometimes customers require analysis of
concrete parts of the website, or do not want to include others.
- Multithreaded crawling. For a large site, it may be important to optimise performance by
having a tool able to crawl in parallel threads.
- Avoidance of resource duplicates. It is typical from web resources to link many times to the
same results. If the crawler is not able to identify such issues, it may lead to a great
performance loss.
- Session persistence. Some sites include the session ID in the URL. If the site is big, it may
occur that the session ID changes over time, leading to identify resources as different when they
are in reality the same.
- Authentication support. Many sites require some kind of authentication (e.g., HTTP
authentication, OpenID, etc.). A crawler should be in the position to handle such use cases.
2.3. ...
3. Example profiles of evaluation tools
4. References
The following are references cited in the document.
- RFC2119
- Key words for use in RFCs to Indicate Requirement Levels. IETF
RFC, March 1997. Available at: http://www.ietf.org/rfc/rfc2119.txt
- WCAG20
- Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008. Ben
Caldwell, Michael Cooper, Loretta Guarino Reid, Gregg Vanderheiden (editors). Available at: http://www.w3.org/TR/WCAG20/
- WEBCRAWLER
- Wikipedia. http://en.wikipedia.org/wiki/Web_crawler
Acknowledgements
Appendix A: Customising results to
different audiences
Appendix B: Integrating the evaluation procedure into
the development testing workflows