RE: PROPOSAL(revised): User Agent Types

I'm not sure the revised name is the right one, but I think you are on the
right track.

If we back up and look at the web as it exists, we can say that it contains
a number of different media.  There is text content, there are graphics
(some of which look like text, but are not), there are sounds, there are
videos, animations, and, in the future, equations.  Each of these media
contains information.

The role of a user agent is to make that information available to the user
in a format that is apprehensible to the end user.  Not all user agents
render all forms of content.  In fact, some agents may be nothing more than
switch boards, sending content to the appropriate helper application, and
not rendering anything intrinsically.

The guidelines should focus, I think, on the concept that a user agent that
renders any particular type of medium should render it in a fashion that is
as inclusive as possible, and not, by design or inadvertence, exclude any
population of users.  (Note that populations are different that single,
worse-case situations.)  Since many of the designers of user agents are, at
best, clueless about the needs of people with disabilities, the role of the
guidelines is to make the developers aware of the issues involved in
rendering different types of media, and to *suggest* strategies to make that
rendering as inclusive as possible.  Whether the specific technique used is
the one suggested in the guidelines document or not is irrelevant.  The
issue is whether an individual with a disability has access to the
information being conveyed by the medium being rendered.

This has significant implications for the focus and target of the document,
I think.  We would want to say, "If your user agent renders this type of
medium, then it should do so in a way that allows the following
functionality..."  Providing that functionality might be native, or it might
be through providing an interface that could be used by third party AT to
provide the functionality.  However, if your user agent does not render this
content at all, then ignore this issue.  If your user agent hosts embedded
applications to render the technology, then you must also provide a means to
setting the point of regard on the embedded agent, and recovering the point
of regard into the host UA.

Denis Anson, MS, OTR
Assistant Professor
College Misericordia
301 Lake Street
Dallas, PA 18612

Member since 1989 of:
RESNA
The International Association of Assistive Technology Professionals

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
Of Jon Gunderson
Sent: Monday, January 04, 1999 12:55 PM
To: Al Gilman; w3c-wai-ua@w3.org
Subject: Re: PROPOSAL(revised): User Agent Types

In response to Al Gliman,

The intent of the User Agent Types was to define the functional output
meida capabilities of different types of user agent technologies and the
examples were only intended to give informational material on the current
commercial technologyies that would need to pay attention to a particular
user agent type specification.  There is not intent to have "Explorer" or
"Navigator" user agent type, but there are user agents that render their
information on a graphical screen (at least 640x48), have a 102 key
keyboard interface, pointer and etc.. that can can have built-in
accessibility features that are particular to these characteristics.
Different media types have features that are needed for that media type.

Our strategy for asssitive technology ahould be to help them understand W3C
technologies and how to use it in their products to make the WWW more
accessible. Therefore a screen reader could use DOM technology already
available to create a audio or Braille rendering of a document, rather than
have the screen reader try to read information off the screen and have the
user agent implement some tricks to make the visual rendering more
"compatible" with a screen reader.  As in my previous messages, I think
these tricks would be difficult for developers to accept and therefore take
a long time to get implemented by many developers.  In many cases the
rendering features or "tricks" may not even be needed or appropriate by the
time they would be implemented.  I think our energy is better spent getting
W3C specifications implemented and providing information to assistive
technology vendors on how to use the specifications in their products.  The
assistive technology therefore becomes the user agent to access the WWW
document in a way that will be much more robust and usable than looking at
a complex interaction of screen renderings, user agent controls and
assistive technology controls.

Mainstream developers role in this process by implementing W3C standards
(or at least important one for accessibility), including accessibility
features related to the media types they directly support (visual,
auditory)  and incorporating operating system accessibility standards into
their products.

But if a technology does not provide auditory rendering or element
information, then I don't think we should require them to implement a whole
bunch of features that only are useful for auditory rendering.  I think
this was the consensus of the Face-to-Face meeting.  If the user agent does
start supporting auditory rendering then it wil need to support the
accessibility features of that user agent media type.

