OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Request for TC approval of our ODF Accessibility Guidelines document as a "Committee Draft"

On Thursday 11 October 2007 23:06:24 Peter Korn wrote:
> Dear TC members,
> As the co-chair of the OASIS OpenDocument accessibility subcommittee -
> and on behalf of that subcommittee - I would like to request your
> review of our version 1.0 candidate draft of our ODF Accessibility
> Guidelines, and your recognition and approval of it as a Committee
> Draft document. 

In your email you made a reference to gtk+, so I looked at the document 
again; and found this;

  "On UNIX systems, use the GNOME Accessibility API.  This can be done by 
following one of several specific user interface toolkits,  including 
GTK+, UNO, XUL, and Java/Swing; or it can be done by implementing support 
for ATK or the Java Accessibility API directly, or by AT-SPI directly.  
In any case, it is highly likely that either ATK or AT-SPI support will 
need to be implemented for the editing/content portion of the ODF 
application.  This is well supported by UNIX assistive technologies such 
as the Orca screen reader/magnifier, and the GNOME On-screen Keyboard."

It looks like just about all accessibility frameworks have been mentioned 
in this paragraph! Well, except one. Trolltechs Qt has accessibility 
support thoughout its toolkit and is cross platform (so are the others, 
so why the 'on UNIX' part?)
Also the sentence "use the GNOME Accessibility API" is unneeded biased, 
especially for a standard that I expect will remain unchanged for the 
next couple of years.

Now, I'm not sure if I should be suggesting we add another 'favorite' toolkit 
there, I'm more thinking that an overview of technologies does not really 
have a place in a specification like ODF.  I'm much more inclined to link 
to a some website that can iterate all the technical options there.
Which means we can keep it up-to-date as new technologies arise.

I suggest we remove the whole of the 2.3.2 chapter and link to an external 
source instead for this info.

I also suggest we remove this snippet; I have no idea what it does in a 
  "It was developed by the GNOME community under the leadership of Sun 
Microsystems, Inc."
as found in "GNOME Accessibility API" definition.

Bottom line; lets sanitize this doc so we don't look like we are advertising 
the products of some parties that some of our members might even have links 
to. Remaining impartial in a standards document seems like a basic 
requirement to me.
Thomas Zander

This is a digitally signed message part.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]