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