- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Fri, 03 Sep 1999 14:54:49 -0700
- To: thatch@us.ibm.com
- Cc: "Denis Anson" <danson@miseri.edu>, schwer@us.ibm.com, w3c-wai-ua@w3.org
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