The InterNet Aural Accessibility Protocol
(IAAP)
The purpose of the InterNet Aural Accessibility Protocol
(IAAP) is to enhance the accessibility of the World Wide Web to
blind and visually impaired individuals using graphical browsers in
conjunction with screen-readers, refreshable braille displays, and/or screen
magnification software. Patches based on the IAAP would:
- 1) Allow the user to activate a
numbered links option, which would cause the browser to associate a bracketed
number with every hyperlink. Hyperlinks could then be selected simply by
typing the number associated with the desired link and pressing
<ENTER>
- 2) Communicate the
ALT text correctly and uniformly, as outlined in
the W3C's HTML
specifications. This includes the use of
ALT-text in the
<AREA> portion of
<MAP ...> definitions.
- 3) Facilitate
the feeding of the ALT-text to a screen-reader
and/or screen-magnification program when image loading is turned on--a
feature which would greatly benefit low vision users who want/need aural
feedback, but have enough visual acuity to perceive the images. While this
is a commendable feature of MSAA (Microsoft Active Accessibility), MSAA is
not a viable option for anyone: a) not operating in a 32 bit environment; b)
not using a MSAA-capable screen access solution; and c) not using a
MSAA-compliant browser.
- 4) A de-tablization option,
which would force the browser to degrade tablized content by forcing a
<BR> whenever a
</TD> is encountered. This, in conjunction
with Point 3 and the method of using the
tools provided by HTML 3.2 to convey cellular structure outlined in the
document entitled Constructing Aurally
Comprehensible Tables Using HTML 3.2 will preserve the cellular
structure of table-ized content in an aurally intelligible manner.
- 5) Generation of
pseudo-ALT tags for graphically defined links that
lack ALT-text in a manner similar to that employed
by Lynx, which
generates the pseudo-ALT
[LINK] whenever it encounters an
un-ALT-texted graphically defined hyperlink. This
would make it possible for the speech-user to not only ascertain the
existence of a graphically defined link, but would facilitate the navigation
of a page (such as http://www.sony.com) which consists solely of
un-ALT-texted, graphically defined hyperlinks
- 6) The generation of text-based
output whenever a <MAP> ... </MAP>
container is encountered. Whenever a <MAP ...>
element is encountered, the browser, if so set, would automatically generate
an ordered list, using the HREF of each
AREA as the hyperlink text. If the
AREA definition contains an
ALT argument, the ALT-text
will comprise the hyperlink text; if it does not, the hyperlink text will
contain the resolved URLs to which the AREA
HREFs point.
- The patch should use the TITLE attribute of the
IMG element, or the TITLE
attribute of the MAP, if either is present in the
markup, as the title and main header of the menu. Otherwise, it will use the
ALT attribute of the IMG
element as the title of the menu. If neither TITLE
nor ALT attributes are present in the markup, the
browser will create and use a [USEMAP]
pseudo-ALT. if the MAPs
are not in the same document as the IMG elements,
the browser will fetch the document which contains the referenced
MAP, and locate it based on its
NAME or ID attribute.
All MAPs should also be cached, so that they need
not be retrieved repeatedly when referenced in different documents.
- 7) The use of frames
(simultaneously displayed, independently scrolling windows) in HTML documents
presents the blind/VI user with a multitude of access problems. Given the
ever-increasing popularity of framed sites, therefore, it is essential that
the following options be included in all graphical
browsers:
- 7A) A no-frames option, which allows the user to disable
the rendering of frames. With the browser set to "No Frames" (or
"Framed Pages Off"), the user would be presented with the content of
the <NOFRAMES></NOFRAMES> section of
the document being rendered. If the document source does not contain a
NOFRAMES section, the browser will present the user
with a vertically aligned (one hyperlink per line) list of labeled links.
The text of each link should be predicated on the NAME
argument used in the FRAME definition, as in the
following example, where underlined text represents the hyperlink text:
FRAME 1: nav
FRAME 2: main
FRAME 3: fb
- (Optimally, the NAME arguments utilized by the
author of the document source should be more substantive than those used
above for the purpose of example. Unfortunately, the vast majority of
NAME arguments utilized by HTML authors are
cryptically incomprehensible.)
- 7B) With "Display Frames" activated, the
browser must generate an on-screen
announcement/status-line warning which informs the user:
a] that he or she is in a framed document
b] in which frame the cursor is currently located (i.e. Frame X of Y)
- Frame identification should be predicated on the
NAME argument used in the
FRAME definition.
- 7C) With "Display Frames" activated, the
browser must allow the user to maximize and
minimize individual frames.
All of the above suggestions should apply equally to hypertext documents
generated by authoring/conversion utilities and by dynamic page generators,
such as Cold Fusion and Active Server Pages (ASP). All such output should be
filtered through an HTML validator/parser, in order to ensure that its output
contains valid HTML that any browser, regardless of platform, is capable of
rendering.
drafted by Gregory J. Rosmaita, unagi69@concentric.net
WebMaster & Executive Committee Member, VICUG NYC
this page created September 11, 1997
hyperlinks last updated December 8, 1998