Re: User Agent Last Call Period Extended to 14 May 2001

Hi Ian,

My responses are indented and preceded by an EJ.

Earl


> [snip]
> 
> ============= 
> > Guideline 2
> > 
> > Nothing about enabling keyboard navigation of content is
> > mentioned here. This is an important aspect of content
> > access but it doesn't seem to be covered in this
> > guideline. The suggestion here is to explicitly mention
> > somewhere in this guideline that keyboard access to content
> > is a part of "Ensure user access to all content."
> 
> IJ: [Editorial] Since this is covered by Guideline 1, I
> think a note and cross reference from the Guideline 2 prose
> should suffice.
>  
EJ	Ok.

> 
> > Then guideline 7 says in part "follow operating
> > environment conventions." But operating environment
> > conventions, with the exception to some extent of
> > Java/Swing, only cover navigation thru and in standard UI
> > toolkit components and in text. But the sum of web page
> > content navigation and control is larger than the sum of
> > what platform guidelines cover. Given this hole and
> > opportunity to expand the usefulness of the UAAG, the
> > recommendation here is that the UAAG committee produce a
> > reference or suggestion document for key sequences for
> > navigating content from the keyboard. Developers who follow
> > what is in this suggested document should be able to feel
> > that by following it they have accounted for all the content
> > navigation oriented stated or suggested in the UAAG and WCAG
> > in their UA design criteria.
> > 
> >         This recommendation applies to UAs targeted at
> >         desktops and other systems powered by standard
> >         keyboards such as QWERTY keyboards not to the broad
> >         range of devices UAs are found today.
> 
> IJ: It is my opinion that we shouldn't do this for a couple
> of reasons:
> 
> 1) Integral to UAAG 1.0 is the idea that we can't dictate
> what keyboard configuration will suit users the best. So as
> a result:
> 
>  a) We require that the user be over to override default
>     bindings (checkpoint 11.3). Configuration, rather than
>     a fixed list, is our approach to this issue.
> 
>  b) We make requirements about the complexity of the
>     keyboard shortcuts (checkpoint 11.4): Single key, etc.
> 
>  c) We have requirements about which functionalities must
>     have bindings by default (checkpoint 11.5), but we do
>     not specify what those bindings have to be.
> 
>  d) We also have requirements for documentation of bindings
>     (11.1 and 11.2), and profiles for saving bindings
>     (11.6).
> 
> 2) UAAG 1.0 does not depend on a particular
> platform. Therefore, we cannot specify key sequences for
> content negotiation since we don't know (a) what all
> keyboards will be like (b) what the standard
> cross-application bindings will be on these platforms (and
> thus the bindings we should not interfere with for content
> navigation).
>    
> Perhaps I've misunderstood your suggestion. Do you have some
> examples to illustrate your request?
> 
EJ	Good point. The real issue isn't what the keysequences are,
	which was seemingly the main point of our suggestion, but which
	things need one to ensure they are specified and none get
	missed. What are your thoughts on digging out and centralizing
	what actions need keyboard support to ensure full access to the
	content is provided?


> Note: I need more information before considering this
> editorial or an issue.
>   
> ============= 
> > Guideline 6
> > 
> > It is not clear where scripts fall in this guideline or what
> > to do with scripts embedded in HTML content. If it causes the
> > display of standard HTML elements in the same way as
> > HTML/XML, what is it considered - another markup language or
> > something that should use platform APIs? How about if the
> > script is on a server but it causes things to happen to the
> > content - is it another markup language or something that
> > should use platform APIs? The recommendation here is the
> > UAAG provide a discussion of answers to the above and other
> > relevant script related questions off this guideline
> > somewhere.
> 
> IJ: Scripts are mentioned explicitly in section 3.5
> Checkpoint applicability. 
> 
> UAAG 1.0 in essence states: if there is a requirement
> related to X, and the user agent is capable of recognizing
> or controlling X, then it must satisfy the requirement. The
> applicability exceptions are listed in section 3.5. 
> 
> We expect that any functionality controlled by the server is
> not therefore subject to control by the user agent. [Again,
> if the UA can do it, it must, but almost by definition,
> "controlled by the server" implies that the UA doesn't
> have control.] So, for example, the Note in checkpoint 2.4
> says:
> 
>     "This checkpoint does not apply when the user agent
>     cannot recognize the time interval in the presentation
>     format, or when the user agent cannot control the timing
>     (e.g., because it is controlled by the server)."
> 
> Strictly speaking, the sentence isn't necessary because it's
> just about applicability (which covers all the
> checkpoints). But enough readers have said "what about
> server-side timing?" that we added this (redundant) note.
> 
> The same applies to scripts: There is a general problem
> recognizing what a script is doing. In some cases, the UA
> can know what a script will do (for example, that a
> particular library function call will open a viewport) while
> in others the UA cannot (for example, that a script
> calculates a factorial). UAAG 1.0 is relying on developers
> to make a judgment about what can be "recognized". We
> provide some information and examples in the Techniques
> document about what should be recognized.
> 
> [Editorial] So, I think UAAG 1.0 already addresses your
> comment, but we could add a statement along the lines of
> what I've just written, for further clarification. This
> might be added to the definition of "script" (since scripts
> are mentioned in more than one Guideline).
>  
EJ	Sounds good.

