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

Re: March 9 Draft of UAAG

From: Ian Jacobs <ij@w3.org>
Date: Mon, 19 Mar 2001 12:16:35 -0500
Message-ID: <3AB63EF3.BEC80A7F@w3.org>
To: Denis Anson <danson@miseri.edu>
CC: w3c-wai-ua@w3.org
Denis Anson wrote:
> Some comments on the current draft, in preparation for the meeting.

Hi Denis,

Thank you for these comments (most of which we addressed at
the 15 March teleconf [1]). Some comments preceded by IJ: below.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0427

> Abstract:
> By following these guidelines, developers will create more usable
> software for all Web users. [DA: Actually, only for users of the browser
> in question.  Web authoring guidelines improve access for anyone who
> accesses a page, but UA guidelines only help those using a specific user
> agent.  What we really mean is that following the guidelines will
> improve access for all uses of the user agent, including those with
> disabilities.]

IJ: I disagree with your interpretation (though I take note of it).
Our intention is to say: "Accessible design is good design, so
if you meet these requirements, you will also benefit a larger 
audience than just users with disabilities."

> In Section 1.1:
> .       UAAG 1.0 includes several repair requirements (e.g., checkpoints
> checkpoint 2.7 and checkpoint 2.10) for cases where content does not
> conform to WCAG 1.0. Furthermore, some requirements in this document
> support authoring practices that may be widely deployed but that are
> discouraged because they cause accessibility or usability problems
> (e.g., some uses of HTML frames).[DA: This seems to be saying that this
> document is supporting practices that cause access problems!  Surely
> that isn't what we mean.]

New text:

"Furthermore, this
document includes some requirements to address 
 certain widespread authoring practices that are discouraged because 
 they may cause accessibility or usability problems (e.g., some uses 
 of HTML frames)."
> Guideline 1:
> People who cannot or do not use a mouse have to be able to operate the
> user interface with the keyboard, through voice input, a head wand,
> touch screen, or other device. [DA: In this context, a head-wand is a
> means of accessing the keyboard, and a touch screen is generally a mouse
> emulator, so these examples are actually just restating mouse and
> keyboard.  Why not consider input methods there that do not rely on
> standard mouse and keyboard presence: such as Morse Code or
> single-switch scanning. ]

IJ: The introduction ("Known limitations of this document")
explains that this document "only includes requirements for 
keyboard, pointing device, and voice input modalities.
> Checkpoints 1.1 through 1.3
> [DA: As written, this seems to say that you can choose to implement
> mouse only, keyboard only, or voice input only interfaces, and claim
> such conformance.  I understood us to intend that you must provide
> keyboard interface, and may provide mouse and voice interfaces.  

IJ: Yes, that's true. Refer to recent proposal on this topic:

> Even
> devices that do not have keyboards should have an API that supports
> keyboard control to facilitate use of AT. ]

[I have snipped a bunch of comments addressed at the 15 March teleconf.]

> 2.7 Allow configuration to generate repair text when the user agent
> recognizes that the author has failed to provide conditional content
> that was required by the format specification. If the missing
> conditional content is included by URI reference, base the repair text
> on the URI reference and content type. Otherwise, base the repair text
> on element type information. [Priority 2]
> DA: I agree with Ian here that the information in the URI is a minimal,
> but certainly not optimal repair text.  This might be the minimum
> implementation, but other solutions should be supported.

IJ: Ok.
> 2.9 Allow configuration to create the conditions under which conditional
> content is rendered. [Priority 3]
> Note:
> DA: I'm not sure what this means.  Doesn't conditional text, by
> definition, have attached conditions?  Perhaps we mean that the user
> agent should allow configuration to modify the conditions under which
> conditional text is rendered?

IJ: Refer to proposal to clarify:
Thanks Denis,

 - Ian

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Monday, 19 March 2001 12:16:54 UTC

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