W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 1999

Comments and suggestions related to current guidelines

From: Jon Gunderson <jongund@cmos-eng.rehab.uiuc.edu>
Date: Thu, 29 Jul 1999 12:08:59 -0500 (CDT)
To: ij@w3.org
cc: w3c-wai-ua@w3.org
Message-ID: <Pine.LNX.3.96.990729120429.8083A-200000@cmos-eng.rehab.uiuc.edu>
I have attached a text file with comments related to the current
guidelines through guideline 7.  I hope to get to the rest of the
guidelines this afternoon.  I have included some suggested text for sub


P.S.  I am using a temporary e-mail address so if you want to reply please
use jongund@uiuc.edu.  The mail server is down at UIUC today.

Status of Document Section:

Broken link

Currently: www.w3c.org/wai/ua/wai-ua-members.html

Should be: www.w3.org...


1. Introduction

change "rely on of other user agents "  to " reply on other.."

Add specialized browsers for specific disabilities to the list of types of dependent user agents


Ensure that the user interface is accessible

JRG: Suggest 2 changes:

built into the tool as well as those offered via the document: links, form controls, applets, and other interactive elements. 


built into the tool (menus, dialogs, toolbars and other user interface components) as well as those offered via the document: links, form controls, applets, and other interactive elements. 

some pointers


some references


Guideline 1. Support input and output device-independence

No comments at this time


Guideline 2. Ensure keyboard access to user agent functionalities

Checkpoint 2.5 Allow the user to turn on and off author-specified keyboard configurations. [Priority 2] Techniques for checkpoint 2.5 

JRG: Does checkpoint 2.5 currently only refer to ACCESSKEY bindings?

If it only relates to ACCESSKY, maybe we just want to have a checkpoint that states this more directly, like the ability to turn on or turn off ACCESSKEY bindings


Checkpoint 2.6 Indicate the keyboard access method to activate a user agent function using platform conventions. [Priority 2] Techniques for checkpoint 2.6 

JRG: Does checkpoint 2.6 currently only refer to how to activate an author supplied ACCESSKEY binding to a link or a control?

If it is only related to ACCESSKEY, then maybe it should be stated for ACCESSKEY in the checkpoint.  Otherwise I am not sure how it is different from checkpoints 2.2 and 2.3


Checkpoint 2.7 Avoid default keyboard configurations that interfere with system conventions. [Priority 2] 

JRG: A better example maybe the use of ALT-F4, since that is used to close an application in Windows.  Or the F10 key to move the application focus to the menu in windows.  Ctrl-Alt-Delete just seemed a little extreme to me.


Checkpoint 2.8 Provide a default keyboard configuration for frequently performed operations. [Priority 3] 

JRG: Seems redundant with checkpoint 2.1 and related to 2.4.  Its relationship to 2.4 seems to be that if the user can configure, part of that should be able to return to the default settings.  I would suggest combining the two checkpoints


Guideline 3: 

JRG: Some additional sub-heading text

Documentation on specific features of the user agent that enhance accessibility is important since many of the features used by persons with disabilities are often not generally known to the average user.    Documentation that clearly indicates the features useful to people with disabilities therefore can be extremely important for users with disabilities and people trying to assist people with disabilities to know how to optimize the user agent for the most efficient access to web content.


Guideline 4. Allow the user to configure the user agent

JRG: Some sub-heading text

The user needs to be able to configure the user agent on how to render web content and the types of controls available to select user agent functions.   People with disabilities have a wide range of functional capabilities, even people with the same diagnosis often have significant individual differences.  It is important for user to configure the user agent to optimize their access to web content based on their specific capabilities.


Guideline 5: Allow the user to turn off features that may reduce accessibility 

JRG: Some sub-heading text

The ability to turn on and off the rendering of primary or alternative content is one part of allowing the user to configure the user agent to their preferences.  Some types of disabilities can only use alternative content and need to be able to enable the rendering of the alternative information.  The rendering of other types of web content may obscure or mask primary or alternative information and that information needs to be turned off.  Dynamically changing web content can be a problem for people using some types of assistive technology and for people prone to epileptic seizures and user need to be able to turn off the sources of dynamic content.

JRG: Would like to add a checkpoint related to turning on or off the rendering of tables at a priority 3.  It is currently implemented in Opera and the screen reader JAWS.  It maybe both a useful interim and long term solution to people improve access to web content for some types of disabilities.  It is also similar in intent as 5.10 and 5.12 in terms of removing spatial formatting.  Some disability groups may also be looking for this type of feature during public reviews.


Guideline 6: Ensure user control over document styles 

JRG: Suggest changing  

"Users who are color-deficient may not be able to perceive certain color combinations"


"Users with visual impairments, including color blindness, are typically insensitive to certain colors and may not be able to perceive author specified color combinations"

JRG: Suggest changing:

"Users with low vision may require large fonts."


"Users with reduced visual acuity, including people who are older, may require larger fonts than the fonts specified by the author."

JRG: May also want to add in the sub text that this is part of user configuration.  Should we also have a reference to Guideline 4

JRG: Suggested addition

Add "older and color blind" to the list of people in the following statement

Otherwise, users who are blind, have visual impairments, 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. 

JRG: Checkpoint 6.12 should be priority one for people with hearing loss


Guideline 7: Ensure user access to document content 

JRG: Additional sub text

The primary or alternative content may be rendered to the user though character, graphic, audio, speech or Braille.  Each of these presentation mediums has their own characteristics of rendering information to a user.  Each medium should allow the user to adjust and control the rendering to meet their specific needs.  

For example, speech is a temporal medium.  Speech output based browsers therefore need features that allow the user to render sub-structures of text content like paragraphs, sentences, words and the spelling of individual words.  These types of features are needed for speech since certain words or phrases may not be properly converted from their original text to their correct speech pronunciation.  By allowing the user to access sub-structures of text the user cam replay and even spell words and phrases until the user understands the content.   Speech based user agents also need to convey the type of element text content is associated with similar to they way graphical browser use spacing and font characteristics to indicate the elements type.   Speech can use the pitch, articulation model, volume, and orientation text to provide element information.  For example, announcing the word "header" before the text content of a header or "item 1" before the text content of the first item in an ordered list element.  Speech can also automatically change languages if the author provides markup to indicate changes in language, the same way a user agent support changes in fonts as the author specifies changes in language.

JRG: Checkpoint 7.12 Provide a mechanism (e.g., through style sheets) to distinguish visited links from unvisited links [priority 3]

Seems to be linked to the checkpoint, 

9.16 Make available whether a chosen link (target) has already been visited. [Priority 3] 

On the surface the two checkpoints seem to be saying the same thing.  I think 7.12 is focused on the style of rendering the information, implying the user will be able to perceive the information.  I like 7.12 more than 9.16 and maybe it would be better to move 9.17 and 9.18 to section 7 as:

Provide a mechanism (e.g., through style sheets) to distinguish fee based links from free links [priority 3]

Provide a mechanism (e.g., through style sheets) to distinguish internal links from external links [priority 3]

I am not sure if current style sheets support these distinctions 

Received on Thursday, 29 July 1999 13:04:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:22 UTC