AChecker Rebuild in PHP
As part of the Culturall2 project being lead by the ATRC, the AChecker accessibility checker will be rebuilt as a PHP application, making it easier for us to manage as part of our collection of PHP applications, updating the accessibility checks to take into consideration changes to the developing WCAG 2 guidelines, and making it easier to install for novice users either as a standalone application or as an addon module for ATutor, and other systems that require accessibility checker services.
Much of the work undertaken for the Java version of AChecker can be reused, using the existing accessibility checks, which exist as XML files, as well as building a new parser using PHP, and using MySQL to store review data. AChecker is based on the Open Accessibility Checks (OAC) which are essentially a collection of all the checks from various accessibility guidelines around the world.
AChecker-PHP should standalone from ATutor, but may recycle some ATutor functionality, and be able to content to ATutor content editor via SOAP as it currently does with the java version of the checker.
AChecker relies on NEKO HTML parser, which turn an HTML document into a list of elements, along with line numbers (very important). Will need to find a PHP HTML parser. Possibly the the W3C validator, which would provide validation and a list of HTML elements. If not the W3C validator, then some other validator will be required, prefereably a library we can include with the checker, or if necessary through an external validation web service.
Possible HTML Parsers/Validators
Via PEAR SOAP W#C Validator service http://pear.php.net/package/Services_W3C_HTMLValidator/docs/latest/elementindex.html
W3C Perl Source http://validator.w3.org/source/
Then the parsed list of elements is run through Ckeck.java where each of the checks are defined. These will be rewritten in PHP.
The natural language associated with all checks is contained in the file: checks.xml. This languages has been well vetted and should be reused. It should also be setup with language variables and a language manager site like ATutor, so the whole system can be translated
The checks.xml file is loaded into memory. Checks are categorized by element type. see: http://checker.atrc.utoronto.ca/servlet/ShowCheck
Once parsed into a list, checker goes through the file one line at a time, and applies all the "triggered" checks for a particular element (e.g. all img check when an image is encountered.
Checks include a confidence level (high, medium, low) which correspond to the Known, Likely, Potential problems levels in the display.
The AChecker accessibility checks are all contained in the Ckeck.java file. sample files in which each of the potential accessibility barriers are implemented, or not, are contained in the web/checks/testfiles directory of the java distribution.
Typical check block of 276 total blocks This text will all be moved into a database, where it can be retrieved with an SQL query as needed during checker accessibility testing, and can be translated to other languages.
what does the Prerequistite element means, and how is it handled during an evaluation?
SOAP Out from AChecker
Allow users to use SOAP to connect to a remote AChecker (like the java version)
Should we adopt EARL for our output format? http://www.w3.org/TR/EARL10-Schema/