Now available at http://EmpowermentZone.com/tpgsetup.exe I have developed a Windows program for testing the usability of a web page and generating a report as a text file. It is meant to be especially easy to use. The primary documentation is pasted below. Jamal TestPage Version 1.0 January 30, 2009 Copyright 2009 by Jamal Mazrui GPL license Contents Description Bringing Accessibility into the Development Process RAACT Tests Error Explanations for The W3C Markup Validation Service ---------- Description TestPage is a command-line utility and dialog interface for doing a simple, automated test of a web page for problems related to accessibility for users with disabilities or to validity of the HTML according to standards of the World Wide Web Consortium, located at http://w3.orc.org The command-line syntax is TestPage.exe URLPath FilePath The first parameter specifies the URL to test and the second parameter specifies the file name of the resulting report. The TestPage installer creates a shortcut for launching an input box that prompts for the URL to test, which is then passed onto the command-line utility. The default hotkey for invoking the input box is Alt+Control+Shift+T. This may be changed by modifying properties of the TestPage shortcut on the Windows desktop. The installer also creates a TestPage program group in the Windows Start Menu, with options for launching the program, unstalling it, browsing generated reports, or reading this documentation. The default program folder is C:\Program Files\TestPage The TestPage dialog is built with the VBScript language. As a convenience, if Internet Explorer is open, the URL of its web page is used as the default value in the input box. Also, the domain name of the URL is used for the file name of the report. The command-line utility, which does the main work, is built with the Ruby language and several related packages. Subsequent sections of this documentation provide more detail using excerpts from material on the web. Please note that this program is only intended as a convenient, mechanized test of web accessibility. Hopefully, its ease of use will enable more people to do accessibility checks and send them to web developers, as appropriate. In addition, since TestPage is open source, programmers are encouraged to contribute improvements. A list of more sophisticated and effective evaluation tools is available at http://www.w3.org/QA/Tools/ ---------- Bringing Accessibility into the Development Process From the web page http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ By Peter Krantz Web accessibility is, in my experience, often considered late in the development process. Typically, accessibility evaluation is conducted by outside experts after the application is delivered and content is produced. This leads to issues being reported to dev elopers late in the project, at a time when changes cost more. In order to make accessibility development efforts more efficient I believe that accessibility has to be integrated into all stages of a project with as much automation as possible. Here are some ideas on how this can be done for the developer role. Project roles and process Consider the typical staffing of a web development project and how the respective roles relate to accessibility: Designers create the user interface design. The design needs to be checked for visual aspects such as contrast issues, choice of color, font readability etc. The designer deliverables are often due early in the project. Developers create the markup and application logic for the application. The markup has needs to be checked for technical accessibility issues such as correct markup of tables, forms, document structure etc. The developer devliverables appear throughout the project. Content producers (copywriters) create text. The text has to be checked for readability issues and other language aspects. Content is often delivered towards the end of the project. Accessibility experts typically appear at the end of the project to test the application. This is natural as it isnt until the end that the majority of design, markup and content is available for testing. Implications The problem with this approach is that the time between feedback from the accessibility evaluation and the work done is too long. Proponents of agile development methods identified this a long time ago and it is typically illustrated with the cost of change curve. In essence, rapid feedback is easier to act upon and incurs a lower cost of change. Getting the feedback later means that you as a developer may have implemented more functionality in an inaccessible way. There may also be more dependencies developed that affect the parts that you need to change based on the late feedback. So, if possible we would like to have a tool that provides rapid feedback throughout the development process to all project roles. By rapid I am referring to near instantaneous feedback to minimize context switching for the developer. Challenges with automated accessibility evaluation tools The challenge with accessibility testing is that many things are difficult to automate. Content, for example, is hard to do an automated assessment of. You may calculate all the readability scores you want but only real user testing will give you enough information to conclude if your content is understandable. Contrast and color is also difficult. Developers may have used combinations of javascript, css and markup to create the final look. To have a machine understand the actual contrast ratio for a specific text may be nearly impossible if you dont roll your own browser implementation. Other challenges include integrating a tool into your projects continuous integration framework. This rules out many of the web based tools available. A proposed solution If you havent heard of Raakt (The Ruby Accessibility Analysis Kit) before, there is a quick introduction on the Raakt wiki. Raakt focuses on the developer role in a project and helps developers make sure that the created markup passes a set of basic accessibility tests. It integrates with many test frameworks to become part of the automated test cycle. The ambition is to make basic technical accessibility testing a natural part of a development projects test suite. This will hopefully improve markup quality and minimize the number of accessibility issues found in subsequent tests. It also helps developers with little or no accessibility knowledge to get on track faster. ---------- RAACT Tests From the web page http://www.peterkrantz.com/raakt/wiki/tests The following tests are available in Raakt. These generate error message objects. Each error message has an id and a description text. See Error message ids for more information. Check_areas: Check area elements and make sure they have a non-empty alt attribute. Check_character_set: Verify that the character set specified in HTTP headers match that specidied in the HTML meta element. This test will be skipped if you dont pass a hash of http headers when setting up the test. Check_document_structure: Verify that heading elements (h1-h6) appear in the correct order (no levels skipped). Check_embed: Verify that the embed element isnt used. It does not provide a way to express a text representation. Check_fieldset_legend: Check all fieldsets and make sure each fieldset has a legend element with text content. Check_for_formatting_elements: Check that none of the following elements are used: font, b, i, u, tt, small, big, strike, s. styling should be done in CSS. Check_for_language_info: Make sure the root HTML element has a non-empty lang attribute. See also Check_valid_language_code below. Check_for_nested_tables: Make sure the document doesnt contain nested tables. Check_form: Check that all editable form elements have an associated label element connected via the for attribute. Check_frames: Check that all frames have a title attribute. Check_has_heading: Check that the document has at least one h1 heading. Check_images: Check that all img elements have an alt attribute. Check_input_type_img: Check that image buttons have a non-empty alt attribute. Check_link_text: Check that the document doesnt contain ambiguous link texts. A typical example is several links with the text Read more pointing to different URLs. Check_refresh: Check that there isnt a meta element conatining a refresh instruction. Check_tables: Make sure each table has at least one table heading. Check_title: Check that the document has a non-empty title element. Check_valid_language_code: Check that the first two characters of the lang attribute value on the HTML element is in the list of valid |ISO 639-1 language codes. Relation to other evaluation methodologies This table lists the Raakt tests and how they relate to tests defined in other accessibility evaluation methodologies, e.g. the UWEM 1.0 (Unified Web Evaluation Methodology) and the Web Content Accessibility Guidelines (WCAG) 1.0. The table is not complete yet. Mapping is underway. Raakt test UWEM 1.0 WCAG 1.0 Check_areas1.1_HTML_01Checkpoint 1.1 Check_character_set-... Check_document_structure3.5_HTML_03Checkpoint 3.5 Check_embed1.1_HTML_06... Check_fieldset_legend12.3_HTML_01... Check_for_formatting_elements7.2_HTML_01 and 7.3_HTML_01Checkpoint 11.2 Check_for_language_info-Checkpoint 4.3 Check_for_nested_tables-Checkpoint 5.3 Check_form12.4_HTML_02Checkpoint 12.4 Check_frames12.1_HTML_01Checkpoint 12.1 Check_has_heading-... Check_images-Checkpoint 1.1 Check_input_type_img1.1_HTML_01Checkpoint 1.1 Check_link_text-... Check_refresh-... Check_tables-Checkpoint 5.1 Check_title-Checkpoint 13.2 (partial) Check_valid_language_code-... ** To leave the list, click on the immediately-following link:- ** [mailto:guispeak-request@xxxxxxxxxxxxx?subject=unsubscribe] ** If this link doesn't work then send a message to: ** guispeak-request@xxxxxxxxxxxxx ** and in the Subject line type ** unsubscribe ** For other list commands such as vacation mode, click on the ** immediately-following link:- ** [mailto:guispeak-request@xxxxxxxxxxxxx?subject=faq] ** or send a message, to ** guispeak-request@xxxxxxxxxxxxx with the Subject:- faq