Tuesday Nov 10, 2009

"OpenOffice.org can speak in up to 27 languages"

Yesterday Vincent Spiewak announced the availability of the odt2daisy add-on to OpenOffice.org that will create full DAISY talking books for the blind and others with print impairments. Combined with the free and multi-platform OpenOffice.org office suite, the odt2daisy add-on enables for the first time completely free creation of digital audio talking books for the blind and print impaired - in both DAISY 3.0, and ANSI/NISO Z39.86 formats. As both OpenOffice.org and odt2daisy are multi-platform running on Windows, Macintosh, Solaris/OpenSolaris, and GNU/Linux systems, this further means that virtually any desktop computer user can utilize these tools (and when combined with OpenSolaris or GNU/Linux, the entire software stack is free).

When combined with the open source, cross-platform eSpeak text-to-speech engine, OpenOffice.org and odt2daisy can generate talking books in 27 different languages - including creating multi-lingual talking books where different portions of the document are pronounced correctly in the language they came from (see some of Vincent's screencasts to see how this is done -> simply mark the range of text as belong to a specific language in OpenOffice.org and odt2daisy will take care of the rest).

Finally, it is worth noting that this release of odt2daisy is one of the first shipping results of the AEGIS project, which recently wrapped up its first year of work.

Wednesday Apr 29, 2009

A new option for ODF users - MS Office 2007 with Service Pack 2

I just found out from the ODF Alliance Weblog that Microsoft's just-released Service Pack 2 for Microsoft Office 2007 for Windows adds support for reading and writing ODF files. This means that Windows AT users now have yet another option for gaining access to ODF documents. In addition to using (a) OpenOffice.org and any compatible assitive technology, or (b) using Microsoft Office with the Sun ODF Plugin, they can now (c) use Microsoft Office 2007 with Service Pack 2 installed. And as before, Macintosh AT users can use OpenOffice.org version 3 or later on Macintosh, and UNIX users OpenOffice.org on the GNOME desktop with the open source AT built-into the GNOME desktop.

Mandatory disclaimer: I have not yet tried this service pack; I can't speak to the quality or fidelity with which it reads/writes ODF files...

Tuesday Sep 30, 2008

odt2dtbook, Vincent, and Dominique take gold

[This seems to be the month of medals - perhaps it has something to do with the recent Olympics in Beijing...]

I just heard that Vincent Spiewak and Dominique Archambault of the Université Pierre et Marie Curie in Paris have "taken the gold" for their work on the ODF to DAISY DTBook OpenOffice.org extension, as part of the Innovation in Open Source Community Award Program. As such, Dominique, Vincent, and the odf2dtbook project share part of the $1 million in Open Source Community award monies. Congratulations Vincent & Dominique!

I encourage you to listen to an interview with Sun's Simon Phipps and several of the award winners (including Dominique and Vincent). Also worth checking out is a video showing how to use odt2dtbook to create DTBooks from within OpenOffice.org.

Regular readers may recall that I first mentioned this work last May, just a few days after Vincent posted the extension on the new OpenOffice.org extensions website. Since then the various versions have been downloaded thousands of times, enabling many many people to publish DAISY books without having to spend hundreds or thousands of dollars on proprietary authoring environments. Truly a worthy project!

Thursday May 29, 2008

OpenOffice.org plug-in for creation of DAISY books

When we formed the OASIS OpenDocument Format Accessibility Subcommittee and reviewed ODF v1.0 for accessibility concerns, one of the things we thought about was the creation of DAISY books - the suitability of ODF to be the source format for digital talking books for people with print impairments. While most of the 9 recommendations we made for accessibility improvements (all incorporated into ODF v1.1) were of use to DAISY book creation, there was one in particular that had no other purpose save for DAISY: noting the page number whenever pagination occurs (whether or not a visible page number is displayed in the document) so that DAISY book users in a setting with users of printed books could know the printed book page number.

While the OASIS OpenDocument Format Accessibility Subcommittee concerns itself only with file format issues, we all of us on the subcommittee recognize how important it is that applications make use of the accessibility features in ODF (else they would be only of academic interest). To that end we published the OASIS ODF Accessibility Guidelines. Also to that end, one of the subcommittee members (Dave Pawson, then of the Royal National Institute of the Blind) contributed code to the DAISY Pipeline project back in April 2007 to support ODF as a source for DAISY books.

Today I'm delighted to report on the early availability of an ODT to DAISY DTBook plugin to OpenOffice.org (one of the over 100 extensions now available for OpenOffice.org). This open source project - using the GPL v3 license - is a cross-platform extension to OpenOffice.org written in Java that generates DAISY DTBook XML files - the penultimate stage in the DAISY process toward creating a (talking) DAISY book. While only at "version 0.0.4", it already supports an impressive list of tags, and includes a rich set of example documents illustrating a wide range of document scenarios (including addresses, lists, tables, nested tables, and mathematics). This OpenOffice.org extension is being developed by Computer Science Masters student Vincent Spiewak and his professor Dominique Archambault of the Université Pierre et Marie Curie in Paris. It has just been featured in the May issue of The DAISY Planet, and since it was made available 6 days ago, has been download more than 150 times.

Friday May 23, 2008

ODF Accessibility Guidelines now an OASIS Committee Specification

To further underscore the importance of accessibility, the OASIS OpenDocument Format Technical Committee made a request to the OASIS OpenDocument Format accessibility subcommittee for us to submit our completed ODF Accessibility Guidelines to be approved as a formal Committee Specification. Such approval would elevate the document, making it not just a working document of our subcommittee, but a formal Technical Committee Specification.

Balloting by the Technical Committee recently completed, and I'm happy to report that you can now find the Committee Specification of the Open Document Format v1.1 Accessibility Guidelines version 1.0. Find the ODF edition and the PDF edition published as well.

Folks implementing OpenDocument Format support in their applications (as Microsoft is now doing) should use this document to help them make full and appropriate use of the accessibility features in ODF, and to properly expose them in their application's user interface. Specific guidance includes information on things like theme support and keyboard navigation of the UI and content and how ODF applications should support assistive technologies (this last should be done by utilizing the accessibility frameworks supported by assistive technologies on the platforms they are running on).

As an aside, this last piece of guidance is also part of the recently issued report to the U.S. Access Board made by the Telecommunications and Electronic and Information Technology Advisory Committeee (agreed to by IBM, Sun, Microsoft, and others on the committee), which states that: "On platforms that support AT-E&IT interoperability, software that provides user interface components must either use the accessibility services provided by platform software or other services to cooperate with assistive technologies, when such services allow the software to meet the accessibility provisions of this standard." It is wonderful to see how the IT industry has moved to embrace the approach to programmatic accessibility that Sun first implemented in the Java Platform in 1997...

Wednesday May 21, 2008

Microsoft, welcome to the OpenDocument Format neighborhood!

Last November I noted that Microsoft and Novell would be working together to make some of their technologies accessible on UNIX, and I welcomed them to the UNIX accessibility neighborhood. Today it is time to welcome them to another neighborhood - that of the OASIS and ISO standard OpenDocument Format. It is also time to issue an invitation...

In their press release today Microsoft stated that Microsoft Office 2007 Service Pack 2 - to be released in the first half of 2009 - would support reading and writing OpenDocument Format v1.1. Microsoft further states in this release that it will join the OASIS OpenDocument Format Technical Committee, as well as the ISO/IEC working group engaged in ongoing maintenance of OpenDocument Format. Some choice quotes from the press release:

When using SP2, customers will be able to open, edit and save documents using ODF... It will also allow customers to set ODF as the default file format for Office 2007. To also provide ODF support for users of earlier versions of Microsoft Office (Office XP and Office 2003), Microsoft will continue to collaborate with the open source community in the ongoing development of the Open XML-ODF translator project on SourceForge.net.

and:

Microsoft will join the Organization for the Advancement of Structured Information Standards (OASIS) technical committee working on the next version of ODF and will take part in the ISO/IEC working group being formed to work on ODF maintenance.

This means that sometime in 2009, users with disabilities will have yet another application option for reading and writing ODF files - they will be able to use Microsoft Office as shipped by Microsoft. This will supplement the options already available to people with disabilities for using ODF, including: IBM's Lotus Symphony on Windows with a variety of Windows AT applications, StarOffice and OpenOffice.org on Windows with several Windows AT applications, StarOffice and OpenOffice.org on UNIX systems with all of the UNIX AT applications, and the newly announced OpenOffice.org 3.0 beta on Macintosh with VoiceOver and other Macintosh AT applications. For folks who want to use Microsoft Office 2007 with ODF prior to their release in 2009 (as well as folks wanting to use an earlier version of Microsoft Office), there is also the Sun ODF Plugin for Microsoft Office, now at version 1.2.

And so it is time to issue an invitation. As co-chair of the OASIS OpenDocument Format Accessibility subcommittee, I would like to warmly we.come Rob Sinclair, Reed Shaffner, Gray Knowlton, and anyone else at Microsoft involved in accessibility and Microsoft Office to attend our subcommittee meetings and participate in our ongoing efforts in ODF accessibility. As a board member of the OASIS, Microsoft has always been able to participate in any OASIS technical committee or subcommittee. But in light of this recent move, I want to be sure they feel particularly welcome to do so!

Separately, you might enjoy an insightful perspective on Microsoft's decision in Simon Phipp's blog entry on the topic.

Wednesday May 07, 2008

OpenOffice.org 3.0 beta - with support for Mac, VoiceOver & Mac accessibility

The OpenOffice.org community has just announced the availability OpenOffice.org 3.0 beta. This release contains an impressive set of features, including native support for Macintosh, and support for most of the portions of the upcoming ODF v1.2 specification.

For me, one of the most noteworthy aspects of this beta release is direct support for the Macintosh accessibility framework and specifically interoperability with the VoiceOver screen reader. With OpenOffice.org 3.0, blind users on the Macintosh will finally have access to an office suite - enabling them to read and write office documents and spreadsheets and... In fact, because OpenOffice.org supports reading and writing .doc and .xls and .ppt files, this will allow blind users of the Macintosh to work with colleagues on Macintosh and Windows who might be using Microsoft Office. Of course it also means that ISO 26300:2006 format ODF documents are now accessible to the blind on Macintosh.

Earlier this year Sun demonstrated VoiceOver working with a development build of OpenOffice.org for Macintosh at the CSUN Conference on Technology and People with disabilities. We also had a chance to meet with a number of Macintosh AT vendors at the conference, and saw good results with their AT tools and the OpenOffice.org development build.

Download your copy of OpenOffice.org 3.0 beta today! Download the Macintosh version of OOo 3.0 beta here. Please be sure to report any problems found with the beta at the OpenOffice.org QA site. You may also want to check out the set of test cases to use as a reference for accessibility interoperability.

Thursday Jan 03, 2008

ODF Annual Report for 2007

The ODF Alliance has published their annual report for 2007. It contains a nice section on ODF accessibility achievements for 2007, starting on page 4 of the report. I quote it below:

Accessibility & ODF v1.1

The accessibility issues raised by the disability community with respect to office documents have raised worldwide consciousness of the impact of information technology decisions and standards on the lives of people with disabilities. ODF v1.1, approved by OASIS in February 2007, established a high water mark for document formats that should not be allowed to recede with the acceptance of anything less from any other office document format. The following is a list of critical modifications and developments that enable ODF v1.1 to provide the highest existing level of support for people with disabilities:

  • In evaluating ODF against Web Content Accessibility Guidelines (WCAG) v.1.0, several accessibility checkpoints representing significant accessibility issues were discovered by the OASIS ODF Accessibility subcommittee in its public, peer-review of ODF v1.0 and subsequently fixed in ODF v1.1.

  • The OASIS ODF Accessibility Subcommittee examined the suitability of ODF for the creation of DAISY format digital talking books for people with print impairments and the creation of Braille documents for the blind. The OASIS ODF Accessibility subcommittee explicitly addressed these questions in their review of ODF v1.0 and OASIS adopted additions to ODF v1.1 expressly to support DAISY.

  • Subsequent support of ODF v1.1 in the leading Braille transcription application and review by their transcription engineers have validated ODF v1.1 as an excellent basis for Braille production.

  • The Open Document Format v1.1 Accessibility Guidelines Version 1.0 were created by the Accessibility Subcommittee and have been approved by the OASIS OpenDocument Technical Committee. The guidelines describe what an ODF v1.1 implementation must do so that users with disabilities are equally able to read, create, and edit documents.

  • Involving disability experts and people with disabilities in standards development is a principle articulated by the European Union and other governments. Individuals with disabilities provided input and peer-reviewed ODF v1.1.

Not a bad set of accomplishments for 2007.

Monday Dec 10, 2007

Testing ODF document accessibility (and the ODF accessibility guidelines used in the tests)

Recently IBM announced the availability of the Accessibility Tools Framework, and specifically the new aDesigner tool for testing accessibility. Particularly cool in the new aDesigner is the suite of tests for ODF document accessibility. I had the pleasure of seeing demos of this work nearly two years ago, and have had to keep patient until now to download it from alphaworks and play with it. I'm not good at patience, but I can report that the wait was worth it.

Developed by a host of folks at the IBM Tokyo Research Laboratory - including two OASIS ODF Accessibility Subcommittee members Dr. Chieko Asakawa and Dr. Hironobu Takagi - the tool leverages the work we did in that subcommittee - and specifically the Open Document Format v1.1 Accessibility Guidelines Version 1.0 - to examine ODF documents and highlight access problems. Using a three-pane window approach, it shows the original document in the left pane (using OpenOffice.org as the document renderer), and a variety of end-user views in the right pane. At the bottom of the window is a pane that will list the problems found. The right or "view" pane will provide visualizations of the document for blind users as well as users with a variety of vision impairments (you can vary a wide range of vision impairment parameters to simulate). Particularly powerful in the blind user visualization is the the way that aDesigner will use color to graphically show how long it will take a prototypical screen reader user to navigate to a particular section of the document (hint: the more you use headers & subheaders and intra-document navigation links, the faster it will be for a screen reader user to find & read something). Of course this has application in the use of creating DAISY format books as well. Another powerful visualization feature in aDesigner for headings/subheadings is that in the visualization pane, only those attributes that are "structural" are shown, so something that is in 20 point bold (and so "looks" like a header") is shown as normal text unless it is marked formally as a header. In this way, a quick visual scan of the visualization pane will show you where you have failed to use headers appropriately.

And speaking of the Open Document Format v1.1 Accessibility Guidelines Version 1.0, I have been remiss in my blogging responsibilities and failed to mention that this document is available for public review, with the review period ending December 21st. To my knowledge, this document represents the first of its kind - instructions for developers of an office suite telling them what they must do to support accessibility and fully enable all of the access features of the document format.

Monday Sep 17, 2007

Bloor Analyst Peter Abrahams on ODF & OOXML Accessibility

Peter Abrahams, the Practice Leader for Accessibility and Usability at Bloor Research, just published an interesting article today, titled "Document formats and accessibility". In the article he discusses some of the history leading to the ODF and OOXML formats and standards, and some of the accessibility issues around them. In particular, he notes the work IBM has done in the development of IAccessible2, and notes that support for IAccessible2 is coming to OpenOffice.org.

What struck me most about his article is the argument he makes for the strengths of ODF and OOXML, based on their history and where they come from. He notes:

So we now have two competing standards: Office OpenXML which is not yet, and may never become, a standard driven by Microsoft, and ODF which is a standard and which now has IBM support. How will this effect accessibility? The answer, I am afraid, is that having two standards is not good. The problem is that creating assistive technologies is a specialised task and the market is relatively small. Supporting both standards is going to be expensive and likely to lead to delays in implementing and supporting new functions.

And in service of accessibility, he makes the following observations, and then gives the following advice:

ODF is already a standard and has shown that it is robust and extensive enough to support the creation and distribution of new documents. ODF has not attempted to support all the 'archived' documents that OpenXML is designed to support. OpenXML will provide a mechanism for the long term archiving of old documents but it appears not to have any benefits over ODF for the creation and storage of new documents. This is not surprising given the background of each.

For AT developers in particular, and many other tool creators in general, it would be a great benefit if there was just one format for new documents. This would enable all the effort being used in the creation of robust and function rich tools rather than having to support two competing standards.

Given the support ODF is now getting it would be sensible if the OpenXML committee decided to align the standard with ODF so that OpenXML concentrated on the archiving issue rather than defining a new standard for all documents.

Wednesday Jul 25, 2007

Final(?) draft of the Accessibility Guidelines for Implementations of Open Document Format v1.1 available

In addition to our peer-review of the OASIS Open Document Format, the OASIS ODF Accessibility Subcommittee is also charged with development of Accessibility Guidelines relating to ODF. I'm delighted to report that what I hope is the final draft of the Accessibility Guidelines for Implementations of Open Document Format v1.1 is now available. This ~50 page document describes the accessibility features of ODF v1.1 and how applications that implement support for ODF should utilize them. It also contains some information for authors, but primarily it is for ODF implementors. It also contains a fairly lengthy glossary of terms, and a description of accessibility and assistive technologies, as we don't presume that all ODF implementors will have that knowledge.

After we do a final check of this draft, we will post it prominently so that all ODF implementors will likely see it (and hopefully thoroughly read it and abide by its recommendations!).

Saturday Jul 14, 2007

Continuing the conversation with Gray Knowlton, Group Product Manager for Microsoft Office

Gray, I want to thank you again for taking the time to continue this conversation through your latest blog comment. I know that others reading these blog postings appreciate it as well - several folks have told me that they find the discussion useful and illuminating. I appreciate your candor, and I feel that with this reply you have answered all of my questions. Thank you.

Also, I very much appreciate your comments about the importance of being supportive of the energy and enthusiasm and contributions of folks new to the field. I've said so privately, but let me reiterate publicly: Reed, I apologize if anything I have said has made you feel uncomfortable, was unwelcome, felt harsh or critical. The IT accessibility effort needs the energy and enthusiasm and contributions of folks new to the field - folks like you and many others I have had the pleasure of meeting. In no way do I want to discourage your work.

Gray - you have graciously invited me to contribute to the Ecma OOXML accessibility effort, and I'm glad that you have found at least some of the questions I've raised thus far to be useful contributions. I'm sorry, but alas I must decline your invitation to particulate in a more formal way. I am quite busy with other work - with contributions to ODF accessibility, and contributing to the development of open source and free access solutions (and the growing community of users/developers around that). I am also deeply involved in the Section 508/255 Refresh activity, where I have the distinct pleasure of working on with, among others, several dedicated folks from Microsoft's accessibility team. Then of course there is my "day job" at Sun...

I'm glad to hear that you plan to take my questions and criticisms constructively, with the aim of improving OOXML accessibility. Accessibility work is never done; perfect accessibility remains an elusive goal that we all of us must continue to strive toward. It does feel a little odd, though, for a Microsoft representative to invite contributions to the Ecma OOXML work from an OASIS ODF subcommittee co-chair whose company is not an Ecma member. Microsoft, an OASIS member, declined to participate in the OASIS work on ODF. In fact, I note that this is the second time it has been suggested that I contribute accessibility expertise to a new Microsoft standards effort, when there is an already existing standards effort in that area that Microsoft refuses to join.

Separate from my lack of standing in Ecma, and in addition to being rather busy at the moment, there is another reason that I am not motivated to become further involved with Microsoft OOXML accessibility. I have several times before tried to contribute to Microsoft accessibility efforts, and each time before been disappointed. In 1995 - shortly after Microsoft reacted to a major blow-up in the disability community in Massachusetts over a different CIO's decision to standardize on the (then inaccessible) Windows 95 desktop - I attended a 3-day Microsoft accessibility summit. At that summit I spoke passionately and at length about the things I felt Microsoft needed to do to truly address accessibility concerns in their OS and applications and tools. Later, in 1995/1996, I accepted a Microsoft invitation to Redmond for a couple of days of meetings and presentations to Microsoft OS engineers to help develop an accessibility architecture for Windows. In both cases, I came away feeling that my remarks and energy fell on mostly deaf ears. The suggestions I made in the 3-day summit were little acted on. The accessibility framework I attempted to contribute to became MSAA - a tremendous disappointment to me and others who had hoped for a comprehensive accessibility framework that would eliminate the need for all of the reverse engineering & special casing work that AT products still have to do today in Microsoft Windows. So please forgive the skepticism that I bring to these discussions; they are informed by a decade-long history I have with Microsoft on accessibility.

Shifting gears, there are a few things that you said in your comments yesterday that I'd like to respond to. In replying to one of my questions (also quoted below), you said (with emphasis added):

Blog question #2 (unaddressed):When and how will the accessibility failings cited in the paper be fixed?
Putting aside the "failings" comment, changes to the spec are entiredly dependent on Ecma, just like you cannot personally re-write ODF. After a more thorough review is completed, this project will be submitted to them for consideration in the future. This is similar to (but slightly different than) ODF 1.0, which has no accessibilty support, but does have an engaged committee to improve support in future versions.

I'm sorry, but I must strongly disagree with the notion that ODF v1.0 had "no accessibility support". Please note that I have never suggested OOXML had no support for accessibility. Rather, I believe there are important questions as to how complete and sufficient that support is. But you and Microsoft have just now made that claim about ODF v1.0. I'm sorry Gray, but to me this is just a continuation of Microsoft attacks and disinformation about ODF that began in Massachusetts nearly two years ago. Especially coming from someone who says he has no accessibility background and expertise, it truly calls into question your assertion from your most recent reply, where you said: "I'll happily continue to engage with you on the topic as long as we’re both helping to contribute to accessibility, rather than the Open XML vs. ODF Debate; that’s not something I’m interested in participating in."

As I noted at the beginning of discussions around ODF accessibility in 2005, ODF v1.0 was "based on standard web technologies like SMIL for audio and multimedia, and SVG for vector graphics, which have and continue to be vetted by the World Wide Web Accessibility Initiative processes". I further noted that "we also know that two of the existing applications that currently read/write ODF can export Tagged PDF files in support of PDF accessibility, and Adobe has already conducted some tests to verify that accessibility across that translation is preserved (and thus must exist in the original ODF file)." While I didn't say so at the time, please note that, like OOXML, ODF v1.0 was derived from an earlier file format which had many years of expert accessibility attention paid to the application that creates files in that format. This is precisely why, after a thorough evaluation of the ODF v1.0 format for accessibility, the OASIS ODF Accessibility subcommittee only found 9 accessibility issues to correct.

In your comment yesterday, you also wrote: "I sense that this post is an attempt to use this report against Open XML in the future; for example, to have information you can use in an ISO committee meeting to criticize the specification." Accessibility has become a theme, a subtext in the larger debates around acceptance of ODF or OOXML by various bodies and governments and customers; in the debates about the suitability of ODF or OOXML for use in various places. As the market for office suites runs to the tens of billions of dollars a year, it comes as no surprise that some folks who are partisans to one format or the the other may seek any advantage they can to further their favored format. As I noted in November of 2005, it was Microsoft who brought accessibility into these debates, by attacking ODF on accessibility grounds.

I said in my first posting about your report, "Since the start of the discussions around office document accessibility nearly two years ago...I have seen NO clear and technical discussion of the accessibility of the Microsoft OXML format. Rather, in meetings I've been part of, Microsoft representatives have simply stated that since Microsoft Office is accessible... it is automatically the case that the underlying file format fully supports everything needed for accessibility." Your report represents the first actual review of OOXML accessibility after nearly two years of office document accessibility debate, and so therefore it is naturally the subject of a lot of interest and scrutiny.

Bottom line: when it comes to the acceptance of OOXML - in standards bodies or governments - I think there are three related things going on with respect to accessibility:

  1. The accessibility of office documents has appropriately become a significant issue - in Massachusetts and worldwide. In response, Sun, IBM, the Royal National Institute for the Blind, the Institute for Community Inclusion, Design Science, and several individual disability experts and users with disabilities did a tremendous job analyzing the ODF v1.0 spec for accessibility. The resulting contributions to ODF v1.1 led us to say that "we believe that ODF will meet or exceed the accessibility support provided in all other office file formats as well as that specified in the W3C Web Content Accessibility Guidelines 1.0". The Commonwealth of Massachusetts made it clear to Sun and IBM that they would not accept ODF v1.0, but instead insisted that the OASIS standards body make ODF v1.1 - with the results of our accessibility improvements - an OASIS standard before they would move forward with the plans set forth in ETRM v3.5 to deploy OpenDocument Format for their office documents. Given the issues that your project has highlighted in OOXML, the fact that there are unanswered accessibility questions (such as those I have highlighted with respect to DAISY and Braille conversion), and the fact that there has been no authoritative accessibility review of OOXML to date; I think it is reasonable to ask why the Commonwealth of Massachusetts should add OOXML to their set of acceptable document standards? If the Commonwealth insisted that ODF 1.0 wasn't acceptable - that only the standardized output of an accessibility peer-review of experts and technical individuals/users with disabilities would meet their needs - then shouldn't any other proposed format have to meet the same standard? Shouldn't Massachusetts insist that Ecma standardize on an OOXML v1.1 with accessibility improvements before OOXML can be deployed? Why should another document format receive less scrutiny? Why should another document format be held to a lesser standard?

  2. As was done in Massachusetts in 1994/1995 with the threatened embargo of Microsoft products due to the lack of Windows 95 accessibility, disability advocates in Massachusetts have raised the consciousness of folks throughout the world; this time around the importance of office document accessibility. They have made it clear that the needs of people with disabilities should be thought of and addressed in advance of a standard being accepted. They have made it clear that people with disabilities should be part of the standardization and review process (the adage "nothing about us without us"). They have, in essence, raised the bar on accessibility. I've seen recognition and appreciation of this in Denmark, and Belgium, and France, and England - everywhere that I have traveled and met with disability group and government document accessibility standardization folks. In each of these places, the folks adopting ODF have made it clear that they plan to use ODF v1.1 instead of ISO/IEC 26300 (ODF v1.0). They all want the version resulting from the accessibility peer-review. Yes, ISO standardization of ODF is important to them; many European organizations place an important emphasis on ISO standards. But the ISO imprimatur of ODF wasn't sufficient for the folks I met with; they required the results of our accessibility work before they would use it. For those governments and customers who care about accessibility, this higher bar is entirely appropriate and should be used.

  3. At some point the standards bodies themselves will come (are coming; perhaps have already come) to recognize the importance of accessibility concerns as a pre-requisite for standardization. As I noted previously, a principle established by the European Council eAccessibility Resolution of February 2003 is that people with disabilities should be empowered "to take more control over the development of the mechanisms for delivering eAccessibility", and "by support for their increased participation in standardisation bodies and technical committees". One can argue whether it would be fair if ISO - or more appropriately, the countries who vote on ISO standardization - were to raise the bar on accessibility for one office document standard (e.g. OOXML) after approving an earlier standard without such an accessibility bar (e.g. ODF v1.0). In fact, I've heard Microsoft representatives make that very argument. But that bar should appropriately be raised; and when it is raised it will require more of those that come after than those that came before. This is ever the case when we raise the bar on something, and insist that things be changed - whether it is recognition that slavery is wrong, or that women should have the right to vote, or that "separate but equal" isn't at all equal, or that affordable access to technology and government documents is a basic right of citizens in the Information Society. It would be a poor argument indeed that U.S. presidential candidates in 1920 shouldn't have to take into consideration womens' votes since in 1916 Woodrow Wilson didn't have to worry about them. And please remember, there are more document formats & format revisions in the ISO queue. Do we make the comparison argument indefinitely? When ODF v1.2 (or whatever) comes to ISO for standardization, a raised bar should of course apply to it. Likewise to any new PDF standards. And if Microsoft's XPS "XML Paper Specification" goes through Ecma and on to ISO, a raised bar should apply to XPS as well.

So to conclude this current exchange... thank you again for taking the time to illuminate the work your team has undertaken thus far on OOXML accessibility. Thank you for making it clear that you feel that a more complete accessibility evaluation of OOXML is needed, and that you intend your white paper to be the start of that work. I look forward to hearing more from you, your team, and an OpenXML Developer effort to thoughtfully and thoroughly analyze the accessibility of OOXML.

I make no apology for increasing accessibility requirements, nor for my advocacy of them. Next week at the 5th public meeting of the Telecommunications and Electronic and Information Technology Advisory Committee, I will continue the work of raising the bar on accessibility - working with my counterparts at places like Adobe, IBM, Microsoft, and others in industry; with expert users from the disability community including the American Council of the Blind, the American Foundation for the Blind, Communications Service for the Deaf, the National Federation of the Blind, Paralyzed Veterans of America, and other notable organizations; and with disability experts from U.S. Universities, from independent consulting firms, and from the international community. Raising the bar on accessibility and building architectures to make technology more accessibility is what I do. It is what I have been doing for the last 15 years.

People with disabilities - especially folks with severe disabilities like blindness and total hearing loss and severe physical impairments - face some truly severe barriers in technology. It is morally incumbent upon the people developing technology - like the two of us - to work diligently to remove those barriers. I'm sure you will agree that we must continually raise the bar on accessibility ; continually challenge ourselves to do an increasingly better job ensuring that everyone has the fullest possible access to and use of the products, technologies, and standards that we create. When it comes to technology for people with disabilities, we should not accept any backsliding on what is possible. Nor on what is acceptable.

Monday Jul 09, 2007

Talking with Microsoft's Gray Knowlton about MSOXML accessibility

Late last week, Gray Knowlton wrote a lengthy blog comment, sharing some of this thoughts about my review of the Microsoft white paper "Accessibility of Ecma Office Open XML File Formats" that Gray posted to the OpenXML Developer website. Given the importance of the office document accessibility, and the attention that ODF and MSOXML are getting with respect to accessibility, I wanted to continue the conversation directly in my blog (vs. buried in a comment to his comment). The rest of this is written directly to Gray...

First, Gray, thank you for talking the time to have this discussion - and thank you for correcting my misspelling of your name (oops!). You mentioned that you undertook this review "in part to educate a few individuals who claimed that “Open XML does not support accessibility”" but that "it was not intended to be a definitive guide to accessibility of Open XML". Can you tell me, has Microsoft - or anyone else - done a thorough review of MSOXML accessibility? Education, and "correction" of "significant misunderstandings" is one thing; a thoughtful and thorough accessibility review is another. Is this white paper the former, or the latter? If as you say it is the former, what about that thoughtful and thorough accessibility review?

Gray, at the start of your blog comment you say "I’m not sure that the “who did this?” question matters as much as your post seems to indicate", and you spend several paragraphs describing your (non-accessibility) background at Microsoft and Adobe. You also noted the name Reed Shaffner, as "a member of my team specifically focused on the accessibility of the Microsoft Office system", though you don't mention whether he was involved in writing this white paper (by the way, is this Reed Shaffner the author of these two blog posts? the new hire from Duke University who last year was a college senior and who presented a paper Linking Pgm allozyme and nucleotide variation in blue mussels at a Colorado Evolution conference?).

The reason I raise the question of authorship of the white paper is to better ascertain the level of accessibility expertise involved in the review. MSOXML has gone through the ECMA standards process, and is up for vote and adoption by the International Standards Organization, and is being evaluated by many countries and U.S. States for use and standardization in their organizations. Knowing whether a thoughtful and thorough accessibility evaluation was done on MSOXML has an impact on folks in many of these places.

Elsewhere in your comments, regarding my question about the use of WCAG 1.0, you note: "We are aware that the WCAG1.0 guidelines might not be the most appropriate of benchmarks today, but there are few finalised alternatives. I do work with our accessibility team on evaluating Open XML against the developing standards, and as I am sure you are aware we are active participants in these processes; however it would not be appropriate at this point to publish anything until those efforts are completed." I understand that issue, but then why do you use the XML Accessibility guidelines, which are only in draft form? It doesn't seem consistent to me...

And speaking of questions, I hope that we can continue this conversation, and that you might address the other questions I raised in my review. To quickly summarize them:

Blog question #2 (unaddressed):When and how will the accessibility failings cited in the paper be fixed?

In your evaluation, you note that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4, and that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these have quite significant impacts on folks with disabilities, including especially those who use assistive technologies to access office documents. For example, WCAG 1.0 Checkpoint 9.4 requires that you have a logical TAB order through all of the links, form controls, and objects within a document. Without this, keyboard only users won't be able to get to and manipulate all document content; screen reader users may miss some sections of content altogether. Another example: WCAG 1.0 Checkpoint 12.4 requires that all labels be explicitly associated with the objects they are labeling. Without this, blind folks using screen readers have a lot of trouble figuring out what a control is when they TAB so it - imaging hearing "edit field; edit field; edit field" as you TAB through a form, instead of "name edit field; address edit field; city edit field".

Blog question #4 (unaddressed): How does MSOXML meet accessibility needs outside of WCAG 1.0 & the W3C XML Accessibility draft? How well does MSOXML support translating into DAISY and Braille?

Perhaps your comment "The scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post" answers this, but it wasn't clear to me from your reply, and I don't want to make poor assumptions (misspelling your name is bad enough!). Does Microsoft know how well MSOXML supports the requirements of DAISY book creation? How well is supports the creation of Braille publications? How well it meets other accessibility needs? Does Microsoft have any experienced accessibility people looking at MSOXML, evaluating against accessibility needs independent of W3C accessibility specs?

Blog question #5 (unaddressed): Is there a difference between the phrases "supported" and "fully supported" in the white paper? When the white paper says that a provision is only "partially supported", what is missing?

Since you use "supported" in some places, and "fully supported" in others, it strongly implies there is a difference. Is there? Is merely "supported" less than full support? And when you note that MSOXML only "partially supports" an accessibility checkpoint, you don't say what is missing. Could you please elaborate on that missing support?

Blog question #6 (unaddressed): Why is the white paper so lacking in clear "supports" statements about the XML Accessibility guidelines?

The style change from the white paper text about WCAG 1.0 vs. XML Accessibility checkpoints almost suggests two different authors. But whatever the reason for it, it leaves a reader like me unable to form a clear picture of how MSOXML stacks up against the XML Accessibility checkpoints.

Separate from these questions - which I hope to read your answers to soon - I want to touch again on this comment of yours: "the scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post, but I posted this project to OpenXMLDeveloper.org specifically for this reason. I do hope this project can become the contribution that you and others have expressed interest in evaluating." Many people - me among them - are not in a position to review a 6,000+ page specification. Microsoft has been working on accessibility for at least the past 20 years, and is the author of that that massive specification. Shouldn't Microsoft have its experienced accessibility experts working on this, rather than hoping that others work on it for you?

On a different topic, I'm curious about your comment regarding my P.S. about an accessibility problem I noted in the PDF edition of the white paper. You said: "I am somewhat embarrassed to have not used the tools in Acrobat for making PDF documents more accessible. I did create a Tagged PDF, as you noted, but I haven’t installed Acrobat on my new hardware yet, so I did not have the ability to edit the PDF to correct this easily." Did you use Word 2007 to create the white paper, and the Export to PDF function to create the PDF? In other words, is this the result of a bug in the accessibility functionality of Word 2007's PDF export feature (as you say that you need Adobe Acrobat to "edit the PDF to correct this easily")?

Finally, fair is fair. You asked me a question:

Speaking of PDF, would you mind please pointing out the list of W3C recommendations supported by PDF/X-1a, PDF/X-3 and PDF/A? It’s been a few years, but I don’t recall the use of XForms, SVG or MathML in these specifications. These are all ISO standards today, so I’m curious to compare this with the ODF example you cited in your post.

First, let me forward you to Andrew Kirkpatrick of Adobe, who writes the Adobe Accessibility Blog, and who along with me and 40 other folks is a member of the Telecommunications and Electronic and Information Technology Advisory Committee providing recommendations for updates of accessibility standards issued under section 508 of the Rehabilitation Act and guidelines under Section 255 of the Telecommunications Act. Perhaps you met Andrew during your time at Adobe? In any case, Andrew and Adobe are the experts on PDF accessibility, not me and Sun...

That said, please let me observe that PDF/X-1a (also known as ISO 15930-1:2001) and PDF/X-3 (also known as ISO 15930-3:2002) are "graphic technology standards" for use in "prepress digital data exchange". They are subsets of the full PDF standard. They are not for editable office documents; rather they are for the final step in a print document's life prior to being sent to the printer (whether that document started out life as a spreadsheet or a glossy 4-color magazine advertisement). Mathematical equation editing happens upstream - in places like office documents or other formats dedicated to preserving all of the semantic meaning of the equation. Likewise the gathering of form data.

Anyway, where I believe it makes sense to ask these questions is with PDF/A-1 (also known as ISO 19005-1:2005). This is a "document management" standard, which is described as an "electronic document file format for long-term preservation". It is here (rather than while in transit to a printer) that the preservation of accessibility information is important, and where our accessibility attentions make sense. I haven't yet read that standard, so I can't speak to what W3C specifications it does or does not incorporate. As I find out more, I'll post the answers here.

Tuesday Jul 03, 2007

Reviewing the "Accessibility of Ecma Office Open XML File Formats"

Since the start of the discussions around office document accessibility nearly two years ago - with the publication of Commonwealth of Massachusetts' Enterprise Technical Reference Model v3.5 in September 2005 specifying the use of OpenDocument format for office documents - I have seen NO clear and technical discussion of the accessibility of the Microsoft OXML format. Rather, in meetings I've been part of, Microsoft representatives have simply stated that since Microsoft Office is accessible (only when running on Microsoft Windows, and for the blind only when running with expensive 3rd party assistive technologies), it is automatically the case that the underlying file format fully supports everything needed for accessibility. This has been the first, last, and only word on the accessibility of MSOXML even while many European countries and American States have considered standardizing on an office file format - and grappled with accessibility concerns arising from that consideration. And while several folks I know in the accessibility field have contemplated undertaking such an evaluation of the file format, the 6,000+ page specification for MSOXML proved an effective deterrent.

That finally changed yesterday morning, with the publication of the "Accessibility of Ecma Office Open XML File Formats" white paper at the OpenXML Developer website. This welcome - if late - development allows us to finally start to have a real technical discussion of MSOXML accessibility, and to start to compare MSOXML accessibility support to what is in OpenDocument Format v1.1.

The 38 page "white paper discusses the Accessibility features of Open XML and using the Web Content Accessibility Guidelines 1.0 and XML Accessibility Guidelines ." It begins with this cover text:

Microsoft is offering this document as a contribution to OpenXMLDeveloper.org, to further understanding of Open XML within the development community. Microsoft offers this to OpenXMLDeveloper.org as a project to which others may contribute, to help improve the support for assistive technology in the development of software using the Ecma Office Open XML Format Specification.

This Microsoft-proffered document goes through each of the checkpoints of the May 1999 Web Content Accessibility Guidelines v1.0, and the 3rd Draft, October 2002 XML Accessibility Guidelines, and describes whether and how MSOXML supports these checkpoints. One particularly nice thing this document does for many of the checkpoints is to illustrate in XML precisely which MSOXML tags one would use to support that checkpoint. For example, for Checkpoint 1.1 of WCAG 1.0, on pages 7 & 8 the white paper shows how to use the tag to annotate shapes, grouped objects, and line/arrows with text equivalents, and the tag to do the same thing for images, charts, and 3D objects. These XML fragment illustrations are present for most of the provisions that Microsoft claims MSOXML supports.

While a very welcome contribution to the discussion of office file format accessibility, this document raises a number of new questions, even as it answers others:

  1. Who did this review? The white paper contains no list of authors, nor even the name of one or more groups at Microsoft. The only person associated with this document is Gray Knowlton, an openxmldeveloper.org member with no bio, and only one posting to the website to date. He appears to be a Group Product Manager for Microsoft Office, focused on Technical Product Management. What about people with accessibility expertise at Microsoft? I presume at least one of them was involved, but with what background? What about folks from the disability community. Was anyone with technical background from a blindness organization invited to contribute? Anyone with physical impairment expertise? Anyone making assistive technologies? Anyone making file conversion software to take office documents into Braille or DAISY? It is difficult to trust a document that has no attribution. Given the high stakes involved, it is difficult to accept something without peer review from experts that don't stand to profit from the results of the review.

  2. When and how will the accessibility failings cited in the paper be fixed? While the white paper introduction notes that the "adoption of Accessibility in the Open XML standard will help many technology providers carry forward the information stored in billions of existing documents AND preserve the information in that document intended to enable accessibility", it is silent on the question of whether how MSOXML accessibility support itself will improve. For example, the white paper notes that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4. The white paper further notes that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these are particularly important for blind users needing to understand the context of table cells and for good Braille and DAISY transcription of tables - issues we found in ODF v1.0 and fixed in ODF v1.1. Will these things get fixed in the future? If so, when? By whom? With what outside review (if any)? To appear in what update of the specification?

  3. Why use WCAG 1.0? It is widely recognized that WCAG 1.0 is very old. The Web Content Accessibility Guidelines v2.0 is in ""last call". The white paper uses a draft of the XML accessibility specification, but then oddly doesn't do the same with WCAG 2.0, relying instead on a document that is over 8 years old.

  4. The white paper notes in many places that many of the WCAG 1.0 checkpoints are inappropriate for an office document (this is separate from the checkpoints noted above that the document says are either not supported or not fully supported). This suggests that the document author(s) don't feel that WCAG 1.0 is a fully appropriate standard to use. Yet there is no discussion about this - about why those standards were chosen and not others. Also no discussion about the accessibility purposes to which one might put an office document (e.g. meeting the needs of Braille or DAISY transcription).

  5. The white paper sometimes uses the phrase "this checkpoint is fully supported in Open XML file format", and other times the phrase "this checkpoint is supported in Open XML file format" (as distinct from the phrasing "this checkpoint is partially supported in Open XML file format". Is there a difference between "supported" and "fully supported"? For those checkpoints that are merely "supported", what is missing (if anything)? Further, in many cases for checkpoints that are "partially supported", often the white paper doesn't state what is missing. Without undertaking a thorough reading of the 6,000+ specification, it is difficult to know exactly what is missing. Without knowing who did this review and wrote this white paper, there is nobody we can ask this question of...

  6. In the review of MSOXML against the XML Accessibility guidelines, there is no definitive statement on whether and how MSOXML supports the first 8 checkpoints (1.1 through 3.2); only summaries of what those checkpoints say. For many other XML Accessibility guidelines checkpoints, there is some description of what MSOXML does, but no definitive statement about whether that means that the checkpoint is "fully supported", "supported", or "partially supported" by MSOXML (or yet some other thing). Does this mean that MSOXML fails to support those checkpoints? Does it mean that the checkpoints are inappropriate for an office document? Something else? It just isn't clear.

In addition to these important questions, this white paper nicely sidesteps what I believe is the intent of WGAG 1.0's Guideline 11: "Using W3C technologies and guidelines", and most specifically checkpoint 11.1 "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported." Unlike ODF, MSOXML makes almost no use of existing W3C standards. Instead of using the W3C XForms specification for embedded forms, it invents its own XML terminology for forms. Instead of using the SVG specification for vector graphics, it uses its own vector graphics encoding. Instead of using the MathML specification for mathematical equations, it uses its own math encoding. Instead of using the W3C date format, it invents its own (and perpetuates a leap year bug from the first releases of Microsoft Excel, rather than having the software that converts from .xls into MSOXML calculate the correct value). Yet oddly, on this topic, the white paper claims that checkpoint 11.1 is "partially supported", with the checky claim that "the Open XML file format has defined namespaces and elements and use [sic] them." This lack of re-use of existing (and accessibility-vetted) W3C XML standards is perhaps the main reason for the MSOXML specification running to 6,000+ pages, and is repeatedly cited by ISO voting members in their objections to the Fast Track ballot of MSOXML.

P.S. a final note: I was disappointed to see that the PDF edition of this white paper failed to make full use of the accessibility features of PDF and be a properly tagged document. The first 8 words of the document appear doubled to screen readers: "AAcccceessssiibbiilliittyy ooff EEccmmaa OOffffiiccee OOppeenn XXMMLL FFiillee FFoorrmmaattss"

Sun's OpenDocument Format plugin for MS Office now shipping

As my colleague Malte Timmermann has pointed out earlier today, the Sun ODF Plug-in 1.0 for Microsoft Office is now available for download, free of charge.

The plug-in is an extension to Microsoft Office that allows it to read and write ISO standard ODF files. It supports Office 2000, XP, and 2003, and works on Windows XP and Vista. It adds to MS Office the ability to read and write ODF text, spreadsheet, and presentation files (.odt, .ods, and .odp) - the ISO standard editions of MS Word, Excel, and PowerPoint files. Furthermore, ODF text files (.odt) can be made the default format for MS-Word thanks to this plug-in (and double-clicking on an ODF text file on the desktop would automatically open it in MS-Word).

Addressing the accessibility concerns of existing MS-Office users was one of the key reasons behind Sun's development of the ODF plug-in, and I have been one of several folks involved in testing the accessibility of this plug-in (along with several beta testers whose employees with disabilities were likewise doing accessibility testing). I'm delighted to report that all aspects of the plug-in - from installation through to operation from within MS-Office - works very well with commercial Windows AT products. The ODF plug-in works very well with screen reader and screen magnifiers and voice recognition/dictation systems and text-creation assistance applications. It likewise works well with the basic accessibility features built into Windows - with themes for folks with visual impairments and with the limited MS-Windows built-in AT like Narrator\* and Magnifier. This means that existing users of MS-Office can move to ODF without sacrificing any of the accessibility they have achieved, because they need never leave MS-Office.

\* Note: Narrator doesn't read MS-Office content, because Microsoft doesn't support its own screen reader with its own office applications, unlike UNIX distributions like Solaris and Ubuntu, which ship with a screen reader that is able to read (and Braille) office application documents. Unfortunately the ODF plug-in is unable to change this, so Narrator won't read ODF files anymore than it can read Word, Excel, or PowerPoint files.

About

Peter Korn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News