In terms of employment and education I think that providing accessible WWW
technology in the most expedient time frame is our part in that process.
If we develop guidelines that industry does not find useful, then
implementation will be slow and difficult.  By defining user agent types
that developers can easily recognize for their product, I think they will
feel much more comfortable knowing what their role is and will find the
guidelines more palitable.  But if we ask every developer to solve all
accessibility problems, I think we will have an uphill battle to get the
guidelines implemented and to get the developer community to participate in
the WAI process.   This does not serve the purpose of employment and
educational access.

Maybe we should rename the user agent types to user agent media types, to
make it clearer that the types are related to rendering media capabilities?

Does anybody think that would help?

Jon

At 10:46 AM 1/1/99 -0500, Al Gilman wrote:
>At 09:05 AM 12/23/98 -0600, Jon Gunderson wrote:
>
>>Do you think these are the user agent types that we should be using?
>
>No, because I don't think we should be using user agent types.
>
>To determine browser requirements, we should create enough definitions so
>that one can classify the environments in which browser products operate,
>and the browser product developers should be deciding what environments
>they will support directly and what environments they will address by
>adaptability.
>
>Why?
>
>1.  Background:  If [user agent types | interface profiles] is the answer,
>what is the question?:
>
>One original question was "What do I tell my product designers? [that they
>must do]?"
>
>2.  Hypothesis:  One possible response to this question, and the response
>that is assumed here, is:
>
>"You must consider carefully the user interaction functions or modes that
>are required (detailed in the UA guidelines document) for various UI device
>profiles, and clearly state in pre-sale product information what profiles
>the product supports by itself and what profiles is supports by
>adaptability.  Where support by adaptability is claimed, additional system
>requirements for adaptive technology must be clearly explained in the
>pre-sale product information.  All these claims must be subjected to
>stringent quality standards maintained through user testing and product
>support."
>
>3.  Hypothesis (terminology):  Distinguish "user agents" from "browser
>products."
>
>In the accessible-by-adaptation scenario, the user agent includes those
>adaptive technology modules and browser product modules that are actually
>exercised as the user accesses web content available from a remote server.
>So a type system for user agents does not answer the question of what a
>browser product must do.
>
>
>4.  Rationale:
>
>The key reason for the position I am suggesting has to do with the job
>accomodation scenario.  It is not reasonable to say a browser product must
>support any specific user interface profile directly,  if the point of
>stating guidelines is to facilitate job accomodation for people with
>disabilities. In this situation, if indeed there is product-grade adaptive
>technology available which makes an adapted workstation with the browser
>product and the adaptive technology competitive as a job-performance
>platform, then providing a workstation equipped with adaptive technology
>and an AT-compatible browser should be considered a reasonable
>accomodiation and the employer should be encouraged to shop around.  The
>employer should understand their options in providing a browser which meets
>the employee's needs as opposed to providing adaptive technology and
>compatible browser which together meet the employee's needs.  This decision
>should be made by the employer in consultation with the employee on a
>price/performance basis.  The WAI and W3C should not make any statements
>which arbitrarily restrict the employer's choices in this situation.
>
>On the server side, the legal requirement is effective delivery of
>communication services, not that all pages must be accessible to all
people.
>
>Similarly, on the client side the legal requirement is that employers must
>within reason provide employees with a workstation which is competitive in
>job performance and compatible with the employee's interface needs.  Not
>that all products purchased to equip this workstation must be accessible to
>all potential users on a standalone basis.
>
>I expect that we will do the overall job-accomodation effort more good if
>we classify the user interface needs and not the products.  The product
>capability profiles shift too much.  If we design our guidelines around
>product types they will soon be obsolete as the boundaries of market
>segments shift.  This has been an active area of change recently and we
>cannot assume this is going to stop now.  The user interface needs of the
>users with disabilities are relatively stable.  Our statements in the UA
>Guidelines will be relevant longer if we frame our category definitions in
>this way, and not in terms of product types directly.
>
>We should be helping employers make reasonable decisions about how to equip
>their employee's workstations.  To the extent that AT and mass-market
>products team up to make feasible solutions to the job accomodation puzzle,
>we should not make any statements of "acceptable technology" regarding
>either one without considering how it interacts with the other.
>
>Al
>
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:    http://www.staff.uiuc.edu/~jongund
        http://www.als.uiuc.edu/InfoTechAccess

Received on Monday, 4 January 1999 14:16:20 UTC