Massachusetts, Open Document, and Accessibility

Note: this topic, and this blog entry about it, is remarkably deep and complex.  So to help navigate it all this blog posting begins with an index:


Massachusetts CIO Peter Quinn is leading the country in a move to Open Document Format (ODF), an open, public, XML-based file format specification for office applications developed by the OASIS consortium. Many organizations participated in the development of this open standard, including Sun Microsystems, the Society of Biblical Literature, the KDE community, Boeing Corporation, the National Archives of Australia, Arbortext, and Corel Corporation.  You can read the definition of the Open Document Format itself, by downloading it in either PDF format or in format.  Already four applications support Open Document Format, including the commercial StarOffice version 8 and IBM Workplace, and the open source and KOffice applications.  Together these applications run on Microsoft Windows, Sun Solaris, GNU/Linux, Macintosh OS X, and a variety of other UNIX platforms.

This decision, which applies to the Executive Branch of the Commonwealth of Massachusetts, was part of the Enterprise Technical Reference Model Version 3.5 - and specifically can be found in the Information Domain section of the document, as put forth by the Information Technology Division on September 21st, 2005, after a 2 year evaluation process.  The policy states that all new office documents created in the Executive Branch as of January 1, 2007 shall be in either ODF or the ISO approved format PDF/A.  As CIO Quinn has stated, the decision to move to ODF was taken to "address the Tower of Babel" of file formats in the Executive Branch of Massachusetts, and to address the government mandate to preserve electronic documents for posterity.  During the comment period, many public comments were received.  These include comments in favor from Adobe, from Corel Corporation, from IBM, and from Sun Microsystems.  Not surprisingly, Microsoft's comments were not in favor of the decision.  This is not surprising because Microsoft has stated publicly that it will not support ODF in the forthcoming release of Microsoft Office version 12, but instead suggests that Massachusetts endorse Microsoft's proprietary, XML-based file format whose patent and license place severe restrictions on who else can support the file format (limiting choice and competition, as compared to both ODF and PDF/A).

General Implications

In the medium and long term, this move is clearly a boon to the Massachusetts government and its citizens.  By moving to an open standard for its files, it throws open the doors to competition which will lower the price of office software.  In fact, two of the applications that already support ODF are open source applications.  They can be used free of charge (though at that price they come without formal technical support), and can be freely modified and customized by any individual or organization.  This stands to save the Massachusetts government a pile of money (and even if they go with a supported, commercial application like StarOffice, the price is far lower).  It also greatly lowers barriers for the citizens of Massachusetts, who don't have to spend hundreds of dollars for Microsoft Office, on top of their purchase of Microsoft Windows or Macintosh OS, in order to exchange documents with their government.

In the short term there is the need for employees to be trained in using new software.  Of course, the training issue is also present with an upgrade from whatever they are using now to Microsoft Office 12 (which is supposed to have a completely new user interface).  And unless/until older documents are converted to the new ODF format, employees will need to continue to have both their current office suite and a new, ODF-capable office suite on their systems - or an office suite like StarOffice and which can read/write both Microsoft format files and the Open Document Format standard.

Accessibility Implications

While the move to ODF seems to offer clear benefits to the Massachusetts government and citizens in general, a move to ODF and a change in office application has significant accessibility implications for people with disabilities.  Today people with disabilities are predominantly on the Microsoft Windows desktop.  The proportion on Windows increases further when you look at employees of the Executive Branch of the Commonwealth of Massachusetts.

When it comes to the move to ODF for people with disabilities, there are two basic questions to ask:

  1. Are the applications for creating and reading ODF documents accessible to people with disabilities?

  2. Compared to whatever any given individual with a disability is using today (typically Microsoft Office), will they be more or less efficient and productive with a new application for reading/writing ODF documents?

It turns out these aren't simple questions to answer.  First, we need to examine a bit more closely how people with various disabilities interact with their desktop and office suite.  To do this, we need to look at the various kinds of impairments that affect computer use, and how they are addressed.  Disabilities that affect computer interaction can be broken down into the following broad categories and sub categories:

  • Visual impairments
    • minor: need small-ish changes to how things are rendered on the screen
    • major: need a desktop screen magnification software (perhaps supplemented with speech)
    • near or total blindness: need the contents of the screen read out loud, and/or rendered in refreshible Braille
  • Physical impairments
  • Auditory impairments
    • video and other multi-media content must be close captioned, sounds used in the user interface must be rendered visually or in some non-audio fashion
  • Cognitive impairments
    • need varying forms of support for generating, and reading (and comprehending) text and non-text information, and also in interacting with the computer

Another way to look at disabilities that affect technology is the extent to which computer accommodation and modification is needed: can accessibility be provided by "direct access" with some basic changes in the user interface presentation and interaction model (e.g. StickyKeys, theming support, or ShowSounds), or must the user use special additional software to mediate the user experience - an assistive technology like a screen reader?

In the context of the the Massachusetts decision to move to ODF by January, 2007, we have to answer the two basic accessibility questions for each of these disabilities, looking both at the "direct access" options, and at the assistive technologies that mediate the user experience.  As January, 2007 is nearly 14 months away as of this writing, it is fair to assume that more than the current crop of 4 applications will be available to read/write ODF.  Nonetheless, to simplify matters somewhat, we'll just choose one particular application - version 2.0 - for this analysis.