> > We recommend the definition of applet be added to this
> > document and that it be referred to somewhere in guideline #6
> > (somewhere in 6.4-6.7 or in the general discussion on he
> > guideline).
> 
> [Issue]
> IJ: Ok. Do you have a good one for us?
> 
EJ	How about this one: 
	http://www.its.bldrdoc.gov/projects/t1glossary2000/_applet.html


> I've added this as issue 511
>   http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#511
> 
> =============  
> > Guideline 8
> > 
> > The bullet points under "While developers should implement
> > the accessibility features of any specification, this
> > document recommends conformance to W3C specifications in
> > particular for several reasons:" in guideline #8's general
> > discussion suggest what is meant here is "We recommend you
> > use W3C technologies covered by W3C guidelines in UAs as
> > opposed to using platform specific technology whenever
> > possible for the following reasons:" What is there now
> > currently suggests what is being said is "make sure your UA
> > at least conforms with all W3C specs because:" What is
> > really meant by the statement "While developers should
> > implement the accessibility features of any specification,
> > this document recommends conformance to W3C specifications
> > in particular for several reasons:"?
> 
> IJ: The checkpoints in Guideline 8 say:
> 
>  - Implement the accessibility features of any specification.
>  - Conform to specifications:
>      a) Conform to W3C specification (reasons given above), or
>      b) Conform to non-W3C specification that support
>         accessible authoring.
> 
> Hence this statement has two parts:
> 
>   "While developers should implement the accessibility
>   features of any specification (checkpoint 8.1), this
>   document recommends conformance to W3C specifications in
>   particular (checkpoint 8.2) for several reasons:..."
> 
> We don't actually say "Conform to *at least* W3C
> specifications" because both 8.1 and 8.2 allow conformance
> to non-W3C specifications as part of conformance to UAAG
> 1.0.
> 
> Can you state a little more of what you wish clarified?
> 
EJ	This comment isn't worth expanding on other then to say the
	text of what is there can be interpreted as saying something
	else, something less nuetral (it was a semantics related
	comment). Your clarification above does seeem like an
	improvement however...

> Note: I need more information before considering this
> editorial or an issue.
>  
> ==============
> > Guideline 10
> > 
> > Is this guideline covering both the visual and programmatic
> > aspects of orienting the user? Right now it seems to focus
> > on the visual aspects of orientation. We recommend
> > clarification on this point be placed in the general
> > description for this guideline.
> 
> IJ: [Editorial]. The answer is:
> 
>  a) It's not just visual orientation.
>  b) It's not programmatic orientation.
> 
EJ	b) didn't ring clear in this section, it seemed to focus more
	on a).

> Your question applies to every Guideline: Must these
> requirements be met through the user interface (whether
> visual or other), or does making information available
> through an API suffice? Section 3.7 states (under
> Requirements for content, user agent features, or both):
> 
>    "The user agent must satisfy all requirements involving
>    user interaction (both user input and output to the user)
>    through the user interface of the subject of the
>    claim. This includes not only the requirements that
>    directly refer to to user control, configuration, etc.,
>    but also requirements that indirectly involve the user
>    interface (e.g., system conventions pertaining to the
>    user interface)."
> 
> Let me know if this is a sufficient answer to your comment.
>  
EJ	If the programmatic point came thru clearer... Perhaps reword
	to something like: "This includes not only the visual and
	programmatic requirements that directly refer..."?

> ==============
> > Guideline 12
> > 
> > We recommend specifically saying that the online help
> > documentation provided with the UA must include discussion
> > of all user agent features that benefit accessibility. It is
> > typically where people start when they need to find out more
> > about the workings of a product.
> 
> IJ: [Editorial] This is already covered by checkpoint 12.2.
> The claimant may include any source of documentation they
> wish in the claim. We have not made any requirements about
> document delivery mechanisms: it doesn't matter in UAAG 1.0
> whether the help information is available separately on CD,
> on the Web, or is integrated upon installation. 
> 
> I propose that we recommend that online help include
> discussion of accessibility features, but for the purposes
> of satisfying checkpoint 12.2, it isn't required that this
> information be on the Web.
> 
EJ	Wellll, it really doesn't touch on the original point - having
	it in the product's online help. Isn't this the place anyone
	who is using the product will look first when they have a
	problem or question? If it's agreed that this happens to be the
	case, it seems reasonable and important to specifically state
	this in the UAAG. As somewhat of a counter proposal, perhaps
	our point can be specifically added to the Note?

Received on Sunday, 20 May 2001 16:55:37 UTC