[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Request for TC approval of our ODF AccessibilityGuidelines document as a "Committee Draft"
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. >