For minor visual impairments supports the various theming options of both the Microsoft Windows desktop and the various UNIX desktops like Solaris and GNU/Linux with the GNOME graphical environment.  Thus someone who needed a Large Print, High Contrast theme in order to visually discern what is on the screen could certainly do so with, just as they would with Microsoft Office.  So then both from a basic "accessibility" point of view, as well as the question of equivalent efficiency/productivity, for users with these needs the move to ODF appears to present no problems.  Certainly some tests are in order, to verify that is fully theme compliant and there are no bugs that impact its theme support (or at least no bugs that aren't also present in Microsoft Office's theme support).  While Sun Microsystems has run a number of tests specifically for theme compliance on both Windows and UNIX/GNOME desktops, additional testing is warranted.

For users with minor physical disabilities works just fine with the StickyKeys/MouseKeys/etc. suite of keyboard enhancements.  The user that can type with only one finger (or with a mouth stick), or who has hand tremors from Parkinson's, should have no accessibility difficulty with the move to ODF.  Again, additional testing is in order to verify that is fully keyboard-navigable and poses no compatibility problems with StickyKeys/MouseKeys/etc.beyond the testing that Sun has already done.

For users with auditory impairments presents no special challenges on Windows or UNIX.  All system beeps that might make are trapped by the system ShowSounds facility. itself doesn't use sound as part of its user interface.

For the other disabilities, access is via an assistive technology (AT) that mediates the user experience.  This is where our the accessibility challenges lie.  The challenges stem from the fact that Microsoft Windows doesn't provide a real accessibility infrastructure - as compared to UNIX systems with GNOME, the Java platform, or Macintosh OS X.  In Windows, virtually all of the information needed by assistive technologies has to be obtained by patching the operating system, replacing/chaining video drivers, reverse engineering applications, and/or using proprietary COM interfaces to get at the data within an application.  The first accessibility API Microsoft put forth for accessibility -  Microsoft Active Accessibility (MSAA) - fails to provide most of the information needed for screen reading and other AT uses, and is being supplanted in future Windows releases.  What this means is that for an application to be accessible in Microsoft Windows via a particular assistive technology, that AT vendor has to have made a significant investment in customizing their product to that application.  The greater the customization investment, the "more accessible" an application is deemed to be, at least via that particular AT.  For example, the Windows screen reader with the largest market share, JAWS, has made a huge investment in customization of their product to Microsoft Office (and in contrast made a much smaller investment in customization for WordPerfect).  For this reason blind folks generally feel that Microsoft Office is "accessible" (and that WordPerfect "isn't as accessible") - not because of work done by Microsoft or Corel, but work done (or not done) by Freedom Scientific, the creator of JAWS.

For users with major visual impairments (frequently termed "low vision") is today not well supported by screen magnification in Microsoft Windows.  The premier product in Windows, ZoomText, has some support for the Java Access Bridge and the Java Accessibility API, which is how version 2.0 exposes in MS-Windows the rich accessibility infrastructure that it implements.  Unfortunately AiSquared has not made enough of an investment in supporting Java and, and there are a significant number of bugs in ZoomText support that prevents low vision users from having a good experience with  If AiSquared were to improve their support of, or if another application that they did work well with like WordPerfect were to support ODF, then screen magnification users should have no accessibility barriers to equal productivity and efficiency with ODF as they have with Microsoft Office in Windows.

On the UNIX platform - and specifically on the GNOME desktop available in Sun Solaris and a wide range of GNU/Linux distributions, works pretty well today with the magnification features of the Gnopernicus screen reader/magnifier.  The magnifier accurately tracks the caret, focus in dialogs, selections in menus, etc.  This is because the rich accessibility information is directly exposed via the GNOME accessibility framework, which is what the Gnopernicus magnifier uses exclusively for tracking and magnifying the screen contents.  While there are some bugs with and Gnopernicus, the key issue for screen magnification users who are using ZoomText with Microsoft Office today is that the Gnopernicus magnifier doesn't have many of the features of ZoomText version 9 (which just came out a few weeks ago).  So while is accessible in UNIX to low vision users, those users today won't be as productive and efficient as they would be with Microsoft Office and ZoomText in Windows.

For users who are blind, today is not well supported by screen readers in Microsoft Windows.  While two of the three main screen reader products - JAWS and SuperNova - have some support for the Java Access Bridge, that support today is poor.  The third main screen reader - WindowEyes - doesn't support the accessibility architecture of Java and at all.  Some key compatibility bugs are logged, but there are more still beyond these.  And screen readers, much more so than screen magnifiers, make heavy use of application-specific scripting and customization in order to improve the user experience and provide a high degree of productivity and efficiency for blind users.  To my knowledge, no real scripting work has been done at all for (as compared to multiple programmer-years of script work in JAWS for MS-Office).  If Freedom Scientific and GW Micro and Dolphin Computer Access (makers of JAWS, Window Eyes, and SuperNova respectively) were to make similar investments in scripting and customizing their assistive technologies for as they have for Microsoft Office, or if they were to improve their existing scripting and customizations for WordPerfect and Wordperfect were to support ODF, then screen reader users should have no accessibility barriers to equal productivity and efficiency with ODF as they have with Microsoft Office in Windows.

