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

Re: Some comments on conformance levels in UA guidelines draft

From: David Poehlman <poehlman@clark.net>
Date: Wed, 01 Dec 1999 14:31:44 -0500
Message-ID: <384577A0.92BC3129@clark.net>
To: Denis Anson <danson@miseri.edu>
CC: peter.b.l.meijer@philips.com, w3c-wai-ua@w3.org, ij@w3.org
agreed.  this is what I had understood to be the case.

Denis Anson wrote:
> I think that we can fix this issue.  (I've raised it myself on several
> occasions.)  The key, I think, is that the user agent might not have to
> provide screen reading natively, but it does have to provide a standard
> interface to screen readers.  If a browser exposes the content to third
> party assistive technology in a standard and documented way, then it could
> be compliant.  If the information is not accessible, or must be "reverse
> engineered" to access, then the browser is not compliant.
> If we make our language focus on what a user agent must do in terms of
> having methods of export, then it doesn't have to have native screen
> reading, native expanded keyboard access, etc.  So long as there are
> communication channels, it will be compliant.
> Denis Anson, MS, OTR
> Assistant Professor
> College Misericordia
> 301 Lake St.
> Dallas, PA 18612
> Member since 1989:
> RESNA: An International Association of Assistive Techology Professionals
> Website: http://www.resna.org
> ORLANDO, FL, JUNE 28 -- July 2, 2000
> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
> Of peter.b.l.meijer@philips.com
> Sent: Wednesday, December 01, 1999 1:01 PM
> To: w3c-wai-ua@w3.org
> Cc: ij@w3.org
> Subject: Re: Some comments on conformance levels in UA guidelines draft
> [Again, I implicitly refer only to access for blind users in the text below,
> but we may generalize the issues later on to include other disabilities.]
> Thank you very much, Ian, your comments indeed do clarify
> some things to me, but at the same time begin to confuse me
> to the extent that I may start asking silly questions about
> what the main target audience is for these UA guidelines:
> whether it is those involved in developing accessibility
> layers (e.g. screen reader developers), or those involved
> in general applications that may need to adhere to some
> extra rules to match what screen reader technology can do,
> or both groups. To cite a few sections from the guidelines:
> > User Agent Accessibility Guidelines 1.0
> > ...
> > "User agents must satisfy natively all the applicable
> >                           ^^^^^^^^         ^^^^^^^^^^
> >          checkpoints for a chosen conformance level."
> where applicable is further defined as
> > If a user agent offers a functionality, it must ensure
> > that all users have access to that functionality or an
> > equivalent alternative.
> and native support as
> > A user agent supports a feature natively if it does not
> > require another piece of software (e.g., plug-in or
> > external program) for support.
> and you add
> > To avoid the dependencies you describe below (e.g., works
> > with one screen reader but not with another), we decided
> > that conformance would not include tools used in combination.
> Consequently, according to these guidelines and your notes,
> web browsers like Microsoft Internet Explorer and Netscape
> are w.r.t. the current conformance requirements not accessible
> user agents for blind people, because these user agents are
> of no use to them without a combination with, for instance,
> a screen reader (an external program). The same similarly
> applies to my image sonification user agent.
> If so, that indeed avoids the complicating dependencies that
> I discussed, by excluding the vast majority of applications
> that are in practice accessible to blind people, but only in
> combination with a screen reader or equivalent third-party
> assistive technology.
> Yet the abstract of the guidelines begins with
> > An accessible user agent allows users with disabilities to
> > retrieve and view Web content or to enable access when used
> > in conjunction with other software or hardware, called
> > assistive technologies.
> where assistive technologies include screen readers.
> > These guidelines discuss the accessibility of the user
> > agent as well as how the user agent communicates with
> > assistive technologies such as screen readers, screen
> > magnifiers, braille displays, and voice input software.
> So now external programs like screen readers seem allowed,
> and thus MSIE, Netscape, and my sonification browser would
> appear accessible (give or take a few minor changes that may
> still be needed to really meet all of those new checkpoints).
> I'm lost here! I could force myself to consistently interpret
> things by assuming that the conformance definition suddenly
> adds the major burden of requiring full native support for
> screen reading functionality, but it seems rather strange
> that a tool that could quite well get a triple-A conformance
> rating for blind users *if* a combination with a third-party
> screen reader were allowed in the requirements, now drops to
> a zero-A conformance rating. There will then be many fully
> accessible user agents around that get a zero-A rating? Who
> will care for this rating then if its scope is this narrow?
> I'm sorry if I misinterpreted you, but when I get confused
> here, others may share that same fate. I would have hoped
> for a wide scope for the conformance requirements, although
> that would indeed imply that some sort of reference screen
> reader functionality must be defined to get around the
> complicating dependencies that I discussed in my previous
> posting.
> What I would have strongly hoped for is that a minimum set
> of functions is defined that the "reference screen reader"
> can be assumed to perform. All screen reader developers will
> then be motivated to provide at least this minimum functionality
> (and probably more to make them stand out from the crowd),
> such that they can brand their product as triple-A compliant
> with the guidelines, while on the other side many developers
> of (general) applications will be motivated to provide full
> access under this minimum set, e.g., by using only standard
> buttons, checkboxes and so on such that they can brand their
> product too as triple-A compliant with the guidelines. The
> blind user will then know that if he or she uses a triple-A
> screen reader together with any triple-A general application,
> that full accessibility is ensured. Moreover, the fact that
> only one screen reader installation is required (the one
> preferred by the blind user) helps to ensure a consistent
> "look-and-feel" across applications. For instance, the blind
> user will probably prefer having a single speech engine to
> access most applications. In addition, this is by far the most
> economical way of working, because few application developers
> will want to take the major effort/cost of including a screen
> reader to make their tool triple-A compliant, while screen
> reader developers lack the expertise to develop the best-in-class
> mathematics package, or browser, or whatever application you
> may think of. We need a well-defined interface in the middle
> to best combine the expertise of screen reader developers with
> the expertise of application developers. Until this definition
> has been worked out, it would seem best to drop (postpone) the
> conformance rating altogether? The UA guidelines will then
> indeed "just" be guidelines for the time being, but that will
> be a good and useful start already. In my personal opinion, a
> conformance rating is not ready for prime-time yet: it is
> currently either too narrow in scope to be useful or it shows
> too many interdependency pitfalls when it allows for tools
> used in combination.
> Best wishes,
> Peter Meijer
> The vOICe Internet Sonification Browser
> http://ourworld.compuserve.com/homepages/Peter_Meijer/eyebrows.htm

Hands-On Technolog(eye)s
Touching The Internet
voice 301-949-7599
Dynamic Solutions Inc.
Best of Service for your small business network needs
Received on Wednesday, 1 December 1999 14:33:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC