- From: Ian Jacobs <ij@w3.org>
- Date: Sat, 04 Dec 1999 20:26:28 -0500
- To: w3c-wai-ua@w3.org
Ian Jacobs wrote:
>
> "M. Hakkinen" wrote:
> > On to specific comments:
> >
> > SECTION 1.5 - Supporting a multi-lingual UA results in instances where
> > "non-standard" APIs may be needed to communicate with a synthesizer for a
> > given language. For example, there are many synthesizers that do not have a
> > MS-Windows SAPI compliant interface.
I think that if a standard API is not available, then the UA would
would not be able to use it. Does the "applicability" exception address
your concern?
> > In an audio browser, it would be desirable to review recently presented
> > messages (message repeat). This is important for announcements of events
> > that may have been missed or not understood the first time by the listener.
This sound either like a technique for providing access to content
and/or related to issue 135: incremental fast forward and rewind.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#135
> > SECTION 2.3 - When switching synthesizer based upon natural languages, the
> > UA may incur significant processing delays that can hinder understanding
> > (e.g.., "The greeting 'Good Day' is expressed as <span lang="fi">Hyvää
> > Päivä</span> in Finnish, <span lang="fr">Bonjour</span> in French, ...").
> > Further, announcements of language switching can interfere with the
> > presentation. The user should be able configure whether or not language
> > switching is active, and specify whether announcements indicating the switch
> > are to be presented.
There is not currently a requirement to checkpoint 2.3 to
notify users of the language switching.
I'll add the proposal to allow users to turn off language switching
as issue 167.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#167
> > SECTION 2.7 - I would extend this and allow the user to request the name of
> > the object, as that in some cases may help identify its purpose.
Do you think a techniques discussion of this is sufficient, or should
there be a checkpoint-level requirement to have the object
name available. What if the resource is not easily nameable (e.g.,
the URI is part of a query to a database)? (The same argument may
be made for object type, but there may be more information, e.g.,
"type" attribute HTTP headers, etc. to identify object type).
Added as issue 168.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#168
> > SECTION 3.4, 3.5, 3.6 - I have some challenges here, in that it will be
> > difficult in some contexts to know what elements on a page may fall into
> > these categories. Animations may be achieved by GIF, DHTML, SMIL 2.0,
> > player plug-ins, applets, etc. I have created examples of "animated banner
> > ads" that look visually the same, but are implemented by different
> > "technologies".
The "applicability" clause comes into play here:
<BLOCKQUOTE>
A checkpoint applies to a user agent unless:
* The checkpoint includes requirements about a content
type (script, image, video, sound, applets, etc.) that
the user agent does not recognize at all.
</BLOCKQUOTE>
Thus, if the UA can't tell, it doesn't have to support control. If
a plug in or some other user agent renders the content, that plug
in or user agent is responsible for the control.
> > Does my UA have to allow users to select which type of item
> > they wish to turn off?
I'd suggest that if the user interface here is designed with
accessibility in mind, the user should not have to know about
the object technologies. "Please turn off blinking things" would
be a convenient request to the user agent. If the user agent
allows the user to turn off the objects through other means
(e.g., by turning off scripts), then this would also be
sufficient, but the user agent should document that this is
how the user can achieve this particular goal.
Question added as issue 169
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#169
> > What are the unintended consequences?
Can you expand on this question?
> > SECTION 4.11 - Some audio codecs may not support speed up and slow down,
> > something that is out of the control of the player. A UA may therefore be
> > out of conformance through no fault of its own.
Nope, another clause from the definition of "applicability":
<BLOCKQUOTE>
A checkpoint applies to a user agent unless:
* The checkpoint refers to the properties of an
embedded object (e.g., video or animation
rate) that may not be controlled or accessed by the user agent.
</BLOCKQUOTE>
I'd like to note here that the "applicability" definition used to
be in the section of the guidelines on conformance. The Working Group
decided to move it to the glossary, but I'm beginning to think that
it deserves more visibility up front.
> > Further, when a live stream
> > is presented, speed up is obviously not permitted and slowdown presents
> > other problems. This needs to be clarified.
I would argue that the previous comment applies here too, but I will
happily add a note after the checkpoint:
User agents may not be able to control the playback rate for
some audio formats.
> > SECTION 4.16 - It is sometimes the case that a synthesizer will only support
> > one gender. The UA may provide support for gender switching, but may not
> > meet this checkpoint because of limitations in a user selected synthesizer.
> > This may be particularly true as we address the non-english speaking
> > synthesizers. This sections should clarify that the UA should allow
> > switching of these synthesizer characteristics, IF supported in the
> > synthesizer selected by the user.
The checkpoints on speech only apply to user agents that do speech
synthesis natively. If the UA itself doesn't support gender switching,
then this checkpoint doesn't apply.
> > SECTION 5.6 - It is likely that a number of devices will not be able to meet
> > this priority 1. As I interpret the document, I assume that I can strike
> > this Priority 1 as "Not Applicable". I'd like to see this more clearly
> > stated.
Can you list some scenarios where this would not apply? For instance,
I can imagine that in a stand-alone system where no interfaces are
used, this would not apply.
> > SECTION 7.7 AND 7.8 - Familiar elements can be expanded to include the
> > "class" attribute. For example, if an author uses:
> > <DIV CLASS="abstract">
> > and
> > <DIV CLASS="author-bio">
> >
> > to signify abstracts and biographical information in a page of publication
> > descriptions, the user should be able to:
> >
> > 1. Identify a list of elements with classes and what those classes are
> > 2. Navigate to those elements determined by a class name.
I'll add this as a technique.
> > SECTION 8.3 - Assuming (unfortunately) that a large body of content lacks
> > header elements, or uses headers in a non-intuitive fashion by relying on
> > styling to achieve "headers", it is unlikely in many cases that a meaningful
> > table of contents can be constructed. There may be value to allowing
> > "creative" interpretation by the UA of document elements to create this
> > view, and certainly to allow users the option to alter what elements are
> > displayed.
Configuration of the view is covered by checkpoint 8.6:
"Allow the user to configure the outline view."
As for creation of the outline view, if you have repair techniques, they
would
be welcome. I don't know whether we can require user agents to handle
idioms that misuse presentation to represent structure since the list of
those
idioms is not well-defined.
> > SECTION 10.3 - change wording: "For self-voicing browsers, allow the user to
> > modify what voice commands activate
> > functionalities". This should read: "For voice-activated browsers, ..."
Yes. Wendy made a similar comment and I'll fix throughout the document.
> > GENERAL COMMENT:
> >
> > Conformance can be highly dependent upon the content being rendered. A UA
> > vendor may make significant efforts to support guidelines, and verify
> > through test cases using diverse web content that conformance is robust.
> > However, with the mass of poorly constructed legacy content, and
> > "innovations" in web design that move faster than any standards body, what
> > recourse is there for a UA developer when challenged by a user that a site
> > or content is not accessible?
> >
> > My suggested policy (and one that I would certainly include in any fine
> > print regarding conformance), is that the content is only certified
> > accessible using my UA IF the content being rendered meets the WAI Content
> > Authoring Guidelines. Of course my UA will do the best it can with
> > inaccessible content, but I cannot guarantee accessibility to all content.
> > Can this be expressed clearly in the Guidelines where conformance is
> > discussed?
I will add this question as issue #170
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#170
Thanks Mark!
- Ian
> > ---
> > Markku T. Hakkinen - The Productivity Works, Inc.
> > Trenton, New Jersey USA - +1 609 984 8044
> > hakkinen@prodworks.com - http://www.prodworks.com
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Saturday, 4 December 1999 20:26:57 UTC