On the UNIX platform the screen reading solution is very similar to the screen magnifier solution (and is the same application today). works pretty well today with the screen reading features of the Gnopernicus screen reader.  The screen reader accurately tracks the caret, focus in dialogs, selections in menus, etc.  It knows about text attributes and font information, and exposes that upon request in speech and Braille.  This is because the rich accessibility information is directly exposed via the GNOME accessibility framework, which is what the Gnopernicus screen reader uses exclusively for presenting the screen contents to users.  While there are some bugs with and Gnopernicus, the key issue for screen reader users who are using any of the premier screen readers for Microsoft Windows with Microsoft Office today is that the Gnopernicus screen reader doesn't have many of the features that these products have.  Furthermore, Gnopernicus is by design a "one-size-fits-all" screen reader.  The explicit intent behind the first release of Gnopernicus was to not have custom scripts for specific applications, but instead to provide a general and universal user interface to everything on the desktop.  This helped tremendously in proving the design of the accessibility architecture - if there was a presentation problem because of incorrect information coming from the accessibility architecture it had to be fixed in the architecture (rather than worked around in a custom script).  However, when it comes to offering comparable efficiency and productivity to blind users who are used to using MS-Office with one of the premier Windows screen readers, Gnopernicus today leaves something to be desired.

For users with major physical disabilities who use speech recognition today is not well supported by the two main products for Microsoft Windows - IBM ViaVoice and Dragon Naturally Speaking.  As is the case with screen reading and screen magnification, for optimal efficiency and productivity speech recognition products are customized for specific applications.  Dictation should work for entering text, but using speech for command and control of the application will be cumbersome at best. By comparison, IBM and Nuance (the maker of Dragon Naturally Speaking) have made a lot of investments into scripting Microsoft Office.  If IBM and Nuance were to make similar investments in scripting and customizing their assistive technologies for, or if WordPerfect were to support ODF (as at least Dragon Naturally Speaking already works well with WordPerfect), then speech recognition users should have no accessibility barriers to equal productivity and efficiency with ODF as they have with Microsoft Office in Windows.

On the UNIX platform today there is no real end-user speech recognition application.  The open source speech recognition engine Sphinx-4 is a very promising technology that in fact is a generational improvement in its approach to speech recognition when compared to the recognition engines underlying ViaVoice and Dragon Naturally Speaking (in fact, many of the engineers working on speech recognition at IBM and Nuance worked on earlier versions of Sphinx when they were students at Carnegie Mellon University).  Furthermore, because in UNIX we have a real accessibility architecture, the amount of application-specific customization needed for a good speech interface is dramatically less, and the baseline quality of the speech interaction with non-scripted applications should be quite reasonable.

For users with major physical disabilities who cannot use speech recognition should work pretty well with existing solutions in Windows.  The Windows-based on-screen keyboards and other assistive technologies which are driven by single-switch, head-mouse, and eye-gaze systems generally work by either inserting keystrokes or mouse movements at the device driver level.  As such, they are fairly primitive in what they can do with desktop applications, and work pretty universally.  Some products may provide features to more rapidly interact with user interface elements like toolbars and menus.  For those products, testing is needed to verify whether or not those features continue to work with 

On the UNIX platform by contrast, there is the industry-leading open source GNOME On-screen Keyboard which goes far beyond basic and primitive keystroke and mouse-movement event insertion.  It utilizes the accessibility architecture of the GNOME desktop (and its implementation by to provide a dramatically more efficient and productive user experience as compared to offerings in MS-Windows.  For this reason, a move to ODF for these users - if it was accompanied by a move to UNIX - would be a significant improvement over what they have now with Microsoft Office on Windows.  Also on UNIX is Dasher, an open source text-entry alternative for head-mouse and eye-gaze users.  Users of this application are achieving 35+ word-per-minute typing speeds using nothing but eye movement.  Further, on the UNIX/GNOME desktop, Dasher users can use their eyes to control the user interface of desktop applications like

For users with cognitive impairments today is not well supported some of the features of the main product for Microsoft Windows - Read & Write by Texthelp.  This product, and others like it, provide a collection of tools to help with the writing process, as well as with comprehension of information.  Specific tools include color coding of homophones for people with dyslexia, a pronunciation tutor, a "fact folder" for helping with organization of ideas, and a speech dictation system.  While many/most of these tools function across the desktop, some are specifically integrated with Microsoft Office and Internet Explorer.  That integration work hasn't yet been done for

On the UNIX platform today there is no such technology for people with cognitive impairments.  The good thing is that because of the accessibility infrastructure we've built, such a product could far more easily be integrated with all applications on the desktop.

Accessibility of the Open Document file format itself

Another important question is the extent to which the Open Document file format itself supports or fails to support accessibility.  This comes up for things like storing the alternate text tag for an image, or noting the relationships of labels with the objects they label in on-line forms.  While a thorough examination of the file format specifically for these issues still needs to be done, much of ODF is 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.  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). Finally, at this very moment the OASIS Technical Committee that created ODF is looking into forming a specific subcommittee to examine ODF for just these accessibility issues and address any shortcomings found.

