W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2002

Re: UAAG 1.0: Some Linux Issues

From: Ian B. Jacobs <ij@w3.org>
Date: Wed, 28 Aug 2002 20:59:24 -0400
Message-ID: <3D6D71EC.4000106@w3.org>
To: JP Schnapper-Casteras <jp_sc@yahoo.com>
CC: w3c-wai-ua@w3.org

JP Schnapper-Casteras wrote:
> Hi Ian, etc.
>>Thanks for taking the time to read the document and send comments.
> My pleasure; thanks for writing it ;-)


>>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.
> That's good to hear he's aware.  It might not hurt to talk to him and
> send a collective e-mail to the devel lists for Konqeuror and maybe
> kde-multimedia (or devel lists for specific KDE / GNOME multimedia
> projects).  I'd be glad to help / get in on this.  I'll do some
> searching for pertinent Nautilis mailing lists or people.
> There's also the problem that no non-GNOME user agent is going to be
> fully UAAG compliant for a while -- in the KDE accessibility realm,
> we're waiting for the GNOME Accessibility Architecture to finish so
> then we can adopt it as a common arch.  In other domains (e.g., TCL/Tk,
> Motif, etc.) I would suspect it will take even longer because I doubt
> they are very accessibility-aware at all.


>>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.
> Not exactly, sorry I was a little unclear.  In my mind, there are a
> couple tricky points.
> 1) What happens if an user agent provides multiple ways of installing a
> product (say .rpms, .debs, a custom installer) and a couple
> documentation formats (e.g., html, latex, custom format).  Do they have
> to make sure that all installation methods and documentations formats
> have accessible installers and viewers respectively. 

A couple of points:

1) Clearly the folks producing the installation tools need to be
    made aware if the standard mechanisms aren't accessible. This
    would be a problem not specific to user agents.

2) You don't have to claim conformance for everything you do.
    So you could say "Conforms to UAAG 1.0 in the Redhat environment
    but not in Debian" (which would be too bad...). This information
    (which operating environment you are running in) goes in the
    conformance profile.

 > How do they
> choose which one is "standard" or "conventional"?  Do they have to drop
> or make inaccessible installers / format less prominent or harder to
> get to?  I'm just worried that might confuse / overwhelm people.

You don't have to drop anything. But you can't claim conformance
if the requirements aren't met. And, as pointed out above, you can
pick and choose which formats/environments/components/etc. about
which you wish to make a claim.

> 2) There are probably KDE, Qt, and (perhaps several) low-/kernel-level
> APIs for things like keyboard access and character encodings.  I think
> the logical answer to which API you should choose is "whichever one is
> closest to what you write your user agent in and trust that your
> toolkit will be smart about it."  In other words, for Konqeuror use
> KDE's APIs, for a straight Qt app, use Qt's, etc.  But I think these
> needs to be communicated to user agent developers so we don't have a
> situation where the KDE media player using a kernel-level API by
> accident.


>>>1.5: Does a common security arch exist?
>>I don't know. (I hope others familiar with security architectures
>>will pipe up here.).
> I'll look into this.

Thanks again,

  _ Ian

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Wednesday, 28 August 2002 21:03:20 UTC

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