Skip to end of metadata
Go to start of metadata



The Enabling Change Partnership program is supported by the Ontario government aimed at assisting government and business transition to the accessibility requirements set out by the Accessibility for Ontarians with Disabilities Act (AODA). The AChecker redesign project is one project being supported through the program.

The goal of the project is to redesign, simplify, and extend instructional information in AChecker, making it accessible to a broader audience, who can now install their own copy of the AChecker software. This project is occurring in parallel with the Enabling Change Understanding Web Accessibility course project.

A number of tasks have been set out for the project:

  1. The steering committee will meet prior to beginning work to review the proposed project plan, and recommend adjustments to the plan where necessary.
  2. Identify all the functional elements of the original version and develop a plan for implementing those features in the new version.
  3. Convert the old XML based checks and accessibility information into a more efficient database driven format.
  4. Develop a PHP parser that will process HTML content and assess its accessibility using the pre-existing accessibility checks from the original version of the tool.
  5. Develop a simplified user interface that is easy to understand and navigate.
  6. Re-implement the authentication system to allow users to login, customize the accessibility checks they use, and save data collected from decisions made during Web site reviews.
  7. Re-implement Web services to allow external systems to access AChecker remotely, with Web services used to integrate accessibility checking into other Desktop software and Web applications.
  8. Design and implement a tool to customize accessibility checks and author new ones.
  9. Advisory committee will conduct objective reviews of the accessibility reports, including people with disabilities, to confirm the tool itself is accessible, and accurately represents the needs of Web users with disabilities.
  10. Steering committee will review the report submitted by the advisory committee and make recommendation for changes.
  11. Update accessibility checks based on the recommendations of the steering committee, and add additional instructional information where necessary.
  12. Write documentation that describes installation, management, and general use of the system.
  13. Release a public distribution of the software, setup a local installation for public use, and setup development, communication, and promotional tools to support an open source community.

Development Plan

Items 2 to 5 above have been completed as part of the Cultureall2 Project. The accessibility checks from the older Java version of AChecker have been converted and imported into a MySQL database. The AChecker accessibility check parser has been recreated in PHP, and a simplified interface has been designed. The following screenshot shows a mockup of the simplified interface.

A number of features being developed are first implementations, and some research and experimentation will be necessary, the results of which may change the technical aspects of the final product somewhat from what is described in this plan. If there are significant changes needed to the plan, the steering committee will be notified, otherwise minor variations from the original plan will be treated as normal adjustments made on lessons learned. The following describes the areas of functionality we intend to implement as part of the Enabling Change project.

1. Re-Implement Multi-user System:

In the Java version of AChecker users can to log into the system, customize the accessibility checks they use in their reviews, and save decisions made on accessibility checks that a human must make. This functionality will be reproduced in the redesigned version of the software.


A registration screen will be created that resembles the one in the older AChecker, and collects the data it collected. Registrants' email address will act as their login name. The registration form will include the following required fields:

First Name
Last Name
Password Again.

A "members" database table will be used to collect the above data. Its fields will be created as follows:

For security, passwords will be submitted, and stored in a SHA1 encrypted format.


An administrator account is setup during the installation of AChecker. When a user logs into the system as its administrator, a link to Administration will be added to the interface to provide access to various system management and configuration tools. System preferences set through the administration tools will be store in the config database table as name/value pairs. The config table will be created as follows:

When a user first accesses AChecker, the system configuration preferences are retrieved and restored into the user's session.

Check Editor described below, and User Management will also be found in Administration area. Language management tools will also be added into this area (see AChecker Internationalization) as part of another project. Additional tools and system preferences can be easily added into the administration area into the future.

User Preferences

Once logged into the system, the choice of standard to be used for accessibility reviews, selected from Options on the AChecker opening screen, will be saved to users' preferences so when they return, their previous settings are restored. Preference settings will be stored in the members table of the database as a serialized string, and when a user logs in, that string and the preferences it contains will be restored into the running session. Handling preference in this way makes it easy to add additional preferences to the system into the future, by simply attaching preference name/value pairs submitted from a form field.

Resolving Known Accessibility Problems