This is in stark contrast to proprietary file formats like those used by Microsoft Office.  Those formats are totally opaque, with no peer review of accessibility issues possible. Thus we cannot objectively tell how well the Microsoft Office file format supports accessibility, or say whether it does a better or worse job than ODF.

Massachusetts Accessibility Background

It is important to note some of the history in Massachusetts around accessibility.  In the early 1990s corporate and government desktops were transitioning from DOS to Windows 3.1.  A welcome transition for many, it was causing a lot of problems among people with disabilities - and especially those with blindness and low vision - who were fairly successful and productive using assistive technologies in DOS.  Screen reading products like Flipper and JAWS (for DOS) in particular worked very well with WordPerfect, Lotus 1-2-3, and other office applications, but offered nothing for Windows users.  In fact, by the fall of 1994 Charlie Crawford (then Commissioner for the Massachusetts Commission for the Blind) and Judy Brewer (then Director of the Massachusetts Assistive Technology Partnership) were each getting calls every week from folks with disabilities who were either (a) loosing their existing jobs because of a shift to Windows 3.1, (b) having promotions rescinded or denied because they couldn't be accommodated in new positions that were on Windows 3.1, or (c) failing in their first days on a new job because of the realization that they couldn't be accommodated in Windows 3.1.

In parallel, at the national level Council member Bonnie O'Day of the National Council on Disabilities (NCD) brought the issue of the lack of blind access to Windows 3.1 to the attention of her organization.  Jamal Mazrui, who had lost a promotion at Harvard University because of accessibility problems with Windows, joined NCD in the summer of 1994 and focused his work on Windows accessibility issues.  The NCD convened a meeting in Seattle in August 1994 to attempt to address accessibility in Windows, but the Microsoft employees present didn't believe Microsoft was responsible for resolving the problem.  Both Charlie Crawford and  Marca Bristro (chair of the Board of the National Council on Disabilities) wrote letters to Microsoft in the fall of 1994 attempting to gain the attention of Bill Gates to this issue, but for months received no reply.

Against this backdrop - almost precisely 11 years ago - a growing number of Massachusetts State agencies were looking into migrate their existing desktops to the the not-yet-released Microsoft Windows 95.  In response, disability advocates in Massachusetts stepped up their efforts to get the accessibility problems addressed.  Lorraine Greiff, acting Director of the Massachusetts Office on Disability become involved.  And in addition to Lorraine, Charlie and Judy, a number of other individuals played key roles in understanding the nature of the accessibility problems - including two folks who are still very active in Massachusetts: Brian Charlson of the Carroll Center (at the time chair of the Massachusetts Assistive Technology Partnership Advisory Committee), and Joe Lazzaro of the Massachusetts Commission for the Blind.  These advocates held a series of meetings with various officials in Massachusetts State government - outlining the accessibility issues and Microsoft's lack of response to, let alone ownership of, accessibility issues.

In January 1995, in frustration with Microsoft's continued unwillingness to address accessibility, officials in the Massachusetts government communicated to Microsoft their intention to rescind their planned purchase of Windows 95.  Furthermore, agencies in several other states that were facing similar problems also started considering actions of their own.  And the major national disability organizations began efforts to get more articles in the mainstream press about individuals who were loosing their jobs because of the inaccessibility of Microsoft Windows.  Expanding on local coverage of the issue in October 1994, the story of Jamal Mazrui's job loss at Harvard, along with similar stories of other individuals with disabilities, went national.  National Public Radio broadcast a story on the issue in March of 1995, and articles appeared in both the mainstream computer press as well as blindness community publications.  Just as Microsoft was preparing the largest product release in their history, they faced a growing raft of negative publicity due to accessibility issues.  And in fact, just after they released Windows 95 the State of Missouri began a 3 month embargo of the product.

It is around this time that I entered the story.  At the start of 1995 I was working at Berkeley Access, makers of the very first graphical screen reader (outSPOKEN for Macintosh).  We had shipped one of the first Windows screen readers the previous year, and were working on an update for Windows 95.  On 72 hours notice, fellow employee Marc Sutton and I flew up to Redmond Washington to take part in a Microsoft-orchestrated press preview of "coming applications for Windows 95".  Part way though the event Bill Gates stopped by our booth, and after a 15 minute chat about how our product worked and the problems with Windows that were impacting accessibility we were mobbed by the press.  A few months later Microsoft held a 3 day Accessibility Summit, where I met Judy Brewer as well as many of the other engineers working on various assistive technologies for Windows.  The summit attendees' message to Microsoft was clear and unanimous: (1) build a real, comprehensive accessibility framework into Windows; (2) implement that framework on all Microsoft application toolkits, including MFC and the internal toolkit used by Microsoft Office; (3) build support for this framework into Microsoft developer tools and make it very easy for 3rd party developers to support accessibility, especially in their custom user interfaces.

