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

Productivity Works (Markku Hakkinen) review of last call UAGL

From: Ian Jacobs <ij@w3.org>
Date: Thu, 02 Dec 1999 15:08:16 -0500
Message-ID: <3846D1B0.A95CF8B6@w3.org>
To: w3c-wai-ua@w3.org
"M. Hakkinen" wrote:
> 
> Hello,
> 
> Sorry for the late arrival of the following.
> 
> --------
> 
> I have reviewed the guidelines and find it an excellent effort to identify
> and determine techniques that can be used to make user agents accessible to
> all. The challenge here is to create a document that will actually be used
> and followed by UA implementers, and in the end result in off the shelf/net
> products that will conform to the guidelines.
> 
> As a member of a commercial entity that seeks to remain viable and
> profitable by selling innovative web access technologies, it will clearly be
> to my firm's advantage in the marketplace to seek the stamp of conformance
> for its products.  However, with the bias in the document toward
> desktop/traditional OS platforms, and with much of my energy devoted to
> developing UAs that are beyond the desktop, I see this document as only a
> starting point in the definition of what makes UAs accessible, whatever form
> they take.  I clearly see in the near term a variety new devices that will
> offer significant accessibility benefits in given contexts, but will have
> difficulty being conformant.  Will the lack of a conformance stamp impact
> the ability of a such a device to be marketed? Perhaps in government
> acquisitions which seek to purchase only conformant products, yes. In the
> general marketplace, unlikely.
> 
> The guidelines can only look so far ahead, and would never be completed if
> all potential UA configurations were considered. WAI needs to continue
> onward with this first step, and draw from the groups engaged in mobile
> access, interactive television, "net appliances", etc.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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".  Does my UA have to allow users to select which type of item
> they wish to turn off? What are the unintended consequences?
> 
> 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. Further, when a live stream
> is presented, speed up is obviously not permitted and slowdown presents
> other problems. This needs to be clarified.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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, ..."
> 
> 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?
> 
> ---
> 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 Thursday, 2 December 1999 15:10:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT