Contents
1. Introduction
2. "World Wide Web Browser Guidelines" Document
A. Presentation Adjustment
B. Navigation and Control
C. Orientation
3. Miscellaneous Proposals
Plug-ins
HTML extensions and corresponding Browser features
4. "Unified Web Site Accessibility Guidelines" Document (Version 8) - Guidelines for User Agents
5. Future Contributions
This document is submitted in the context of the WAI User Agent working group, as a contribution towards the development of the "WAI Accessibility User Agent Guidelines: Browser User Interface". It is, mainly, based on the document "World Wide Web Browser Guidelines" compiled by J. Gunderson (the version referred to as current, is the one updated on February 13, 1998). Included are: comments and suggestions for additions, or enhancements to existing categories of guidelines, and proposals for new guidelines (and possibly new sections). Some of the items (browser accessibility features and facilities) discussed in this document have already been implemented in the browser developed by ICS-FORTH, Greece, in the context of the ACTS AVANTI AC042 project funded by the European Commission. The AVANTI browser is a "unified" browser that currently supports interaction by able-bodied, blind and motor-impaired individuals. ICS-FORTH will continue to work in this direction and is planning to be involved in the implementation of Web browsers that comply with the accessibility guidelines developed by the WAI User Agent working group.
ADD
ADD
ADD
Example:
Image map 1. Area 1. Area 2. ...
Image 4. Some other text. Image 5. ...
ADD
ENHANCE
No comments.
Preliminary ideas concerning user events which trigger scripts
within a document and how disabled people make use of them. Bellow
are the main questions which appear in the current version of
the guidelines document followed by our corresponding proposals.
How will the person know the event exists?
The browser can notify the user of the existence of events handled by scripts in a document in two different ways:
Please note above, that the difference between the entries in
the "global" event list and the one local to an element,
is that entries in the first also include some information regarding
the element with which they are associated, that is redundant
information in the local list.
How can events be emulated, or simulated?
The user should be able to "trigger" any event corresponding
to an entry in the lists described in the previous question, by
selecting / activating that entry. All of the user (interaction)
events that are used in browsers today, or are foreseen as extensions
to be supported in the near future can be very easily replicated
by browsers.
How do users know how the event changed the document?
The browser should be able to report all the modifications that
a script makes to the current state of a document being viewed
by the user. This includes for example transition to an entirely
new HTML document, transition to a new document within a frame,
substitution of an image, etc. This type of report should be automatically
provided to the user following the activation of an event, as
described in the previous two questions. Furthermore, the user
should be given the option of "undoing" the event, i.e.
returning to the state of the document, or interaction, that was
valid prior to its activation. This option should be made available
to the user starting with the activation of an event and should
be explicitly, or implicitly declined by the user, after all modifications
made have been presented, and before interaction with the document
may commence again.
ADD
CLARIFY
ADD
There are no comments regarding the rest of the existing sections
under Navigation and Control.
Provide inter-page navigation facilities. Such facilities
may concern memory aids for blind people, non-linear history presentation,
alternative presentation of bookmarks, enhanced feedback for visited
pages or pages in the bookmarks, ageing of pages, etc. Some of
these facilities (along with others proposed outside the scope
of rendering browsers accessible) would benefit disabled and able-bodied
users alike, as they would significantly increase the usability
of a browser.
Preliminary ideas concerning the provision of orientation support
to the user. Bellow are the main questions which appear in the
current version of the guidelines document, followed by our corresponding
proposals.
How does the user know how large a document is?
Size is a difficult issue, as different users perceive size in
different ways. For example, the number of lines could be an indication
of the size of the document, but this would require that a standard
algorithm be used to calculate lines (e.g. 80 "visible",
i.e. non-tag, characters constitute a line). Alternatively, the
number of sentences in the document could be used. The file size
of a document could also be used, but it would only provide a
rough estimate of the relative size of the document: an HTML page
might be 6 Kbytes, for example, out of which only 1 Kbyte results
in "real" information that gets presented to the user
(while the rest is made up of tags, etc).
For blind, or visually-impaired users, an appropriate representation
for approximate document size should be established. For example,
the browser could allow the user to define what in his / her opinion
constitutes a "small", "medium", or "large"
document (e.g. in terms of lines, or sentences). The browser would
then use one of the three alternatives to characterise a document.
How does the user know about the content of the page (headers, tables, frames, links, etc.)?
A good solution for a brief overview of the contents of the page
appears in the current version of the guidelines under the section
Document Summary Information. An alternative type of content
overview is also discussed in the same document, under the section
Document Structural Information. Please also refer to the
corresponding section of this document for a proposal to enhance
the latter type of overview.
How does the user know / find the major topics of the page?
Unless the major topics of a page appear in headings, it is practically
impossible for the browser to locate them (for example, semantic
analysis of the contents of the page would be required). Along
these lines, the issue of supporting the user in identifying the
major topics of a page is equivalent to presenting the user with
a high-level view of the document contents and providing associated
navigation facilities (see previous sections).
Where is the user in the document?
This question pertains mainly to visually-impaired users, since
sighted users have the benefit of the proportional scrollbar thumb,
which is now standard on all major platforms. A possible solution
for visually-impaired users would be to associate the position
of the user in a document with the "amount" of the document
that has already been presented to them. For example, indicating
to a user that s/he is one third of the way through a document,
indicates that there is roughly twice as much information in the
document as they have already "viewed". This idea would
be of value even when users moved through the document without
reading it.
In addition to providing orientation information to the user concerning
the document in its entirety, it is important to extend orientation
support "within" the document, i.e. assist users while
they are reviewing an HTML page. This type of support could also
have the form a brief summary, which, unlike its "global"
counterpart would concern individual "composite" elements.
The term "composite" is used to refer to elements that
are made up of more than one simpler items. Such elements include
lists, image-maps, tables, forms, etc. Indicative types of summaries
that could be provided by the browser in each case are: list with
x list items; image-map with x links; table with x rows and y
columns; form with x elements; etc. The summary could be more
detailed than in the examples above, depending on the expertise,
or preferences of the user (e.g. form with x edit fields, y radio
buttons, a Submit button and a Reset button). Users with print
impairments would greatly benefit from such a feature, as they
would always have an idea of what they can expect next.
ENHANCE
A possible visual representation that could be used for the type
of overview described above would be a hierarchical tree control.
Blind users should also have access to the hierarchical structure
in a slightly different manner: It is difficult to conceive multiple
levels of a hierarchy when presented sequentially (which would
be the case if items at different levels in the hierarchy were
presented "at the same time"). A method usually employed
to overcome this problem, is to "render" levels separately,
i.e. the user is presented with one level of the hierarchy at
a time; when a non-leaf item at that level is selected, the hierarchy
is descended and the subordinate, "lower" level is presented;
the user may continue down the hierarchy, or return to the previous
level.
The proposed structured overview of a document would complement
the "flat" overviews already suggested in the guidelines
and in this document, and would allow experienced users to get
a quick idea of both the type content in the page and the way
in which it has been structured, which is more than often valuable
information in itself.
There are no comments regarding the rest of the existing sections
under Orientation.
This section contains proposals that could not be categorised under the existing sections of the current document.
Browsers should support the incorporation of plug-ins that render information in alternative modalities than the ones directly supported by the browser. In parallel, they should allow for respective style-sheets to be associated and used with those plug-ins. For example, a plug-in that renders text in Braille could be associated with a "tactile" style-sheet. The ability of the browser to render information in multiple modalities in parallel should be preserved when such plug-ins are added.
The browser should be able to relay events from plug-ins to the
user. It should also allow the user to manipulate the state of
plug-ins, to whatever extend possible. As an absolute minimum,
the user should be notified of the activation of a plug-in, the
type of content (a textual description, if available, otherwise
the content identifier) handled by the plug-in, and should be
allowed to start, stop and pause the execution of the plug-in.
An attribute should be introduced in elements that support alternative
textual descriptions, through which page authors could specify
a sound to be used for the alternative representation of an element
in auditory form (e.g. 'ALTSOUND').
The guidelines addressing user agent accessibility that appear
in the Unified Web Site Accessibility Guidelines document
and are not already part of the document for World Wide Web
Browser Guidelines should be incorporated and categorised
accordingly (currently they are categorised by HTML tag).
Future contributions from ICS-FORTH, Greece, will be in the direction
of guidelines that will address the development of Web Browsers
that follow the concept of "direct" accessibility. This
concept advocates the incorporation of accessibility facilities
within the browser application, reducing (and ultimately eliminating)
the need for third-party accessibility software (in the sense
that it will become an inherent part of the application itself).