After the meeting Microsoft added additional staff to their accessibility effort.  They also made a $250,000 donation to Recording for the Blind and Dyslexic to make Microsoft manuals available in audio and Braille formats.  And over the next two years they worked on, and eventually released, Microsoft Active Accessibility - which as I noted above failed to provide most of the information needed for screen reading and other accessibility uses.  However, at the same time that Microsoft was taking these steps, a number of assistive technology vendors shipped products for Windows 95.  Access to Windows improved slowly but steadily.  And now, 10 years later - and thanks in large measure to the hard work of these assistive technology vendors - accessibility for a wide range of disabilities is pretty good in Windows.  Many thousands of individuals with disabilities are effective and productive using a number of key software applications in Microsoft Windows, and as a result hold fulfilling jobs in both the public and private sector.

In 1996 the American Foundation for the Blind recognized 5 individuals - the "Windows access activists" - with the Access Award for their work in changing Microsoft's position on accessibility and their contributions to the subsequent improvements in accessibility of Microsoft Windows 95.  The honorees were: Marca Bristo, Charles Crawford, Judy Brewer, Jamal Mazrui, and Bonnie O'Day.

[Much of the source material for this history comes from the National Council on Disability document What GUI Teaches About Technology Access.  Thanks also to Judy Brewer, Director of the Web Accessibility Initiative at the World Wide Web Consortium, who verified a number of the events in this history.]

Attacks from Microsoft

It isn't at all surprising that Microsoft is actively trying to kill the Massachusetts move to Open Document Format - it threatens their monopoly hold in office applications.  While they didn't mention accessibility issues for people with disabilities in their public comments on September 8th, an article by James Pendergast of Americans for Technology Leadership on September 27th specifically cites accessibility issues with the move to ODF [and as we later discovered after his article was published on, Americans for Technology Leadership is a Microsoft-funded organization].  Also from conversations I've had with a number of disability groups in Massachusetts, it appears that Microsoft has been actively pushing them to come out strongly against ODF.

However, given Microsoft's history in Massachusetts around accessibility, it is especially disappointing that they would try to use accessibility concerns to try to kill Massachusetts move to ODF.  This is all the more galling because (a) most of the achievements in Windows accessibility come from the actions of 3rd party assistive technology vendors rather than from Microsoft's efforts, and (b) Microsoft could simply support ODF in MS-Office 12 and ensure that accessibility concerns were addressed that way.  If Microsoft truly cared about the needs of their customers and the needs of people with disabilities - rather than trying to use them as a corporate weapon - that is what they would do.

State of the Matter as of Today

So given all this, where are we today?  After realizing a little late that there were accessibility issues in a move to ODF, Peter Quinn and the CIO's office are sincerely working with a number of the disability organizations in Massachusetts to ensure that employees with disabilities will not lose any of the accessibility gains they've made as the Executive branch moves to ODF.  In particular, Peter Quinn and the Massachusetts CIO office:

  • has promised that no user with a disability will be moved off of Microsoft Office unless it is to an accessible alternative that is equally productive and efficient for them (see among other things the Massachusetts Open Document Format Standard FAQ which states: "Under Final ETRM Version 3.5, agencies can retain copies of MS Office as needed for disabled employees and other citizens", and then goes on to say that "the legal rights of employees and other citizens with disabilities will take precedence over any particular implementation of the Revised Final ETRM V. 3.5")

  • has invited people with disabilities to take part in an accessibility evaluation of applications that read/write ODF

  • is working to change procurement and contract language for the Massachusetts Executive to specifically require a high level of accessibility

  • is engaged with Sun Microsystems, IBM, Adobe, and others - insisting that we work as hard and quickly as we can to improve the accessibility of our applications that read/write ODF and PDF in order to serve the needs of people with disabilities in Massachusetts

Separate from Peter Quinn, a lot more of industry and the open source community are waking up to, and more fully engaging on, accessibility.  At the OASIS Open Document meeting on Friday November 4th it was agreed by all present that they would form a subcommittee to evaluate possible accessibility issues in the Open Document file format itself, and address any shortcomings found rapidly (see press coverage from ComputerWorld and from Bio-IT).  Also, the Accessibility Working Group of the Free Standards Group (which is developing open source desktop accessibility standards), is engaged in ODF questions.  Prominent members of the KDE Accessibility community are pledging open source support for ODF accessibility.  And ODF accessibility in Massachusetts has become a topic of discussion in the GNOME Accessibility mailing list.  Given all of this, I am confident that the existing accessibility work already in process for Open Document and the applications that implement it will accelerate significantly.

Options for Addressing Accessibility Gaps

There are multiple options available to addressing the accessibility requirements of people with disabilities in Massachusetts (and elsewhere) in a move to Open Document Format.

  1. Microsoft could support ODF in Office 12.
    To date Microsoft has said repeatedly they won't do this.
  3. Existing Windows assistive technology vendors could support one or more applications that read/write ODF in Windows.  This need not all be the same ODF reading/writing application.  For example, some might support StarOffice, others IBM Workplace.  And if Corel supports ODF in an update to WordPerfect, that too becomes an option.  And just recently Bob Sutor of IBM stated that IBM would release a version of IBM Workplace for Windows that fully supports accessibility.
  5. Users with disabilities might move to a UNIX/GNOME desktop, and utilize the assistive technologies there to interact with StarOffice or (or KOffice).  For some disabilities this is unlikely to be an option for a while, but for others - especially users with major physical impairments who use single-switch, head-mouse, or eye-gaze systems - this is already an excellent choice.  And for blind and low vision users, Sun is developing the Orca open source, scripting-based screen reader which shows tremendous promise in providing equivalent efficiency and productivity to commercial products in Windows.
  7. Some combination of the above - a heterogeneous solution with some users staying with MS-Office, others moving to ODF reading/writing apps in Windows, and others still moving to a UNIX desktop.  In fact, this may be the best of all worlds because it encourages competition and choice for people with disabilities.  That's something they haven't really had for a long time...


