[Promotion-technology] Announcing TestPage, Simple Web Test Program

[Jamal Mazrui]

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 deliverables 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 isn't 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 don 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 Haven 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 specified in the HTML meta element. This test will be
skipped if you don 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 isn't 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 doesn't 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 doesn't contain ambiguous link
texts. A typical example is several links with the text Read more pointing
to different URLs.

Check_refresh: Check that there isn't a meta element containing 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-...