Re: UAAG 1.0: Some Linux Issues

JP Schnapper-Casteras wrote:
> Hi all,
>    Today I read over UUAG 1.0 looking for Linux compliance issues. 

Hi JP,

Thanks for taking the time to read the document and send comments.

> Here are some of the main ones:
> 
> - One main problem is that, with the possible exception of Mozilla, I
> don't think developers of Linux user agents are very aware of
> accessibility or wholly W3C standards compliant in general.  For
> example, of the various Linux media players or media player plugins, I
> would be (happily) suprised if there is support for captions.  Many of
> the browsers and multimedia players / agents on Linux are still in
> active development.  As a result, there is just limited functionality
> when it comes to, say, adjusting the speed of a multimedia clip.
> 
> Possible Action Item (for me and /or someone else who volunteers): talk
> to the creators of Konqueror and Nautilis (which uses Mozilla's
> rendering engine).  Also, talk to the developers of multimedia players.

Sounds great. I chat periodically with Dirk Mueller (Konqueror),
who is aware of this document. I haven't had (to my knowledge)
discussions with people about Nautilus.

> - Another big problem is the assumption that there are standard APIs
> and conventions for things like keyboard configuration, UI design, and
> access to what the user agent is doing.  One part of this problem is
> that the APIs don't exist in some cases (e.g., 6.1-6.6).  Another part
> is that sometimes there are multiple APIs -- if there are several, how
> do we judge which one is the standard? 

This is, in fact, a judgment call. UAAG 1.0 has been designed
so that there's a balance between following conventions (intended
to benefit assistive technology developers, for example) and
finding a solution that may be necessary even if non-standard.

So, checkpoints like 6.3 read:

   * If no such API is available, or if available APIs
      do not enable the user agent to satisfy the requirements,
         o implement at least one publicly documented API to satisfy
           the requirements, and
         o follow operating environment conventions
           for the use of input and output APIs.

If there is no clear conventional API for a particular application,
pick the best one that is public and use standard I/O. UAAG 1.0
doesn't mandate particular APIs (other than the DOM) as the 
landscape may change.

 > Also, each desktop environment
> tends to have its own way changing configurations (e.g., keyboard),
> installing products, vieweing documentation, etc.  Each version or
> distribution of Linux has its own mechanism for installing products or
> "packages".  This question of determining what is "standard" or
> "conventional" when there are multiple permutations of an OS is a hard
> one.  

Are you referring to the challenge of designing a conforming
user agent that works cross-platform? The UAWG is aware of that
issue, and has struck a balance between (a) following conventions
(e.g., the KDE or the Gnome way of doing things) and (b) realizing
that following conventions is not in itself a guarantee of
accessibility. Therefore, for example, checkpoint 7.3
(Respect operating environment conventions) is a Priority 2 
checkpoint, not a Priority 1 checkpoint.

 > There are similar wording complications when it comes to making
> Linux 508 compliant.  I'm talking with some people from the
> Accessibility Forum trying to figure this out, if anyone else is
> interested.

You are welcome to share your thoughts on this list.

> 1.5: Does a common security arch exist?

I don't know. (I hope others familiar with security architectures
will pipe up here.).

> 4.7: Does a truly global volume control exist (/me thinks so)

I think so, too. I control the volume with the knob that
plugs into my sound card. I think it's also controllable with
gmix.

> 6.1 - 6.6: I don't think these APIs exist (e.g., Konqueror)

6.1 and 6.2 (the DOM) certainly make sense in the Linux context.
The Techniques Document also refers to (and has links
for) the Gecko API, Java Accessibility, and Atk. I think that
the APIs in the Linux environment are less ubiquitous, but
I think there are emerging conventions. Maybe UAAG 1.0 will
help promote their adoption. :)

> 6.7: Are there more than one keyboard APIs? 

The Internationalization Working Group informed us that, for
example, for Japanese and Chinese, input may be processed in
two stages, with an API for each. So, there may be one "standard"
that's in fact N APIs.

> Possible Action Item (for me and others who are interested): Continue
> to think about if there is a reasonable way to determine what is
> standard and conventional under Linux?  For example, can we base it off
> the Linux Standard Base?  Also, can we incorporate
> accessibility-related APIs into the LSB? (URL: www.linuxbase.org)
> 
> Comments, questions, and answers are all welcomed.

I really appreciate your comments. I would welcome text
contributions to the Techniques Document (or just linkx) to
provide more guidance to Linux developers. We've made some 
improvements in recent versions of the Techniques Document,
but we can do more. We can also organize a teleconference
to brainstorm on this.

Thank you again,

  _ Ian

> Best,
> 
> --JP Schnapper-Casteras
> 
> =====
> -
> Cell Phone  -  206-849-9032
> Time Zone   -  Pacific (-08:00 UTC)
> Home Page   -  http://ocularis.sourceforge.net
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
> 


-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Tuesday, 27 August 2002 23:00:50 UTC