The accessibility issues affecting people with disabilities in the applications that read and write Open Document Format are real.  While some users with some disabilities should have no difficulty with ODF (and in fact in some specific cases an improved experience), for others a move to Open Document capable applications today would have significant impacts on their productivity and efficiency.  However, the first significant Open Document deployment affecting people with disabilities - in the State of Massachusetts - is still nearly 14 months away.  Given the serious attention to accessibility coming from the State agencies involved, the existing accessibility work and foundation for support already in place, and the growing awareness and engagement of the companies and organizations involved in Open Document - we stand a good chance of meeting the needs of users with disabilities without a repeat of the job impacts and losses that came a decade ago with the move from DOS to Windows.


It seems like ODF would make it easier to solve the accessibility issue because it makes it easier for people to adopt the OS + application that best supports their needs. And if a new combination arises down the road switching to it is much eased by ODF. If windows makes it so hard to support accessibility, then don't waste time supporting it. Use some other platform. From everything you said it seems the best use of available developers is to avoid windows development and focus on the other platforms with better accessibility architecture. If a job has an application that requires windows, then run vmware and run an ODF capable product on a different OS. The notion that ODF adoption should be slowed or cancelled because writing accessibility enabled applications for windows is a hard job is silly. The fact that it is such a hard job is actually a strong argument for moving to a different platform. For example IF it turned out that Mac OS X 10.4 currently had the best architecture for accessiblity technologies, than it would make sense to polish up open office on the mac so that MA had something to move to. Then later when Linux catchs/surpasses Mac OS X then MA could switch to that.

Posted by TO on November 13, 2005 at 12:35 PM PST #

I am disgusted but not surprised by the revelation of Microsoft's duplicity, since all of their arguments against the adoption of ODF (cost, switchover problems, single-source limitations) were considerably more damning of their products than they were trying to be of ODF. Biggest and most obnoxious: citing limited deployment of ODF, where current deployment of their proprietary schema is, exactly, zero. Did I say duplicity? No, I think <em>chutzpah</em> is a better word.

Along those lines, I haven't yet heard anything about how well Office 12 will support the third-party assistive technology products currently relied on by so many users. Seems to me that you might be a good person to make that particular inquiry, no...?

BTW, I'm not any more vision-impaired than the average person my age, but I do understand why fine gray on white text is a pet peeve of many...

Posted by Brian Thomas on November 15, 2005 at 05:21 AM PST #


Another option might just be to add OpenDocument support for Microsoft without Microsoft needing to be involved at all. (and to do it with a reasonable quality of translation)

You might find interesting. If there's anything special that needs to be done to make the plugin work properly for accessibility issues. We should be ready to start releasing in a few weeks, so if you know of anyone who might like to help out, let me know.

Posted by Adam Kennedy on November 15, 2005 at 11:08 PM PST #

Am I the only person who finds it ironic that this article on accessibility, which is otherwise excellent and highly informative, is formatted in a tiny font using pixel sizing, so that users of Internet Explorer are literally unable to increase the text size to make it easily legible? Nice article, but I had to copy and paste it into to read it, since I don't have any open-source browsers installed on this machine. Maybe we could switch to specifying font sizes in an accessible way for the next installment? :)

Posted by Concerned of Tunbridge Wells on November 15, 2005 at 11:22 PM PST #

Great article. Thank you for a very good description of the current situation. One minor point though - you have consistently used 'loose' where you meant 'lose'. In such a well crafted article which is likely to be referenced and quoted heavily, it would be good to get that right. Just a small edit. Regards, Nitpicker

Posted by Nitpicker on November 15, 2005 at 11:26 PM PST #

Why is a goverment so bent on formating a document. Goverments should publish everything in ASCI text format, everyone could read this. People should be able to read documents from their goverments regardless of income and equipment. I think what is in the document should be the only thing we care about. Graphics, fonts, and Formatting are a tool of the lazy, who hope that we are mesmerized by the look of the document instead of the content. In Open Office you can save a document as an ASCII text and set this as the default. Thank You Philip Merner Edlin an Vi rule

Posted by Philip Merner on November 16, 2005 at 02:26 AM PST #

I'm confused about this. If accessibility implications are used to kill Mass. ODF efforts, then what about the accessibliity issues raised with Microsoft's secret XML? That is, not okay to discriminate against handicapped people but is okay to discriminate against people who don't have Windows?

Posted by sergio on November 16, 2005 at 03:36 AM PST #

