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

[Peter Korn <Peter.Korn@Sun.COM>]

Hi Thomas,

Thank you for your review and your thoughts. 

I believe Section 2.3.2 is unchanged from the subcommittee draft 1 
(http://www.oasis-open.org/committees/download.php/24574/ODF_Accessibility_Guidelines_scd1_9July2007.odt) 
that we presented to the TC in July (and from which we received TC 
comments, all of which were incorporated in subcommittee draft 2 on July 
25th - 
http://www.oasis-open.org/committees/download.php/24778/ODF_Accessibility_Guidelines_scd2_25July2007.odt).

I wonder if there is some confusion about the intent and desired status 
of this document.  The ODF Accessibility Guidelines document is a 
*non-normative* document.  It is not a specification.  Specifically, 
this version 1.0 is a stand-alone document that is not even bundled with 
the OpenDocument specification, and is a collection of advice and 
guidance for ODF developers today who want to ensure their ODF 
applications are accessible to people with disabilities.

As such, I believe that section 2.3.2 is an important part of the 
document.  As we saw with a number of sites that were considering 
adopting ODF, the ability for users with disabilities to have an 
efficient and productive experience with ODF applications was a 
significant concern to them, and significant factor in their potential 
adoption of ODF as a format standard.  Section 2.3.2 is a description of 
the state of the art on interoperability with desktop & web 
accessibility frameworks - "here and now" advice on how to work with the 
assistive technologies that people with disabilities are using today.

Regarding the focus in UNIX on GNOME/GTK+ as a path to supporting 
ATK/AT-SPI (as well as UNO and the Java/Swing toolkits as a path to 
supporting ATK/AT-SPI), those are the known, proven paths that work 
today to support existing assistive technologies that users on UNIX are 
today successfully using for desktop access.  As you may know, I am 
involved and engaged with the Trolltech Qt accessibility team and 
effort, and eagerly await the day - not too far off I hope! - where the 
UNIX screen readers and the API-based on-screen keyboard are working 
well with Qt.  The instant that this is the case, I believe it would be 
appropriate to include that in the "here and now" advice we give to 
developers. 

You may note that we aren't recommending UNO as a path to Windows XP and 
Macintosh API support.  There is active work going on in those areas - 
just as there is active work in process for Qt accessibility 
interoperability with Orca and GOK - but as that work is not ready to 
deploy now, we did not feel they should be mentioned in a "what works 
today" document.  Please believe me - no favoritism for or slight 
against any technology is intended with this text.

We are beginning to working on the v1.1, and I expect this section will 
expand to cover additional approaches that will be ready for end-user 
use by the time the v1.1 document is finished. 

We could add a new section - between the existing 2.3.2 and 2.3.3 - that 
notes "Engineered Accessibility Frameworks of the future", and suggest 
that Qt is something that should be evaluated at the time of 
implementation to see if it is at that time interoperable with key AT 
like screen readers.  As Orca is moving to pyspi for GNOME 2.22 which is 
a potential target for Harald and the Qt accessibility folks as a 
possible layer that isolates the infrastructure from CORBA (allowing a 
DBUS implementation as used by Qt to work as well), we may be less than 
6 months away from this being a deployable solution.  But as this is a 
"here and now" recommendation, we should not recommend what isn't ready 
at the time of publication.


Regarding the glossary entry for GNOME, that text did change since my 
request for TC review of the subcommittee draft #1 document; though it 
is unchanged from subcommittee draft #2 of July 25th.

With the subcommittee draft #2, we updated a number of glossary entries 
to provide more information and context for the technologies in 
question.  For example, the entry about "IAccessible2" notes that it was 
developed by IBM and submitted to the Free Standards Group; the entries 
for FilterKeys, ShowSounds, SlowKeys, SoundSentry, StickyKeys, and 
ToggleKeys all note that they were developed by the Trace Center.  If we 
want to add an entry about the Qt accessibility framework (which would 
particularly make sense if we insert a new section after 2.3.2 to note 
frameworks of the future) then I would likewise note where that work 
came from - Trolltech - in parallel to these others. 

I don't think there are objections to removing those phrases from this 
non-normative document; certainly none from Sun (I'll let Rich speak for 
IBM).  I know that Trace appreciates being credited for their hard work 
that was given freely to the computing community, but I expect they 
would be OK without this reference, if it were in fact a sticking point 
for us moving forward.  I've always known them to be very pragmatic in 
such things.  So, I await the determination of the TC on those glossary 
entry references, and stand ready to make those changes as directed.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> 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 
> specification;
>   "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.
>