HTML Extensions for Accessibility
Gregory C. Lowney
Senior Program Manager
Accessibility and Disabilities Group
Microsoft Corporation
August 3, 1997
Executive Summary
This document proposes five extensions for HTML that would
let authors create HTML documents that easily translate into
other formats, especially those that enable access for
people with certain types of disabilities.
The proposals fall into two categories: (a) ways to allow
authors to provide hints about how to order the document
content for different renderings, and (b) ways to allow the
author to provide customized appearance without sacrificing
the standard tags and the structural information they
provide.
The specific recommendations are (1) orientation of tables,
(2) hand-tuned ordering of document elements when rendered
for different output formats, (3) customized bullet images
for unordered list item, (4) customized appearance of
buttons, and (5) invisible fieldsets.
Several proposals are in the early design phase, and are
provided as a starting point for discussion.
There are many other potential enhancements to HTML that
would benefit accessibility. This document is not a
comprehensive list, but merely presents a few options
currently being considered.
Goals
This document proposes five extensions for HTML that would
let authors create HTML documents that easily translate into
other formats, especially those that enable access for
people with certain types of disabilities.
These recommendations are based on the author’s experience
in creating a filtering system that produces “universal
versions” of arbitrary Web pages. These universal pages
generally contain the same content, but are formatted to
present the information in ways that are more accessible.
(The filter is described on
http://microsoft.com/enable/about.htm,) The recommendations
directly address difficulties in performing this operation
on a wide range of existing Web pages.
The following enhancements let authors provide information
about how to order document elements when rendering the page
in alternate forms:
· ORIENTATION: an attribute for tables that provides
information about the order in which the contents of the
table should be read.
· CUSTOM ORDERING: constructs allow the author to provide
hand-tune the order in which document elements should be
presented when rendered for different output formats.
The following enhancements let authors provide customized
appearance without sacrificing the standard tags:
· LIST IMAGES: the ability for the author to provide an
image that should serve as the bullet for an unordered list
item. This allows authors to display customized appearance
without sacrificing the LI tag and the structural
information it provides.
· CUSTOMIZED BUTTONS: allow authors to present buttons
with entirely customized appearance. This allows authors to
display customized appearance without sacrificing the BUTTON
tag and the standardized information it provides.
· INVISIBLE FIELDSETS: make it easy to use FIELDSET for
grouping purposes without interfering with the normal visual
presentation. This will allow grouping of items for the
purpose of aural output.
Several of the proposals (custom ordering and invisible
fieldsets) are in the early design phase, and are provided
as a starting point for discussion.
There are many other potential enhancements to HTML that
would benefit accessibility. This document is not a
comprehensive list, but merely presents a few options
currently being considered.
Ordering Information for Different Renderings
In some cases it is most necessary or beneficial to change
the order in which elements are presented when the document
is rendered in different formats. (Such formats include
purely aural output for people who are blind or in eyes-free
situations, and simplified HTML designed to make sense when
read serially by older blind-access utilities that don’t
have direct access to the structural information in the
document.) This ordering often needs to be hand-tuned to be
most effective. The following extensions are designed to
allow authors to add such hints in a standardized fashion.
Table Orientation
In most cases we don’t need additional information to read
tables in the proper order. The utility interpreting the
table can often infer the proper order of simple from the
presence of TH tags, or when the contents of certain cells
are bold or end in colon. However, I believe that there are
a significant number of cases—including complex or “abused”
table—where more information is needed. I proposed an
ORIENTATION attribute for tables, which I distributed in
email during 1996. It is described in more detail in the
attached document.
Customized ordering and filtering for different
presentations
Sometimes the order in which things appear should vary
depending on the media or options. I’ve run into this in
building the filter that makes the accessible version of my
public web site. For example, the toolbar often comes at the
top of the normal page, but should come at the bottom of the
page when it is being presented aurally, so the user doesn’t
have to wade through the same junk on every page before they
get to the real contents. In my table orientation proposal
I suggest a way to deal with this when you want to read a
table in non-default order, but that is not always enough of
a solution. For example, you may have three table rows with
the first being the toolbar, and want to read them in the
order 2, 3, 1. Is there any way to put in hints as to a
preferred ordering?
My filter uses comment tags following a private convention.
The following proposals would define a standard for
providing such hints.
Simple Solution: Single Index Ordering
I could imaging putting INDEX= onto almost anything,
where the INDEX values define the order in which objects
within the parent container should be read when serialized.
This would be used for speech output and for turning out an
ASCII text, Braille, or simplified HTML version of the Web
page. Thus one could set index values to force table rows or
columns to be read in a hand-tuned order. It could also be
used on DIV or FIELDSET to change the order in which
arbitrary blocks of HTML are read.
General Solution: Multiple Orderings by ID
Caution: this section is not yet thought out as well as the
others, and still needs discussion with HTML experts to find
out how media-specific style sheets might apply toward this
goal.
This is a more general solution, which would allow the
author to define any number of alternate presentations,
specifying which elements should appear in each and the
order in which they should appear. Ordinarily the browser
would ignore these and, as today, use the order of elements
in the source as the presentation order. However the browser
or translation tool could choose to use the order defined
for any of the alternate presentations included in the
document.
We would define a standard set of presentation types,
including voice-output and serial-html. Any number of
PRESENTATION blocks could be allowed anywhere in the
document, or they could be restricted to the HEAD section.
Within a PRESENTATION block, ELEMENT tags are used to
reference blocking or non-blocking elements within the
document. The order in which they are referenced within the
PRESENTATION block defines the order in which they are
rendered in that particular presentation.
Example:
...
Customized Appearance of Standard Elements
The structural information provided by standard HTML tags
allows tools to convert the document to alternate
presentations. These include converting the document into
Braille, or reading it aloud to users who are blind or
operating in eyes-free situations. Today, HTML authors who
want to customize the default appearance of the page often
need to avoid using the standard tags, and so this
structural information is lost. The following
recommendations would allow authors to customize the
appearance of their document while still using standardized
tags.
Image attribute for List Items
A minor enhancement would be to support SRC attribute on LI
tags. This would allow the author to provide a image to
represent the bullet, yet still use the LI tag to provide
the accompanying structural information.
This first proposed syntax is very flexible, allowing the
author to use a full-featured IMG tag to represent the
bullet. The ID attribute on the IMG tag is referenced by the
new BULLET attribute on the LI tag.
This is an example
A second, simpler syntax would simply add a SRC attribute to
any LI tag. This would allow the author to provide a image
to represent the bullet, but does not allow providing
additional information specified on an IMG tag.
Customized Buttons
Provide a way for the author to present buttons with
entirely customized appearance. Using BUTTON you can provide
an image, but it goes on the face of the button. I would add
an attribute that allows hiding the normal 3D border etc.,
leaving only the image. Ideally the user could provide two
images, one for the normal and one for the depressed state.
In the first possible syntax, the normal button appearance
is omitted if the UPSRC attribute is provided. The DOWNSRC
attribute is optional.