First, I'm a blind computer user, I studied Comp Sci for some years, am a supporter of Free Software and a GNU/Linux user, so I'm in favour of the ODF adoption. Now that's out of the way, I bring up some issues which I think are important: 1. Why Freedom Scientific isn't going to support OpenOffice: the accessibility layer in Windows is rather incomplete, confusing, quirky. In many ways it is underspecified, which leads to third party accessibility providers having to "scrape" around for the information they need. Much of this information is not presented in properly specified and upwards compatible ways, so these vendors pretty much depend on Microsoft goodwill to let them know, somewhat in advance, what ways they can get the information they need. This might be the reason why Freedom Scientific has, until now (although this might be changing), not supported FireFox, OpenOffice or Thunderbird. 2. Accessibility on GNU/Linux: while the accessibility APIs and architecture are well thought out, the end-user experience is not good. There are several reasons for this, one of them being the lack of high quality voice synthesis for GNU/Linux, as much as Festival is a good framework for it. IBM used to have some voices that worked, but they have not been updated and in fact are no longer on offer on IBM's website. This decision of IBM to withdraw support for their excellent GNU/Linux compatible voices and pretend that FreeTTS is an acceptably equivalent alternative is one of the weirdest decisions I've witnessed from this company. 3. Gnopernicus is not viably equivalent to JAWS or other windows-based systems, for now. Access software isn't trivial to right, because user interaction is a hard matter. For now, for a GNU/Linux blind user, the best alternative is probably using the console and the many excellent applications that exist for it, which leads to... 4. The GUI is inherently innefficient for blind users. We don't get any benefit from non-serialized information, such as buttons and icons, we don't get any benefit from all the resources the computer utilizes to make things pretty. The GUI is something that blind people use because, essentially, at least in the Windows world, noone is writing good console apps anymore. Personally I think one of the best user environments for a blind person, in some ways superior to existing Windows solutions, is emacspeak, a global user environment that makes GNU/Emacs accessible. What I'm trying to get at here is that adapting X seems to me like the wrong approach. Many Unix applications follow the paradigm of separating presentation and functionality, and this approach ledns itself a lot better to accessibility issues. A GUI-based system is not the most efficient way for us to operate, and it seems clear that the use of mediating software on the console would be a far better fit. If there were a text-based console app that could read and write ODF, and use tags, or text console attributes (colours, etc) to indicate different typographical or style markers, that would probably be the easiest and most productive way for us to use ODF. WYSIWYG makes absolutely no sense when what you see is serial audio information. Some of my ideas about accessibility are not shared by all blind users, and I speak only for myself, obviously. I might be biased towards symbolic information-oriented means to work with data rather than GUIs and the like due to my personal way of working and my background in computer programming and LaTeX, and so on. Whatever the case, though, it seems intuitively clear that a system primarily designed for a user who gets most information through concurrent observation of a high-bandwidth data channel (monitor) isn't going to be a best fit for a user who gets the totality of information from serialized low-bandwidth information (both speech and Braille are serial, the former more than the latter though). Hope this comment is useful, and makes some people think whether it is wise to keep on pouring resources in adapting an unsuitable infrastructure or whether it would be better to decouple things further and let us use the best possible interface.

Posted by David on November 16, 2005 at 05:15 AM PST #

Those that have commented on the formatting of this page:

In Mozilla 1.5 (and I think earlier ones) try the following menu:

 View -> Page Style -> No Style

