UIUC PRACTICES, TOOLS AND TECHNIQUES FOR FUNCTIONAL
WEB ACCESSIBILITY
Presenter #1
Jon Gunderson
UIUC
1207 S. Oak Street
Champaign IL 61820
Day Phone: 217-244-5870
Fax: 217-333-0248
Email: jongund@uiuc.edu
Presenter #2
Hadi Bargi Rangin
UIUC
1207 S. Oak Street
Champaign IL 61820
Day Phone: 217-244-0518
Fax: 217-333-0248
Email: hadi@uiuc.edu
UIUC has developed a set of best practices, accessibility management and
visualization tools to improve the design and verification of the functional
accessibility of web resources.
Illinois Center for Instructional Technology Accessibility (iCITA)
Division of Disability Resources and Educational Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL 61820
Abstract
Functional web accessibility goes beyond complying with the technical
requirements of Section 508 or W3C Web Content
Accessibility Guidelines 1.0. Current web accessibility policies and
practices favor an “accessible repair” approach to web
accessibility, which lead to resources that might meet the technical
requirements of accessibility guidelines, but are still
not functionally usable by people with disabilities. UIUC has
developed a set of best practices, accessibility management
and visualization tools to improve the design and verification of the
functional accessibility of web resources. The goal of
these practices and tools is to support developers and administrators in
creating and verifying the functional accessibility
of their web resources. The practices encourage developers to use
forward looking web design that improves the accessibility
of web resources to everyone, including people with disabilities, by making
web resources more adaptable to a wider range of
technologies and user preferences.
Accessible Repair Model
Universities, community colleges and other organizations are defining and
setting web accessibility policies and practices.
Current polices and practices are based on the minimal standards of Section
508 [1] with encouragement to implement the more
extensive requirements of W3C Web Content Accessibility Guidelines[2].
Based on these practices developers usually first
create web resources using the techniques and markup that they want,
usually without any consideration for accessibility.
Near the end of development cycle the developer uses an automated web
accessibility checking tool to tell them of known or
potential accessibility problems. Most web accessibility checking
tools are based on markup pattern matching to identify the
markup used with the requirements of web accessibility requirements and
include tools like Watchfire WebXact,
Webaim Wave and
other tools [3]. The reports can identify a few known accessibility
problems like ALT text for images and LABELs on form
controls. But most of the items in the report require the user to
make extensive manual checks for accessibility that
require to much time and are often beyond the
capabilities of most web developers. The current practice therefore
usually
improves the use of ALT text of images, but does little to improve the
navigation structure or ability of users to restyle
content for their own needs. For example if a developer does not use
header (H1-H6) markup none of these tools will
complain, even though headers are critical for providing a navigation
structure. Current tools also are not designed to
support administrators in understanding the state of functional
accessibility of the web resources they manage, so
verification of accessibility was difficult or impossible for them to
assess.
Functional Accessibility
The goal of accessibility at UIUC is to make web resources more
functionally accessible to people with disabilities. One of
the key components to obtain this goal is the need for tools that would
estimate compliance with the manual checks required
in other accessibility analysis tools and in general provide authors with
more information to help them evaluate the
accessibility of their web resources. UIUC has developed a set
of html best practices [4], Web Accessibility Management
Tool (WAMT) and a Web Accessibility Visualization Tool [5] to support
developers in using accessible markup, estimating the
use of the best practices and help developers visualize the accessibility
of their resources. The tools use the following
accessibility these to organize the best practices and the results of the
The functional requirements are defined in five major topics:
1. Navigation and Orientation: The use of html structural markup like
headers (H1-H6), form control labels and other HTML
structures for identifying the topics and relationships between topics in
web resources.
2. Text Descriptions: Images, video, audio and other multi-media object in
web resources need text descriptions for people
who cannot use the objects.
3. Automation: Javascripting, embedded objects
and other technologies that generate dynamic or interactive content.
4. Styling: The use of markup and styling techniques that support users
restyling content for their own needs and content
adapting to the capabilities of the browser rendering the resource.
5. Standards: The use of web standards insures that web resources can be
rendered by the widest range of web technologies,
which supports the basic principle of interoperability that is the heart of
web technologies.
HTML Best Practices
The CITES/DRES HTML Best Practices [4] translate the requirements of
Section 508 and W3C Web Content Accessibility Guidelines
into markup requirements for implementing common web page features.
Each best practice includes:
1. Explanation on the accessibility issues
2. HTML markup associated with the best practice
3. Relevant Section 508 and WCAG requirements
4. Examples of the best practices
5. Other resources
For example the best practices related to navigation include:
• Uniquely titling each web resource
• Indicating major/minor topics
• Accessible menus
• Accessible dynamic Menus
• Labeling and grouping form controls
• Indicate default and changes in languages
• Creating accessible links
• Using list markup
• Simple and complex data table markup
• Issues in using accesskeys
• Frames
Web Accessibility Management Tool
One of the major problems after an organization defines a web accessibility
policy and practices is estimating the
implementation of the policy. The Web Accessibility Management Tool
provides a means to estimate the functional
accessibility of web resources by analyzing web pages and estimating their
use of the best practices. The tool does not
determine if a resource or a collection of resources is accessible or not,
but provide statistics on the use of accessible
markup.
Some examples of test for accessibility:
1. Unique Titles: The best practice require the
TITLE element and an H1 should be used to uniquely identify a web resources.
The WAMT tool reports the percentage of pages in a web site that have
unique TITLE elements and a matching H1 element on a
page.
2. Headers: The use of headers is mostly ignored by other automation tools.
WAMT provides information on the use of headers
(H1-H6) by providing counts on the number of headers used on a page and
percentage of content that is contained in headers.
This allows web developers to see how much of there content is contained in
headers and the distribution of header types in a
web resource.
There are rules for testing each of the functional accessibility features
of navigation, text descriptions, styling,
automation and the use of standards. The test results are linked to
both the best practices document and the web
accessibility visualizer for web developers to
find out more information about the results. The best practices provide
information on the accessibility and markup issues with the functional
accessibility requirement and the visualizer provides
a means developers to graphically view the accessibility issues.
Web Accessibility Visualization Tool
The web accessibility visualization tool provides a means create graphical
views of functional web accessibility issues based
on the best practices. For example with header the visualization tool
shows a rendering of the web page with all non-header
text grayed out, so the header information is highlighted on the page.
This allows a developer to see if all the major topic
areas of a web resource have a header. Another example is looking at
overall document structure. If there are no headers,
lists or other structural content on a web page, then the visualization of
the web page puts all the text in the web page in
one paragraph. The developer is then asked how easy is it for them to
use the web resource when all the content is in one
paragraph. The visualization tool helps to take developer beyond the
current lists of accessibility checks of current web
accessibility analysis tools and provides them with a means to visualize
the accessibility problems.
Accessible Web Publishing Wizard for Microsoft Office
Professional web developers can learn how to create accessible markup, but
the most important web content in education is
created by instructors. Most instructors have little understanding or
interest in learning about the details of html, let
alone the additional details associated with web accessibility.
Therefore the tool that they use will have a tremendous
impact on the accessibility of their web resources. The Illinois
Accessible Web Publishing Wizard for Microsoft Office
provides them to use their most familiar authoring tool, Microsoft Office,, to create highly accessible web versions of the
resources.
Conclusion
For functional accessibility to be achieved, web developers, instructors,
students and all users need to embrace the benefits
of accessible design principles. People need to value the additional
options and control they have over the rendering and
navigation of web content. As long as web developers view the needs
of people with disabilities as something that does not
benefit them or their users, the functional accessibility of web resources
will remain marginal. Only when all users expect
and appreciate the features of accessible design will there be a break
through in making web resources more accessible to
people with disabilities
References
[1] Section 508 Electronic Information Technology Accessibility Standards,
http://www.access-board.gov/sec508/standards.htm
[2] Chisholm, W., Vanderheiden, G., Jacobs, I.
(2000) W3C Web Content Accessibility Guidelines, http://www.w3.org/TR/WCAG
[3] iCITA Web Accessibility Evaluation and Repair
Tools, http://cita.disability.uiuc.edu/evaluation/
[4] DRES/CITES HTML Web Accessibility Best practices, http://cita.disability.uiuc.edu/html-best-pracitces/
[5] iCITA Software Tools for Accessibility, http://cita.disability.uiuc.edu/software/
[6] Illinois Accessible Web Publishing Wizard for Microsoft Office,
http://www.accessiblewizards.uiuc.edu
Go to previous article
Go to next article
Return to 2006 Table of Contents