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

Re: comments on section 4

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Thu, 18 Feb 1999 15:26:15 -0600
Message-Id: <199902182128.PAA10437@staff1.cso.uiuc.edu>
To: mark novak <menovak@facstaff.wisc.edu>, w3c-wai-ua@w3.org
The rationale is that even if the documentation is not accessible, somebody
culd still use the user agent.  In general Priority 1 is reserved for the
checkpoints that make it impossible for people to do without the feature.
Priority level 2 still indicates that it is very difficult if it is not
accessible.

We are trying to limit and focus the priority 1 to the items that are most
essential for implementation.

Jon




At 02:00 PM 2/18/99 -0500, mark novak wrote:
>hi
>
>[ February 10th version ]
>
>along with Kitch's comments, I was wondering why 4.1.2, Ensure that product
>documentation is available in at least one accessible, open standard
>electronic
>format (e.g., HTML, XML, ASCII)., was not a priority 1?   Just seems a bit
>strange that so much effort is going into improving the UA, yet  "at least
one"
>accessible form of the documentation is only a "should" (priority 2
>definition).
>
>mark
>
>
>
>>Hi,
>>
>>
>>The following are my comments on section 4, "Ensure that the user interface
>>is accessible." My comments are based on the February 10th version of the
>>guidelines at http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990210/ My
>>comments are preceded by KB: and I've cut any text that I thought was ok as
>>is. I hope they make sense.
>>
>>
>>Kitch
>>
>>
>>
>>Section 4.1 Ensure accessible product installation, documentation, and
>>configuration
>>
>>4.1.1 [Priority 1]
>>     Ensure that the software may be installed in a device-independent
>>manner for all supported input and output devices.
>>
>>KB: I think the words "for all" should be replaced with "using any" so the
>>checkpoint would read
>>
>>     Ensure that the software may be installed in a device-independent
>>manner using any supported input and output devices.
>>
>>
>>4.1.4 [Priority 2]
>>     Follow operating system conventions for user interface design, user
>>agent configuration (including configuration profiles), product
>>installation and documentation, and accessibility flags and interfaces.
>>
>>KB: Should the last word, interfaces, be changed to settings? I assume that
>>this checkpoint means that user agent should pass through OS accessibility
>>settings such as color schemes and font sizes that the user has set in the
>>OS. I don't know if accessibility interfaces is clear.
>>
>>
>>
>>Section  4.2 Support input and output device-independence
>>
>>
>>4.2.3 [Priority 1]
>>     Ensure that the user can activate the links in a document in an input
>>device-independent manner.
>>4.2.4 [Priority 1]
>>     Ensure that the user can activate the form controls in a document in
>>an input device-independent manner.
>>
>>
>>KB: Did we decide on the teleconference that these two checkpoints could be
>>combined into a single checkpoint by substituting "all active elements" for
>>"links" and "form controls" ?
>>
>>
>>
>>Section  4.3 Support accessible keyboard input
>>
>>
>>
>>4.3.1 [Priority 2]
>>     Allow the user to configure keyboard access to user agent
>>functionalities. Configuration includes the ability to specify single as
>>well as multi-key access.
>>
>>
>>KB: This may be a silly question, but will it be obvious to developers what
>>single and multi-key access means? I wonder if the checkpoint should read -
>>Configuration includes the ability to specify single keystroke commands as
>>well as commands that require keystroke combinations.
>>
>>
>>
>>4.3.2 [Priority 2]
>>     Ensure that user can find out about all keyboard bindings.
>>4.3.4 [Priority 3]
>>     Display keyboard bindings in menus.
>>
>>KB: We discussed on the telecon that checkpoint 4.3.4 is covered by
>>checkpoint 4.3.2.
>>
>>
>>
>>  4.4 Ensure that users can disable features that might interfere with
>>accessibility
>>
>>KB: suggested rewording
>>
>>Users must be able to turn on and off support for features that may
>>interfere with accessibility. User agents are only expected to provide [KB:
>>this] control for content that it recognizes [KB: such] as an image,
>>blinking text, etc. For example, an applet may cause text to blink but the
>>user agent may not be able to detect it since the blinking text is
>>generated by an applet rather than markup or style sheets.  A user agent
>>should recognize text that blinks because of markup or style sheets.
>>Details are provided in the techniques document.
>>
>>
>>
>>
>>4.4.12 [Priority 1]
>>     Allow the user to turn on and off support for spawned windows.
>>
>>KB: I know that spawned windows are a problem but I am not sure if it is a
>>priority 1 problem. What do people think? Is it important to let the user
>>turn off this feature or should the user agent just make sure that the user
>>is notified when a new window is spawned?
> 
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess
Received on Thursday, 18 February 1999 16:28:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:22 UTC