RE: Action Item: Investigate wording for possible third class agent for conformance section

I am coming to believe we need to have a different sub grouping for
"targeted" or "specialized" user agnets that are trying to improve access
for a particular disability.  It would have some of the features of both
the DGUA and DUA subgroups.  I think that our guidelines should help people
who are trying to do the thinks HPR, pwWebSpeak and VPInfoNet are trying to
do and I think we have a good sub classing for DGUA and technologies that
depend on them for access.  I will try to write a proposal soon for this class.

Jon


At 10:35 AM 9/1/99 -0500, thatch@us.ibm.com wrote:
>
>
>The Home Page Reader conformance question has the following parts:
>
>(1) Checkpoints address features we do not support. We say n/a. Because HPR 
>only
>supports text (supports no multimedia or graphics), we have entered n/a for
>priority 1 items like 5.1-5.11, etc. If this is not a valid reason for "n/a"
>what is?
>
>(2) HPR is an agent targeted for users with disabilities who rely on
speech and
>keyboard.
>
>(2A) The visual user interface is irrelevant in this product.  Although I
wrote
>"no" in 6.1-6.6 (low vision items), I should have written n/a.
>
>(2B) Similarly, I entered "no" to 1.1, because there are things you cannot do
>with the mouse, in fact you cannot do them without speech. It really is n/a
>because keyboard input and speech output are the supported I/O. (You must use
>the keyboard and speech output to use the settings menu. )
>
>(2C) All the standards and conventions checkpoints (12.*) are not
applicable to
>HPR. If an assistive technology is to interact with a user agent, it
should not
>be interacting with a targeted agent. We are an assistive technology; 12.* 
>is to
>accommodate assistive technologies.
>
>(3) We have issues with some priority 1 checkpoints. We can't conform
(priority
>1) as a DUA because we do not comply with 7.3 (nor support its priority) -
>render according to natural language identification.
>
>(4) Finally there are checkpoints that we believe should apply to us and 
>that we
>fail. Checkpoints 1.2 (interact with all active elements) and 5.8 (turn on/off
>support for scripts) are not met by HPR because HPR does not support active
>JavaScript elements, and you cannot turn off JavaScript (our startup process
>involves JavaScript). That is an acknowledged weakness of HPR. 
>Interestingly, we
>might place this non-conformance into (1) above, and claim we do not support
>JavaScript, therefore 5.8 and failure of parts of 1.2 are n/a.
>
>
>Jim Thatcher
>IBM Special Needs Systems
>www.ibm.com/sns
>thatch@us.ibm.com
>(512)838-0432
>
>
>Jon Gunderson <jongund@uiuc.edu> on 08/31/99 03:38:06 PM
>
>To:   "Denis Anson" <danson@miseri.edu>, Richard
Schwerdtfeger/Austin/IBM@IBMUS
>cc:   w3c-wai-ua@w3.org
>Subject:  RE: Action Item: Investigate wording for possible third class    
>agent
>      for conformance section
>
>
>
>
>
>I would like to clarify my view of conformance:
>
>1. The two current sub groups came out of a need seen by the group to
>develop minimum standards for commercial mainstream browsers and plug-ins
>like Netscape Navigator, Microsft Explorer, Opera and multi-media
>technologies for accessibility. A second need seen by the group is to
>indicate the types of additional features for technologies like specialized
>browsers and other types of "assistive technology" that provide advanced
>features to access to web content to persons with severe disabilities that
>is currently beyond the scope of current browser technology (i.e. speech,
>refreshable Braille).
>
>2. Part of what the priorities of the checkpoints need to indicate which
>checkpoints are currently more important and therefore should be developed
>first.  The priorities of checkpoints for the different sub-groups are not
>normative and could change over time as technology changes.  Some
>checkpoints could even have different priorities in each sub-group
>(currently there are none).
>
>3. Part of the work of testing the guidelines is to determine what
>chekpoints work for which technologies.  What we want is more usable
>interfaces for people with disabilities and that should be our focus.  So
>while assistive technology being compatible with other assistive technology
>is a great goal and would help people with mulitple disabilities is it the
>first thing we want AT developers to consider right now, or are other
>checkpoints more important.
>
>Jon
>
>
>At 08:40 AM 8/31/99 -0400, Denis Anson wrote:
>>Rich,
>>
>>This proposal would be fine were it not for the fact that people with a
>>primary disability (such as blindness) sometimes also have a secondary
>>disability, such as physical movement restrictions, that must also be
>>accommodated.  If a targeted user agent provides only native conformance for
>>the issues that are considered to be pertinent to that disability (or more
>>appropriately, functional level), then it may not support the adaptations
>>required for the secondary disability.
>>
>>Primarily, there are two components of access: input and output.  Most of
>>the targeted user agents are built around adaptations of output to a
>>different format: Braille or voice, for example.  Rendering video with
>>captioning deals with auditory output.  But even those with output
>>restrictions can have input restrictions, such that they cannot use the
>>standard keyboard/mouse interface, and must use an alternative input method.
>>All user agents should support external assistive technologies so that both
>>input and output can be modified as needed.
>>
>>Denis Anson
>>
>>-----Original Message-----
>>From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
>>Behalf Of schwer@us.ibm.com
>>Sent: Monday, August 30, 1999 4:47 PM
>>To: Jon Gunderson
>>Cc: w3c-wai-ua@w3.org
>>Subject: Re: Action Item: Investigate wording for possible third class
>>agent for conformance section
>>
>>
>>
>>
>>
>>Jon,
>>
>>After considerable thought on this on really believe section
>>3.1(conformance)
>>needs to define a third class of agent called a "Targetted Agent." Targetted
>>agents like Home Page Reader and PWWebSpeak are user agents that are
>>targetted
>>to a specific disabilities group or groups. They are not designed to work
>>with
>>or provide access to features that an unrelated asssitive technology should
>>need. In particular, the definition of "Native support" required:
>>
>>"for dependend user agents states that Native support does not preclude more
>>extensive support for accessibility by dependent user agents, so user agents
>>must still make information available through programming interfaces."
>>
>>This means that if a targetted agent renders a document visually it needs to
>>support a DOM and expose all the API to another assistive technology for the
>>purposes of enabling access by different user agent technologies or
>>disabilites
>>groups not intended by the targetted agent. When doing our Home Page Reader
>>Evaluation and when assessing future Home Page Reader product requirements
>>we
>>found numerous conformance checkpoints that were non-applicable for the
>>reasons
>>stated.
>>
>>To change the wording in section 3.1 I would suggest the following:
>>
>>The terms "must", "should", and "may" (and related terms) are used in this
>>document in accordance with RFC 2119 ([RFC2119]).
>>
>>To promote interoperability between graphical desktop user agents and
>>dependent
>>user agents and between graphical desktop user agents and targetted agents
>>conformance to this document is expressed in terms of these three types of
>>software.
>>
>>Conformance for graphical desktop browsers
>>
>>In order to conform as a graphical desktop browser, the user agent must
>>satisfy
>>all the checkpoints (for a chosen conformance level) that apply to graphical
>>desktop browsers and do so natively.
>>
>>Even for those checkpoints that must be satisfied natively, graphical
>>desktop
>>browsers should make information available to other software through
>>standard
>>interfaces (e.g., specialized dependent user agents may provide a better
>>solution to a problem than a graphical desktop browser).
>>
>>Conformance for dependent user agents
>>In order to conform as a dependent user agent, the user agent must satisfy
>>all
>>the checkpoints (for a chosen conformance level) that apply to dependent
>>user
>>agents and do so natively.
>>
>>Conformance for targetted agents
>>
>>In order to conform as a targetted agent, the user must satisfy all the
>>checkpoints (for a chosen conformance level) that apply to targetted agents.
>>Targetted agents are graphical desktop browsers targetted to a specific
>>disability.
>>
>>The difficulty here will be deciding what checkpoints apply to what
>>disabilties.
>>Does such a list exist?
>>
>>Rich
>>
>>Rich Schwerdtfeger
>>Lead Architect, IBM Special Needs Systems
>>EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
>>
>>"Two roads diverged in a wood, and I -
>>I took the one less traveled by, and that has made all the difference.",
>>Frost
>>
>>
>
>
>

Received on Friday, 3 September 1999 15:50:12 UTC