- From: David Poehlman <poehlman@clark.net>
- Date: Tue, 10 Aug 1999 12:24:04 -0400
- To: draft@clark.net, WAI User Agent Working Group <w3c-wai-ua@w3.org>
- Message-ID: <37B05224.1EE447A1@clark.net>
I've attached a document containing comments and commented portions of the aug 9 draft <text version> of the ua guidelines for archiving and review. I have several designations just after the *dp* that indicates my comments. <lang> is a language comment>, <proof> catches what may be a slip up in typing or composition, <question> and there are lots of these seeks clarification either in the document or from others as to how the commented portion should be understood. <slant> concerns my take on the slant on the current document and how that might change or could change to make it more reflective and palatable under certain circumstances, and I think the last is <comment general> there is only one of these and it will be easy to understand. Thanks! -- Hands-On Technolog(eye)s Touching The Internet: mailto:poehlman@clark.net Voice: 301.949.7599 ftp://ftp.clark.net/pub/poehlman http://poehlman.clark.net Dynamic Solutions Inc. Best of service for your small business network needs! http://www.dnsolutions.com ---sig off---
Abstract
This document provides guidelines to user agent manufacturers for
making their products more accessible to people with disabilities and
for increasing usability for all users. This document emphasizes the
accessibility of interoperability between two important classes of
user agents - graphical desktop browsers and dependent assistive
technologies (screen readers, screen magnifiers, braille displays, and
voice input software). However, it is meant to be applicable to user
agents in general, including text and voice browsers, multimedia
players, and plug-ins.
*dp* <lang> I propose we change manufacturers to either developpers or manufacturers / developpers or manufacturers and or developpers or some permutation there of? This being as some will develop for manufacturers and some will develop for other reasons. If a manufacturer, of course, it is the primary responsibility of the manufacturer to put the stamp of approval on the product.
1. Introduction
For those unfamiliar with accessibility issues pertaining to user
agent design, consider that many users may be using documents in
contexts very different from your own:
* They may not be able to see, hear, move, or may not be able to
process some types of information easily or at all.
* They may have difficulty reading or comprehending text.
* They may not have or be able to use a keyboard or mouse.
* They may have a text-only screen, a small screen, or a slow
Internet connection.
* They may not speak or understand fluently the language in which
the document is written.
* They may be in a situation where their eyes, ears, or hands are
busy or interfered with (e.g., driving to work, working in a loud
environment, etc.).
*dp* <lang> the use of the word document above fits well with the wcad, but since this is the ua document, shouldn't the word application be here instead? Or even better, user agent sans browser?
The guidelines in this document are designed to help developers
understand and thereby reduce accessibility barriers that impede
access to the Web. The associated Techniques Document
([UA-TECHNIQUES]) provides practical solutions based on existing and
upcoming technologies. Though developers may believe that implementing
accessibility features in their products is difficult or of limited
use, considering accessibility during the design phase of a product
leads to more flexible, manageable, and extensible software.
*dp* <slant> earlier in the document, we tallk about hands busy and eyes busy, so I propose that we change the above and similar wording to reflect a more positive move integrating features that make access more universal? I have taken a stab at this below:
The guidelines in this document are designed to help developers
understand and thereby impliment solutions which broaden accessibility
to the Web. The associated Techniques Document
([UA-TECHNIQUES]) provides practical solutions based on existing and
upcoming technologies. Though developers may believe that implementing
accessibility features in their products is difficult or of limited
use, considering accessibility during the design phase of a product
leads to more flexible, manageable, and extensible software.
these guidelines include information relevant to a wide class of user
agents: graphical desktop browsers, screen readers, speech
synthesizers, multimedia players, text browsers, voice browsers,
plug-ins, etc., with a particular focus on two classes of user agents:
1. Graphical desktop browsers
2. Dependent user agents, which rely on other user agents for input
and/or output. Dependent user agents include:
+ screen magnifiers, which are used by people with visual
impairment to enlarge and change colors on the screen to
improve readability of text and images.
+ screen readers, which are used by people who are blind or
with reading disabilities to read textual information through
speech or braille displays.
+ alternative keyboards, which are used by people with movement
impairments to simulate the keyboard.
+ alternative pointing devices, which are used by people with
movement impairments to simulate mouse pointing and button
activations.
*dp* <lang> in the document's opening , we discuss dependant assistive technology, should not the nomenclature be more consistant?
3.3 Describe product features known to promote accessibility in a
section of the product documentation. [Priority 2]
Techniques for checkpoint 3.3
*dp* <lang> a note here about action description though we may not want to be this specific. I propose we add something here about writing the documentation so that it is clearly designed in an approach that is device independant such as not using click here or press enter here unless alternatives are also specified.
Guideline 4. Allow the user to configure the user agent
Next guideline: 5 | Previous guideline: 3 | Go to contents
Subhead here.
Individuals with disabilities have a wide range of functional
capabilities and so they must be able to configure the user agent to
meet their particular requirements. Users must be able to configure
rendering, mouse, keyboard, user interface control position, etc. to
facilitate their daily use of the software.
*dp*<slant> see above comments for a slant on this but perhaps the words web users instead of individuals with disabilities could be used. One of the problems with <selling> accessibility is that it has the smack of catering to a particular clas or classes of individuals.
Refer also to guideline 2. Refer also to checkpoint 9.10.
Guideline 5. Allow the user to turn off features that may reduce
accessibility
Next guideline: 6 | Previous guideline: 4 | Go to contents
Subhead here.
Some rendering behavior may make the user agent unusable or may
obscure information. For instance, people with photosensitive epilepsy
must be able to turn off flashing within certain ranges, otherwise the
flashing may trigger a seizure. Users who require specific color
contrasts or who have low vision need to be able to turn off
background images if those images interfere with their ability to read
text. Dynamically changing web content or opening windows can be a
problem for people using some types of dependent user agents and may
be disorienting to users with cognitive disabilities.
*dp* <clarification> also, flashing causes my screenreader to repeat the flashed material every time it flashes.
User agents are only expected to provide this control for content or
user interface controls that it recognizes. Please also refer to
guideline 6 and guideline 4.
5.1 Allow the user to turn on and off rendering of images.
[Priority 1]
Techniques for checkpoint 5.1
5.2 Allow the user to turn on and off rendering of background images.
[Priority 1]
Techniques for checkpoint 5.2
5.3 Allow the user to turn on and off rendering of video. [Priority 1]
Techniques for checkpoint 5.3
*dp* <question> what is the justification for this?
5.4 Allow the user to turn on and off rendering of sound. [Priority 1]
Techniques for checkpoint 5.4
5.5 Allow the user to turn on and off rendering of captions.
[Priority 1]
Techniques for checkpoint 5.5
5.6 Allow the user to turn on and off animated or blinking text.
[Priority 1]
Note. This is particularly important for users with screen
readers.
*dp* <note> this makes my earlier point.
Techniques for checkpoint 5.6
5.7 Allow the user to turn on and off animations and blinking images.
[Priority 1]
Techniques for checkpoint 5.7
5.8 Allow the user to turn on and off support for scripts and applets.
[Priority 1]
Note. This is particularly important for scripts that cause the
screen to flicker, since people with photosensitive epilepsy
can have seizures triggered by flickering or flashing in the 4
to 59 flashes per second (Hertz) range.
Techniques for checkpoint 5.8
5.9 Allow the user to turn on and off support for user style sheets.
[Priority 1]
Techniques for checkpoint 5.9
5.10 Allow the user to turn on and off support for author style
sheets. [Priority 1]
Techniques for checkpoint 5.10
5.11 Allow the user to turn on and off support for spawned windows.
[Priority 1]
Techniques for checkpoint 5.11
*dp* <question> What happens if a window is not spawned and that action predicates something that must be done by the user such as filling a form?
5.12 Allow the user to turn on and off rendering of frames.
[Priority 2]
Techniques for checkpoint 5.12
*dp* <question> similar to above?
5.13 Allow the user to turn on and off author-specified page forwards
that occur after a time delay and without user intervention.
[Priority 3]
For example, when turned off, offer a static link to the target
resource instead.
Techniques for checkpoint 5.13
*dp* <question> is this not a wcad issue with regard to what is rendered or can the ua make this call?
5.14 Allow the user to turn on and off automatic page refresh.
[Priority 3]
For example, when turned off, allow the user to refresh the
page manually instead (through the user interface).
Techniques for checkpoint 5.14
Guideline 6. Ensure user control over document styles
Next guideline: 7 | Previous guideline: 5 | Go to contents
Ensure that the user has control over the colors, fonts and other stylistic
aspects of a document and can author styles and user agent default styles.
In order to access a document, some users may require that it be
rendered in a manner other than what the author intended. Users with
visual impairments, including color blindness, may be insensitive to
certain colors and may not be able to perceive author-specified or
user agent default color combinations. Users with reduced visual
acuity, including people who are older, may require larger fonts than
user agent defaults or those specified by the author. Users who are
blind may require audio or tactile rendering. Users who are deaf may
require captions for audio files.
User agents must therefore allow the user to control:
* The document's style (e.g., fonts, colors, aural parameters, etc.)
* The document's formatting: whether the document is presented
textually, graphically, linearly, aurally, for tactile use, or
some combination of these.
* The document's content. This means whether primary content or
alternative representations of content or both are rendered.
* The user interface. Since authors may make changes to the user
interface through scripting (e.g., by spawning new windows,
causing dialog boxes to appear, etc.), users must be able to
override changes that make the user agent or document
inaccessible.
Otherwise, users who are blind, have low vision, color deficiencies,
some types of learning disabilities, or any user who cannot or has
chosen not to view the primary representation of information will not
know content of the information on the page.
*dp* <lang> insert the word "the" above?
Guideline 7. Ensure user access to document content
Next guideline: 8 | Previous guideline: 6 | Go to contents
Ensure that users have access to primary as well as author-supplied
alternative representations of content (descriptions of images, captions
for video or audio, etc.)
Otherwise, some users cannot perceive the primary content due to a
disability or a technological limitation (e.g., browser configured not
to display images).
The primary or alternative content may be rendered to the user though
character, graphic, audio, speech, or braille devices. The differing
characteristics of these devices mean that user requirements and
capabilities will vary.
*dp* <proof> though above should be through.
For example, speech is a temporal medium. Speech output based browsers
must convey sub-structures of text content like paragraphs, sentences,
words and the spelling of individual words to the user as certain
words or phrases may not be properly converted from their original
text to their correct speech pronunciation. By conveying
sub-structures of text, user agents allow users to replay and even
spell words and phrases until the user understands the content and
context. Speech-based user agents must use auditory nuances -
including pitch, articulation model, volume, and orientation - to
convey meaning the way fonts, spacing, and borders do in graphical
media. For example, a user agent might speak the word "header" before
the text content of a header or "item 1.4" before a list item to
convey context. Speech-based user agents must also heed
author-specified markup that indicates changes in natural languages,
and should render appropriately for supported languages.
*dp*<lang> the word link before a link is a good example of this.
*dp* <comment general> I like 9.
Guideline 10. Notify the user of document and view changes
Next guideline: 11 | Previous guideline: 9 | Go to contents
It is important to alert users, in an output device-independent fashion,
when important events occur during a browsing session.
To avoid confusion that the effects of scripts may cause, users should
be notified when scripts are executed (or be able to disable scripts
entirely). This is also important for security reasons; users should
be able to decide whether to allow scripts to execute on their
machines.
10.1 Provide information about document and view changes (to the user
and through programming interfaces). [Priority 1]
For example, inform the users when a script causes a popup menu
to appear.
Techniques for checkpoint 10.1
*dp* <proof> should not users be user? or drop the word the in the users and just leave users?
10.2 Ensure that when the selection or focus changes, it is in the
viewport after the change. [Priority 2]
Techniques for checkpoint 10.2
10.3 Allow the user to configure the user agent for notification of
certain types of document changes only. [Priority 3]
Techniques for checkpoint 10.3
*dp* <Lang> This is unsettling to me. I feel it should be differently put because it doesn't convey exactly what is meant or what I percieve it to mean. I'd like this to allow me to have the opportunity to pick one or several from a list of things I want to be notified about? It has something to do with the word only.
10.4 When loading a document, make available what portion of the
document has loaded, whether loading has stalled, and when the
user may begin to browse. [Priority 3]
Techniques for checkpoint 10.4
10.5 Make available what portion of the document the user has viewed.
[Priority 3]
Note. Depending on how the user has been browsing, the
percentage of document viewed may be calculated according to
focus position, selection position, or viewport position.
Techniques for checkpoint 10.5
10.6 Allow the user to request to be prompted before a form is
submitted. [Priority 3]
Techniques for checkpoint 10.6
---end of commented portions of document---
Received on Tuesday, 10 August 1999 12:53:39 UTC