A Review of Free, Online Accessibility Tools
Accessibility Report Formats

Accessibility tools generate a variety of reports based on the results of an analyzed web page. According to the World Wide Web Consortium's Web Accessibility Initiative (WAI),the developers of WCAG 1.0, all accessibility tools should look at a web page for both obvious errors (such as missing alt text) and warn users of the need for manual checks (i.e. the appropriateness of the alt text for the image). However, beyond the general requirement for tools, accessibility report formats differ widely depending on the target audience familiarity with web design and web accessibility standards. Web designers, developers, and evaluators who know which format best meets their needs will be able to choose an appropriate tool. The seven reviewed tools include six basic report formats. These formats include:

• Text-Based: Errors Listed by Line Number
• Text-Based: Errors Listed by Linkable Line Number
• Text-Based: Errors Listed within Source Code
• Text-Based: Errors Listed within Source Code and GUI
• Graphic/Icon-Based
• EARL Report

Text-Based: Errors Listed by Line Number

This type of accessibility report format lists both the specific guideline being used to scan the page as well as instances of this type of accessibility error. The following image gives an example of this type of report; showing both the guideline used to check the page, whether or not the page passed this guideline, and instances of the error (circled in red) listed by line number. To view the source code error, users scroll down to the bottom of the report.

Benefits

This report format is ideal for evaluators and web designers who want a checklist to quickly see what areas of the site passed the standards and guidelines and what areas did not. Another nice element to this report is that the guidelines are listed next to the error; this allows evaluators and designers who are new to web accessibility to learn the guidelines as they read the report.

Drawbacks

This report format is not ideal for quickly locating the accessibility error in the source code. Web designers or developers who want to see the error and in the source code must scroll down to the bottom of the report to find the error by line and column number. When a web page has accessibility errors or issues, both AccMonitor Online and Cynthia Says list line and column numbers in the report to help users locate the errors in the HTML source code.

Though the report does not explicitly state this, the column numbers actually mean character number (no column numbers are displayed in the report). Thus if a report read "Line: 268, Column 149," users would need to locate line 268 in the source code and then go to character 149 of line 268 to locate the accessibility issue. Not knowing that the columns number actually mean character number may be confusing to some users. Since the column numbers don't seem to be listed in the reports they may only confuse users, rather than helping them to locate the accessibility error.

Tools that use this format: AccMonitor, Cynthia Says, and WebXact

Intended Audience: Web Designers and Evaluators

Text-Based: Errors Listed by Linkable Line Number

This type of accessibility report displays the guidelines being used to check the page as well as any instances of this type of error on the page. This kind of report differs from other text-based reports in that it links error instances to the source code. As an example of this kind of report, Torquemada uses this format in its textual report mode.

The image shows the Torquemada report format and indicates that the Summary attribute for the table being evaluated is missing. The comment for this error informs users that the Summary attribute "is used to inform individuals about the scope of the table," (in other words what the table contains). The image also shows that there are 34 instances of this type of error in the page and the linkable error instances are indicated by the red arrow. Thus as users click on each error instance, they are linked to the HTML source code to view the error. Similarly, Site Valet's Accessibility Valet Demonstrator also uses links for one its report formats. The Site Valet Demonstrator image shows that instances of errors/warnings are shown as clickable red dots.

Benefits

Web developers and designers will notice that this type of report is an improvement on reports that do not provide links to the source code. Linking to the source code means that rather than users having to scroll down to the bottom of the report to see the errors, they can use the link to see the specific error as they encounter them in the report.

Drawbacks

For web designers and evaluators who are not comfortable with HTML code this format will not be as helpful as others. Though the report links errors to the source code, after users click on the link they must scroll back up to the top of the report to continue reading. Scrolling back and forth to read the report and view errors may be frustrating.

Tools that use this format: Accessibility Valet Demonstrator and Torquemada

Intended Audience: Web Developers and Designers

Text-Based: Errors Listed within Source Code

This format uses two columns to display the report information. The first column, lists the guideline for checking the page which expands to show the specific instances of errors. The second column, displays the web page's source code. As an error is selected the corresponding source code is expanded to show the error. The image shows the guideline used to check a page with a red arrow highlighting both the error instance and the source code.

Benefits

This format solves the initial scrolling issue encountered in other formats. Web developers and designers can instantly see HTML code with the accessibility guidelines, and error instances all at the same time.

Drawbacks

An issue that may be confusing to some web designers and evaluators is the way the report works. To view errors in this format, users must click on the guideline warning to see errors. When an individual moves their mouse over the guideline warning (to see if they are links) the cursor changes to the "text-select" or text carat cursor, rather than the traditional "pointing finger" cursor used for most links online. Some users may find this cursor inconsistency confusing.

Tools that use this format: Accessibility Valet Demonstrator Level 1 Report DOM Browser

Intended Audience: Web Developers and Designers

Errors Listed within Source Code and GUI

This type of format uses frames to show users three pages at once: the text-based report, the graphical user interface of the web page, and the error instances highlighted in the code. The image shows that when users select an instance of an error (for example line 53) in the report pane, both the web page and source code are highlighted. Torquemada uses this type of report for its "graphic report" format.

Benefits

This format also solves the scrolling problem and gives developers, designers, and evaluators the functionality to see instances of the errors, the web page and the source code all at the same time. Individuals learning HTML will be able to quickly locate the errors within the context of the familiar GUI while at the same time navigating through the code and the report.

Drawbacks

Evaluators who are not interested in seeing how the source code relates to the accessibility errors on the page may not benefit from that functionality of the report.

Tools that use this format: Torquemada

Intended Audience: Web Designers, Developers, and Evaluators

Graphic/Icon-Based

This report format uses special icons to highlight accessibility errors and manual check issues on a web page. With this kind of report, the icons are integrated into the web page's graphical user interface next to the item on the page with an accessibility issue. The following images show two different icon-based reports and how the accessibility icons are integrated into the rendered version of the Web page. To view the accessibility errors on the page, users move their mouse over a report icon and the alternative text displays either the WCAG 1.0/Section 508 guideline that need to be addressed or the specific solution for the accessibility problem (i.e. "Alerts <b> tag; use <strong> or CSS instead").

Benefits

Graphical/icon based reports may be very helpful to individuals new to web design and web accessibility standards. Accessibility errors and issues may be easier to spot because they are indicated on the web page itself. Beginning web designers or web accessibility evaluators can quickly see what aspect of the web page has issues without being familiar with HTML code.

Drawbacks

A possible drawback to this format would be the number of icons. If the graphical report uses lots of different icons it may be overwhelming for new users who have to learn what each icon means. Depending on the web accessibility tool, the number of icons used to identify accessibility issues range from two to seventy-five.

Tools that use this format: Wave 3.5, Accessibility Valet Demonstrator, TAW, Torquemada

Intended Audience: Web Designers, and Evaluators

EARL Report

An Evaluation and Reporting Language (EARL) report is a machine readable report of the accessibility standard the page validates to, as well as the accessibility issues highlighted in the report, the date of the evaluation, and any manual checks that need to be performed by developers. The EARL reports are an attempt by the W3C to standardize accessibility reports and help users compare the effectiveness of accessibility tools.

Tools that use this format: Accessibility Valet Demonstrator and Wave 3.5

Intended Audience: Web Developers and Designers