Sunday November 13, 2005

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:

• Background
• General Implications
• Accessibility Implications
• For minor vision impairments
• For major vision impairments
• For near/total blindness
• For minor physical impairments
• For major physical impairments with speech recognition
• For major physical impairments without speech recognition
• For auditory impairments
• For cognitive impairments
• Accessibility of ODF the file format itself
• Massachusetts Accessibility background/history
• Attacks on the Massachusetts ODF decision by Microsoft
• State of things today
• Options for addressing accessibility gaps
• Summary/Conclusions

Background

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 OpenOffice.org format.  Already four applications support Open Document Format, including the commercial StarOffice version 8 and IBM Workplace, and the open source OpenOffice.org 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 OpenOffice.org 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
• minor: need desktop facilities like StickyKeys/MouseKey/BounceKeys
• major, but have sufficient control over vocal system:  need/use speech recognition for dictation and control of desktop & applications
• major, unable to use speech recognition: need single switch, head-mouse, or eye-gaze systems to interact with computer & applications
• 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 - OpenOffice.org version 2.0 - for this analysis.

For minor visual impairments OpenOffice.org 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 OpenOffice.org, 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org presents no special challenges on Windows or UNIX.  All system beeps that OpenOffice.org might make are trapped by the system ShowSounds facility.  OpenOffice.org 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") OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org, and there are a significant number of bugs in ZoomText support that prevents low vision users from having a good experience with OpenOffice.org.  If AiSquared were to improve their support of OpenOffice.org, 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, OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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, OpenOffice.org 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 OpenOffice.org, that support today is poor.  The third main screen reader - WindowEyes - doesn't support the accessibility architecture of Java and OpenOffice.org 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 OpenOffice.org (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 OpenOffice.org 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).  OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org, 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 OpenOffice.org 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 OpenOffice.org. 

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 OpenOffice.org) 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 OpenOffice.org

For users with cognitive impairments OpenOffice.org 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 OpenOffice.org.

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 foxnews.com, 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.
   
 
2. 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.
   
 
3. Users with disabilities might move to a UNIX/GNOME desktop, and utilize the assistive technologies there to interact with StarOffice or OpenOffice.org (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.
   
 
4. 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...

Summary/Conclusions

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. (2005-11-13 18:25:33.0) Permalink Comments [17]