2006 Conference General Sessions

Go to previous article
Go to next article
Return to 2006 Table of Contents


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


Reprinted with author(s) permission. Author(s) retain copyright