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

[Richard Schwerdtfeger <schwer@us.ibm.com>]

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

Peter.Korn@Sun.COM wrote on 10/12/2007 04:57:34 PM:

> 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 mind adding a heads up for future frameworks but perhaps it is better
to address the Trolltech work in 1.2 once it is working.

These guidelines and our accessibility review and modifications to ODF 1.1,
are first and foremost about interoperability. Accessibility reviews don't usually
got to that level of detail which is why the first W3C web content accessibility guidelines
have holes as does HTML with respect to accessibility. That is why I introduced
ARIA (formerly DHTML Accessibility) to the W3C and it is also the motivation for many
of the changes for W3C Web Content Accessibility Guidelines 2.0.

Developers need to know how to support a solution that is interoperable with
assistive technologies. If ATs don't support what you are providing the developers
get frustrated and often walk. The Qt accessibility people have done an outstanding
job moving that framework forward but it is just not supported by ATs yet.

These guidelines were to direct office developers toward a solution which will
work with ATs. I agree with Peter that I hope by ODF 1.2 Trolltech will be there
and we can include them in the list of supporting frameworks.

The point about saying that IAccessible2 was donated by IBM was merely to point out
that large companies feel accessibility is important enought to go the extra mile
and get it out there. It is also a statement that "out there" should mean "open and free
to use by all." 5 years from now nobody will remember that IBM ever donated it. Hopefully,
we will have moved on, to address new issues, and won't be milking the same old press releases. :-)

If there is a concern about mentioning IBM here we can remove it. I would like
to mention IAccessible2 as it does deal with interoperability.


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