When a user receives a report from AChecker, problems that can be identified with certainty are listed as Known Problems. The user then corrects the know problems by modifying the markup of the page being assessed, and runs the review again, repeating the process until no known problems remain, after which a Conditional Pass is issued. There are many accessibility problems that accessibility checkers can not identify with certainty, and those require a human to make a decision. The following section describes how those decisions will be made.

Save Accessibility Review Decisions

Under the Likely Problems, and Potential Problems tabs of an accessibility review in AChecker, will appear binary questions with each item listed in the report, such as those displayed in the screenshot below. When a URL to a Web page is supplied, users can select one of the two radio buttons associated with each question, correct any confirmed problem, and save the responses to the database. When all likely and potential problems have been confirmed and/or resolved, a Full Pass is issued and a conformance seal provided. Copying the HTML for the seal into the page reviewed provides a quick link to the report, and when content changes, it provides a quick update review to be sure the changes are not introducing new barriers.

The "reviews" table in which the data is saved will be created as follows.

When a user revisits a report, decisions previously made for Likely and Potential problems will be restored for the matching URL.

Custom Accessibility Reports

AChecker has several predefined accessibility standards, corresponding to WCAG 1.0 and WCAG, 2.0, Section 508 of the US Rehabilitation Act, BITV from Germany, and the Stanca Act from Italy. Each of these standards are essentially a selection of checks from the 270 Open Accessibility Checks included with the system. If an administrator has set the system preference that allows users to create their own custom accessibility standards, users will be able to create their own standard by assembling a subset of the Open Accessibility Checks.

When Logged into the Custom Reviews utility, users can define a custom title for their collection of accessibility checks, then select from the available checks to create a new review standard.

Once a custom review has been created, it becomes available as a review Option for that user. The custom reviews can be made public by setting a "make public" property for it. Setting the custom review to public will notify the system's administrator, who can approve or deny the public request.

2. Re-Implement AChecker Web Services

In the Java version of AChecker it is possible to access the accessibility checking features remotely through a Web service. The Web services in the Java version will be reproduced in the redesigned version, essentially taking a remotely generated HTML document, sending it to AChecker, which sends an HTML report back to the remote application where it gets displayed.

The HTML report method provides little opportunity to customize the output of the reports returned from AChecker. In many cases, the HTML report is sufficient, but for programming client applications that take the data generated by AChecker and formats it to match the look and feel of the host application, other means of transmitting data are required. A variety of different Web service standards are available for sending data between remotely located applications including SOAP and WSDL, both XML based services, and the RESTful Web service standard which sends data as standard GET information between applications, making it easier and more efficient to pass and display data across Web application than with the XML-based standards. Another standards, designed specifically for structuring test results is the RDF based EARL standard.

