Re: comments on section 4

Almost every day, I get a call from someone who wants to use the web but
has never laid their hands on a computer and will likely not do so if they
can't figure out how to use either the computer or the software on the
computer.  So I have to ask, where do these persons fit in the priority of
needing documentation for a user agent they no nothing about and thus can
not use said agent to read the documentation.  This is a bit of a catch 22
is it not?  If you can't use the agent, you can't read the documentation.
If you can read the documentation, you can't use the agent.  What should I
tell all the people who call wanting internet access?  I could tell them
that they have to learn to use the agent in order to read about how to use
the agent, but I don't think they will do it.  I don't think some of them
can do it.  So, Do I really have to tell them that we think it is a
priority two and they are just out of luck?

I don't mean to be harsh about this, but I think this is exactly what we
are saying.  I understand the need to get our priorities in order.  But I'm
still at a loss as to how to reconcile the fact that a person's only
ability to learn about the agent is a priority two.

At 03:26 PM 2/18/99 -0600, Jon Gunderson wrote:
>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 Tuesday, 23 February 1999 11:08:59 UTC