Then it all turns into default black on white. You can of course change size in Firefox, and if I understand correctly (I'm not sure) "No Style" will use the font and colours you set in the preferences.

I'm not sure No Style will work for all pages, or whether it only works here because Peter has used CSS for his page - which being an accessibility expert I'd expect.

Posted by Richard Corfield on November 16, 2005 at 03:04 PM PST #

Thanks you for the excellent overview of ODF accessibility issues. I just wanted to let you know about a new initiative in the accessibility space. A new school is being created “World Academy of Universal Design”. Its intent is to provide supplemental class work for students in Architecture and other disciplines for issues of accessibility in the built world. The school is an offshoot of the work of Kristi Thomas of Accessology ( ). For example on Tuesday, November 8, 2005 in Celina, Texas the Mayor stated that he wants Celina to be the first City in the country to require ANYONE who builds in their city limits to have gone through an 8 hour training class designed just for developers/builders about building in accordance with access standards. The Resolution was presented to the City Council on Tuesday and was voted in UNANIMOUSLY! The next thing the City will do is to develop the ordinance language. The ordinance will give anyone registered to build in the city 12 months to complete their training. The Mayor of Celina is then going to work with all of the other Mayors in Collin County Texas to encourage them to accept the same rules. This is the county where our training center will be built and he believes that the entire county should embrace the fact that this international training center will be there. We are producing a documentary of this project and our video guy captured the speeches and the unanimous vote in Celina. To meet the demand that may be produced by this action in Celina, the plan is to have the classes available for these developers in fall of 2006 through the Collin County Community College system. The building, which will be called the World Academy for Universal Design, will break ground Spring, 2007. It is part of an Eastern European village that is being built in the Dallas/Ft. Worth Metroplex (see The World Academy will be a fully accredited University with transferable credits to/from other degree programs, such as architecture. Eventually, they hope to have a full two year program so people who provide access consulting will actually be able to get a two year degree in it, strengthening the quality of access provided throughout the world. The World Academy for Universal Design will be a facility unlike any other in the world. We will have an entire floor that will be dedicated to show case products and inventions to serve access through the built environment. The top floor of our five story building will have about 25 dorm rooms to house international architectural students while they spend their last semester here, learning about universal design and building codes. Each dorm room will represent a different culture in it’s design and overall look and the list of other features is seemingly endless. The building will be a “smart” building with a fully high tech environment. There will be a number of classrooms of varying sizes and a full performance hall across a gathering plaza so the arts can be fully embraced. The entire 45 acre village will be part of our training program including the residential section with over 1,000 flats and townhouses. There will be restaurants, churches, amphitheatres, a farmers market, a hotel, office buildings, a winery and various retail opportunities. Through this village we will recreate all of the challenges found in small villages around the world along with solutions for better access. Sidewalks will be fully compliant with areas that branch off with slopes too steep so we can use them as training tools. There is also work to incorporate Software into the Universal Design concepts. A virtual school that has ties to Standardization Organizations and the Open Source community could be on line long before the bricks and motor start. The thought is to provide Open Source software project based classes with transferable credits to participating schools world wide. Certainly tools that open wider the doors of ODF should be one of the first themes for projects.

Posted by Greg Alvord on November 16, 2005 at 07:04 PM PST #

I appreciate your awareness of speech recognition. Unfortunately, you've made some classic mistakes. I've lived with speech recognition for 10 years and have acquired much scar tissue in this area.. Hears the world of speech recognition as I see it:
The only viable speech-recognition today is NaturallySpeaking. ViaVoice appears to be a dead-end product.
ScanSoft (now nuance) is a terrible caretaker for handicapped accessibility products. They have not fixed bugs causing serious problems with handicap accessibility on Windows and the same bugs makes X11 on windows totally unusable. The same problems are why I rarely dictate into open office and a host of other OSS applications.
Sphinx-4 is a really impressive small vocabulary speech recognition engine. Unfortunately, while it's great for ordering pizza or asking about the weather, it doesn't work for writing the great American novel or even dictating messages like this one. Also it is not an application users can use. It's an engine which is, from what I understand, only a quarter of the work necessary for a good speech recognition application. OSSRI (Open Source Speech Recognition Initiative) is working with an engine developed at MIT Lincoln Labs that is aimed at large vocabulary continuous speech recognition. but unless someone like IBM donates lots of money and a complete speech-recognition application, a native solution is years away.
So, what's the answer? in my humble opinion, I think it is four-pronged approach.. First make sure the baseline environment has enough information so that the user can dictate and correct text and menus. Second, make sure NaturallySpeaking can work on Linux via wine. It's an interim solution but until you can get an oss speech-recognition application working, it is the only way to full dictation. personally, I would rather see usable solution soon than a perfect solution later. Third, create bridge code so that linux+wine+natspeak or linux+vmware+xp+natspeak combinations will give the user all of the command-and-control, dictation, correction capabilities they need in order to be able to operate their computing environment. Fourth, improve gtk and other multiplatform gui toolkits so that they just work right with NaturallySpeaking and various text to speech engines. As long as some of us are stuck on Windows, we would like to use OSS apps with our accessibility intact. --- eric

Posted by Eric S. Johansson on November 16, 2005 at 10:50 PM PST #

I agree with concerned that the formating of this argument is a major concern in an article about accessibility. It is all very well talking about how to view the document without styles in Mozilla, but this is not helpful to everyone. My wife has very low vision (achromatopsia - a total lack of cone cells, making it impossible for her to see detail or colour). I have tried to encourage her to use Mozilla/Firefox, but she is totally accustomed to the IE menus/keystrokes and would find it impossible to access this article - let alone the fact that the helpful Mozilla comment was also in non-resizable text.

Posted by Bernard Woodhams on November 17, 2005 at 03:49 AM PST #

Insidious as it is to quote oneself, in a comment on Groklaw on this case of Massachussetts sovereignty versus Microsoft grandstanding, I made a couple of comments on Linux, blind users (and developers) and the "surrealism of the underlying metaphor" of the Graphical User Interface for the Blind. I ended up suggesting something more like a cave than a desktop as the most appropriate metaphor - using echoes and sound as the locating metaphor rather than shadow and height/right-to-left-and-vice-versa, which is the reigning metaphor of the GUI. That, might I suggest, needs to be looked into.

Posted by Wesley Parish on November 17, 2005 at 04:14 PM PST #

Web accessibility is extremely important. So important that the federal government is requiring websites to be accessible by the disabled (including blind).

Posted by Brett S. on May 19, 2006 at 04:55 AM PDT #

Your blog is very interesting !

Posted by Aaron on July 02, 2006 at 10:55 PM PDT #

This was an excellent and informative article on accessibility which was deep and very interesting. A pitty I had to increase the font size to read it! Keep up these posts.

Posted by Mobility Man on October 09, 2006 at 07:07 PM PDT #

Good post!China magnifier

Posted by Jonathan on November 20, 2006 at 10:26 AM PST #

Post a Comment:
Comments are closed for this entry.

Peter Korn


« July 2016