The HTML Web service will be reproduced so systems currently using this service in the existing Java AChecker, can continue to use the service when the PHP version takes its place. At least one of the other Web service standards will be implemented to provide developers with a more adaptable means of generating and displaying report data from AChecker (We're leaning toward REST).

3. Accessibility Check Editor

New to AChecker will be a tool used to edit accessibility checks, and create new ones. Not all accessibility checks can be edited, and not any accessibility check can be created with the check editor. More complex checks require a programmer to create custom functions. Fortunately only about 50 to 70 of the 270 checks fall into this category of checks, so most can be modified using the check editor, and most new checks will be simple checks that can be designed using the set of common functions the check editor will provide.

The Check Editor will be designed around a series of common functions that are repeated over many checks in the current AChecker check parser. For instance, many checks are simple string search functions, which identify a particular HTML element, and searches the element to find a particular HTML attribute. These types of checks are relatively easy to create from a programmers perspective. From an author's perspective specific knowledge of accessibility rules and an understanding of how string manipulation functions work will be required to create new checks. Documentation created for the check editor will assume authors have the prerequisite knowledge.

Much of the development will involve breaking down the existing accessibility check parser, currently available as a collection of 270 check functions, recreating the common functionality across these checks, separating the data from the programming and storing it in the database, then rebuilding the checks by defining which common functions each uses, and adding back in the extracted data to reassemble the accessibility checks for use with the check editor.

Using the common functions, a check for Guideline 1.1 might function as follows.

The "string_search" function identifies an HTML image element "IMG" by searching through a line of HTML and finding the string "<img". The function then searches through the element up to the next ">" character to determine if the string "alt=" is present. If not, it adds a "Known Problem" to the report like "image requires Alt text," then continues on to the next check. If it does find and alt attribute, it runs another function called "get_image_size" that gets the dimensions of the image. Then the check_length function is run to determine the length of the alt text. If it is short and the image is large (e.g. greater than 100x100 pixels), it adds a "Likely Problem" to the report and asks "is the Alt text descriptive enough?". If the image is small, and the Alt text is sufficiently long, it issues a pass for the check and carries on to the next one.

Common functions and their parameters will be stored in a number of tables in the AChecker database. These tables will be created as follows.

Common functions will be assembled to create checks, which will be stored in two database tables created as follows:

When the above data is in the database, an interface can be developed where users can create new checks by inputting the relevant information, selecting multiple common functions, joining conditions, and defining parameters to perform check functionality. These data can also be used to edit the functionality of existing checks.

Note that the table design above for check functions only allows single condition joins like condition1 && condition2 || condition3. It doesn't support nested joins like condition1 && (condition2 || condition3)

A fifth, existing database table will be associated with the check editor that holds all the language associated with each check. This table will also be associated with the AChecker language manager, so check language can be translated.

Accessibility Check Structure

The following is an example of the information that accompanies each check, in this case check 1 which checks for Alt text with images. This information has gone through rigorous review by the W3C WCAG Working Group. An additional non-normative section "Long Description" will be added to provide a open language non-technical description of the accessibility check. Depending on the screen through which a user is viewing information about the check, different parts of the information described below will appear. For instance, in the initial report sent to the users, only the Error Text and the short description of the problem will be displayed. If more information is required, users can click on the error text to display the line of HTML in which the error occurs, and a description how to correct the problem. If a user clicks on the ID number associated with the check, they can view the entire record for the check.

A standard HTML form will appear along with the tools in the Check Editor for assembling checks, and to enter various pieces of information associated with the check.

Accessibility Test 1

All img elements have an alt attribute.

Accessibility: Test Properties




All img elements must have an alt attribute.

Error Text:

img element missing alt attribute.



Detection Confidence:

high (known problem)

Trigger Element:


Prerequisite Tests:


Example Text:

<img src="rex.jpg" alt="a picture of Rex the cat" />

XQuery Expression:


Long Description (NEW)

Graphical information is generally not accessible to blind individuals, so it is important to provide a text alternative to images, Java applets, Flash presentations, and other visual information so blind visitors to your site receive the same information sighted users might receive. Providing a text alternative is often done by adding the HTML alt attribute (i.e. alt="" ) to elements used to display various graphical information. Other means of providing text alternatives include captions, descriptions in the text surrounding the visual information, or using the HTML longdesc attribute to link to a separate page with a long description. Providing a text alternative also makes it possible for those using a text based browser to understand what is represented in images or other graphical components of Web pages, and allows search engines to catalog graphical information to make it searchable.

Test Process


1. Check each img element for the presence of an alt attribute.

Expected Results

1. All img elements have an alt attribute.

Fail Instructions

1. Add an alt attribute to each img element.

Pass Instructions

The following tests are related to this test and may be performed next. There is no requirement that these tests be performed:

  1. Image Alt text is short.
  2. Alt text for all img elements is not placeholder text unless author has confirmed it is correct.
  3. Alt text for all img elements used as source anchors is not empty when there is no other text in the anchor.
  4. Alt text for all img elements contains all text in the image unless the image text is decorative or appears elsewhere in the document.
  5. Alt text for all img elements is the empty string ("") if the image is decorative.

Guideline Use

Guidelines known to use this test are listed below.


The WCAG Working Group has created techniques that describe how Web content may be made accessible. The following techniques are related to this test:

Test Files

The test files below contain HTML code that exhibits (or not) the accessibility problem that can be detected by this test. These files may also contain other accessibility problems that should be ignored. View the EARL code for these test files.

  • 1-1.html Will fail the test. (img element without an alt attribute.)
  • 1-2.html Will pass the test. (img element with an alt attribute.)