Re: UAAG 1.0: Some Linux Issues

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.

> 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.

Ok, thanks for the clarification.

> 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.  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.

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.

> > 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.

Thanks, will do (in a bit).

> > 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.

> > 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.

Yup, gmix is what I use too.
 
> > 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. 

Yes.

> Maybe UAAG 1.0 will help promote their adoption.

I hope so :-)

> > 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.

Aha, I see what you're saying; I should look into this; in fact, the
KDE, Qt, GTK, and C keyboard APIs may all be getting the same
(standard) information in their own, language-specific ways.

> 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.

No prob.; I think I'll do that.  Yes, a telecon might not hurt.

Best,

--JP

=====
-
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

Received on Wednesday, 28 August 2002 20:26:23 UTC