Is the OpenDocument Format strategically better for the disabled? Maybe.

Summary:At a hearing on Monday, Oct 31, 2005, a Massachusetts state Senate oversight committee began what could best be referred to as a process of discovery to determine, amongst other things, whether the Commonwealth's Information Technology Division's (ITD) decision to standardize on the OpenDocument Format (ODF) as the standard file format in which the state must save certain public documents may have overlooked two significant drawbacks to the XML-based technology.

At a hearing on Monday, Oct 31, 2005, a Massachusetts state Senate oversight committee began what could best be referred to as a process of discovery to determine, amongst other things, whether the Commonwealth's Information Technology Division's (ITD) decision to standardize on the OpenDocument Format (ODF) as the standard file format in which the state must save certain public documents may have overlooked two significant drawbacks to the XML-based technology.  Opponents to plans to begin implementation of ODF on January 1, 2007 consider the two drawbacks to be dealbreakers that should prevent the state from moving forward with the initiative which is a part of a larger technology blueprint for the state known as the Enterprise Technical Reference Model (ETRM). 

The first of these has to do with the cost and inconvenience of converting the state's existing library of electronic documents (many of which were saved in one of Microsoft's current or legacy file formats -- all of which are supported in Microsoft Office) to the OpenDocument Format.  If I have time, I'll deal with this objection in a separate blog entry.  The second of these alleged drawbacks has to do with ODF's shortcomings when it comes to the accessibility of documents to the disabled.  Although accessibility of the state's public documents to state citizens with disabilities is an issue, the primary concern of those alleging that ODF's implementation would be a significant step backward in accessibility has to do with some of the state's disabled employees who could be forced to use software that has so far proven to be inadequate.

In an interview with Boston Globe reporter and columnist Hiawatha Bray, Curtis Chong, president of the National Federation of the Blind in Computer Science asked ''How will people with disabilities in the state, who are working for the state, how will they deal with this thing?"  According to Bray's story, "Chong said Microsoft has added a number of features to Office that allow the software to interact with Braille printers, screen magnifiers, and screen-reader programs that speak the text appearing on the computer screen."  Chong also said that if state workers can't use MS-Office to do their work, "there is no accessible office product that we can use."

Another Bray, this time Tim Bray, director of Web Technologies at Sun Microsystems (a major contributor to the ODF standard) is also cited in Hiawatha's story as agreeing that the open source-based (OO.o) and its commerical kissing cousin Sun's StarOffice (two competitors to MS-Office) are "playing catch-up when it comes to features for disabled people."  Bray is quoted as saying ''We will cheerfully admit that it's not as good as what's there under Windows today."

During the hearing, Senator Marc R. Pacheco, chairperson of the state's Senate  Post Audit and Oversight committee heard testimony from three people who represented the interests of state employees with disabilities; Massachusetts Office on Disability director Myra Berloff, Bay State Council for the Blind president Jerry Berrier, and former executive director of the Massachusetts Coalition of Citizens with Disabilities (MCCD) John Winske who spoke as a representative of the Massachusetts Disability Policy Consortium. Berrier even enthusiastically demonstrated the degree to which Microsoft's combination of Windows and Office made it easy for someone who is blind (like he is) to work with documents.  Using the current crop of ODF-compliant applications as the basis for their argument, all spoke against the ODF standard as mandated by the ETRM.

If today's state of the state when it comes to Microsoft's Office, StarOffice, OO.o and the file formats they depend on is all that the disabled will have to work with, then based on what Chong, Bray and those who testified at Monday's hearing are saying, how can anyone not question the potential disconnect between that and the ITD's stated goal of ensuring accessibility by all (including the disabled) to the state's public documents in perpetuity.  But that's a big "if."

If the oversight committee really wants to explore the disabled matter in depth, then it must first validate the overall goal behind ODF's selection in Massachusetts.  In other words, it must decide whether or not it is in the best interests of the Commonwealth, the people who work for it, and the citizens who live in it to guarantee the highest degree of accessibilty to the state's public documents in perpetuity.  If this is a worthwhile goal (and I'd agree that it is) and the disabled are included in the group of people who must be guaranteed such access (and I'd argue that they are), then, the oversight committee must zero in on four questions whose answers can help to determine which of the choices that are available to Massachusetts -- OASIS' OpenDocument Format and Microsoft's Office XML Reference Schema -- stand the better chance of ensuring that the disabled have the "highest degree of accessibility to the state's public document's in perpetuity."  Here are the four questions, an explanation of why they are important, and what can be said about the answers, so far.

With respect to ODF and Microsoft's XML Technical Reference Schema, how much of a document's accessibility to the disabled depends on the file format, and how much of its accessibility depends on the application software that accesses that file format?  What's not clear from the various assessments of Microsoft Office versus StarOffice and OO.o is whether or not the higher degree of accessibility for the disabled that Chong describes is due to Microsoft's formats themselves, or to the measures taken at the application and operating system layers to make the data stored in those formats more accessible to the disabled.  This is a incredibly important distinction that's key to any analysis of the situation. 

If the lion's share of a document's accessibility to the disabled is largely independent of its file format, then many of Microsoft Office's accessibility features that are accessibile to documents stored in Microsoft's formats become would be accessible to documents stored in ODF.  If this is the case, the dispute about ODF vs. the Office XML Reference Schema must yield the spotlight to bigger question of whether or not it's the state's decision to standardize on ODF that's allegedly intefering with document access for the disabled, or is it Microsoft's refusal to support ODF with its "accessibility tool" (Microsoft Office) that's getting in the way (Massachusetts CIO Peter Quinn asked Microsoft to support ODF in its products).  In the case of the former, the analysis much switch to a study of the potential remedies (hold that thought for the second question).  If it's the latter, then the committee shouldn't lose sight of one the key reasons that the Massachusetts ITD selected ODF in the first place:  To make sure its information technology would, in perpetuity, never be subject to the decisions of a single vendor. Currently, Microsoft and Microsoft alone is in charge of the future of Microsoft Office and the Office XML Reference Schema. 

By refusing to oblige on ODF support, Microsoft could actually be proving to the state (and others) how the software giant is the one in charge of the state's documents, rather than the state being in charge of them. Put another way, the state is supposed to be able use competition as leverage over its vendors (not just of technology, but of everything the state procures).  But instead, a software company could be using its current advantage in accessibility as leverage over the state.  The committee must carefully consider Microsoft's motivations for not supporting ODF and how reliance on single vendor's decisions affects the state's requirement of sovereignty.

Moving on to the question itself, the majority of the work needed to interact with Braille printers is probably done in the printer drivers and at the operating system level. Likewise, the bulk of the work to change how the contents of a file are shown on a display (eg: magnify them and make them scrollable) is done in the display drivers, the operating system, and the hardware.  There are enough third party screen readers out there that work with way more than just Microsoft Office (including the market leading JAWS) to suggest that such text-to-voice output is largely independent of file format.  Completely? No.

According to Sun accessibility architect Peter Korn, accessibility concerns are also dealt with at the format layer. The Hypertext Markup Language (HTML) is used for formatting Web pages (a.k.a. documents). In a telephone interview with Korn, he described how HTML's ALT tag  -- the one that, for some, causes more information about hyperlinks and images to be revealed when the mouse hovers over them -- is a critical enabler for blind people who use text-to-audio software (screenreaders) to make the Web more browsable (and thus more accessible). 

Bryon Charlson, director of the Accessibility Technology Program at the Carroll Center for the Blind in Newton, Massachsuetts also has concerns about the state's plan to implement ODF.  According to Charlson, usage of the ALT tag is critical to those with disabilties who use Web sites for things like e-commerce because it triggers the screen reader in a way that verbally explains the purpose of links and images.  In a phone interview, Charlson explained how, during a recent attempt to make an online purchase, a Web site he visited directed him to click on the image of a pumpkin to save an additional 10 percent on his purchase.  But, because the Web site's author didn't use the ALT tag with that image, he was unable to find and click it.  He had to ask someone who wasn't visually impaired to click on it for him.

So some work is indeed done at the format level.  But I suspect that an analysis designed to determine exactly how much will reveal that the delta in accessibility between users of Microsoft Office and StarOffice/OpenOffice has much less to do with the differences between the Microsoft's Office XML Reference Schema and the OpenDocument Format and much more to do with the maturity of the applications themselves.  Even Charlson readily concedes that if Microsoft decided to support ODF that his technical and functional concerns about accessibility would be assuaged.

If the state is after the best possible degree of accessibility to public document for its disabled employees and citizens, which of the two formats -- Microsoft's Office XML Reference Schema or OASIS' OpenDocument Format -- stands the best chance of getting it there?  While there is apparently no doubt over which productivity suite is currently better at accessibility for the disabled, there is also no end game to accessibility itself.  Just because Microsoft Office is better at accessibility than just two other products doesn't mean that there isn't significant headroom to make computers even more usable for the disabled and, thusly, to improve the accessiblity to documents, as well as technology itself.

Last week, at an event regarding how open standards enable interoperability that was held by the Harvard Law School's Berkman Center for Internet and SocietyJudy Brewer, director of the World Wide Web Consortium's Web Accessibility Initiative said "I know there has been a fair amount of work on accessibility of ODF by Sun and IBM--and a lot of progress in that area and also work left to do, as there is with every format that’s out there."  With a job that entails making the world's mostly widely accessed platform as accessible to the disabled as it is to those who are not disabled, there is perhaps no one who knows better than Judy Brewer about how accessibility is a never ending quest.  The truth of the matter is that when it comes to accessibility, today's technologies barely scratch the surface of what's possible.   

In an oddly ironic twist during Monday's hearing, Berrier almost disproved the very point he was trying to make when, just prior to beginning his demonstration, he couldn't tell that the image he was projecting onto the hearing room's wall was only part of the image that was being displayed on his notebook -- a problem that given today's state-of-the-state when it comes to accessibility technology can only be resolved by someone with no, or very limited visual impairment.  Not only -- as Brewer said -- is there a lot of work left to do, the bulk of the work that's been done to date (across all fronts) addresses accessibility for the blind.  For example, making documents and technology more easily accessible to people who can only use their breath or shrug a shoulder is an area that's ripe for innovation.

As good as Microsoft Office is at accessibility, the Massachusetts Senate oversight committee must also realize that regardless of the product or the problem, the current state of the art technology is never as good as it can get.   In that light, the commitee must consider what is strategically -- a.k.a. "in perpetuity" -- better for the state's disabled citizens and employees; A product and a format that are under the control of a single vendor and that, perhaps by Microsoft's own choosing (see question #1), appear to be better on the accessibility front at just a point in time?; Or, a technology that isn't up to snuff today, but that is actually poised to bypass Microsoft Office in terms of accessibility because of how free any developer is (proprietary, open source, or otherwise) to implement it, modify it, contribute to it, and even give it away. 

The key here is the degree to which the technologies that produce the effect of accessibility are open.  In Microsoft's case, accessibility comes by way the operating system (Windows), the application (Microsoft Office), and, to a much lesser extent, the format (Office XML Reference Schema).   The combination of Windows, Office, and applications like JAWS, which currently bear the lion's share of the responsibility for the superior accessibility that Microsoft's Office has been credited with, is by no means open.  Under certain circumstances, Microsoft's source code is available for viewing by other parties.  But, if advancements in accessibility are going to be made to Windows or Office, those advancements must come from Microsoft and, much the same way Microsoft is refusing to honor the state's request for ODF support in Microsoft Office, it can do the same should the state request specific accessibility enhancements as well.

The Massachusetts Senate oversight committee needn't look very far back in the state's own history for a very relevant example of how, when certain technologies are under the complete control of a single vendor, that vendor gets to decide when and if it will honor a customer's request.  In fact, that example involved Microsoft.  According to Charlson, roughly a decade ago when Microsoft was poised to release Internet Explorer (IE) 4 and Windows 95, several leaders of the disability community including Charlson who was also serving in an assistive technology advisory capacity to the Redmond, WA-based software company, begged Microsoft not to release the product because of the step backwards in accessibiity that it represented for those with disabilities who were using previous versions of IE and Windows. In what Charlson and his associates viewed as an insensitive brush-off, Microsoft went ahead with its plans anyway. Said Charlson:

Massachusetts was one of the states whose governors had signed off on Section 508 of the Rehabilitation Act (an act that gave federal money to those states to make their systems more accessible).  Once a state accepts that federal money, it is obligated to comply with the Act.  Push to came to shove with Microsoft when it released IE 4.0.  At time I was member of Microsoft's advisory board on accessibility and, having spent considerable time advising Microsoft wth respect to issues of accessbility, we made them aware of our suprise and dismay over the inasccessibility of [IE prior to its release].  When we discovered that IE4 would not comply with the act (systems must be demonstrably usable by persons with all disabilities), we called upon the other [Section 508-compliant] states and Massachusetts led a multi-state embargo on the purchase of Microsoft's products until such time as IE became accessible.

Given that IE4 is something that Massachusetts could neither modify on their own, nor ask other developers to modify on its behalf, the state was clearly beholden to Microsoft to honor its request for a feature before the product was released.   In what may be the only such embargo that forced Microsoft to capitulate, Charlson said the software giant took three or four months to restore the lost functionality to IE. There is perhaps no better example than Massachusetts' own history with Microsoft that demonstrates how (1) when a single company is in sole control of the tools that are fundamental to an organization's ongoing access to its documents, that that single company is also in control of the accessibilty of that organization's documents to those with or without disabilities, and (2) the unusual and great lengths that the state may have to go to should future feature requests be met with similar defiance.

The Senate committee should take this precedent into account as an example how, given the extent to which accessibility is primarily the responsibility of not the format, but rather the applications that use it -- which type of software ecoystem over the long term enourages the greatest range of applications and innovation that can lead to significantly better accessibility than exists today --  The ecosystem where the state is beholden to a single vendor to maintain its compliance with federal law, respond to feature requests and introduce innovations in accessibility?;  Or the one where the the state is free to not just join in the ecosystem's stewardship (and play a contributing role in guiding the technology's accessibilty), but where it's also free to turn to any vendor (or even itself) for existing software, new feature requests, and innovations that further improve on the access that those with any disability have to technology and information.

As the last answer suggests, open, unencumbered standards foster an environment where anybody  is free to develop solutions that comply with those standards and that, by virtue of that, can compete for the state's business.  Whereas other unencumbered standards, for example Web standards and RSS, have spawned tidal waves of adoption and innovative solutions from developers and vendors of all types (proprietary, open source, etc.) and sizes (entrepreneurs, software giants, etc.), it would be helpful to know if open standards (technology or otherwise) for those with disabilities have historically fostered the same sort of adoption and innovation.

It's one thing to observe how a storm of developers, solutions, and innovation gathers around a promising standard.  Consider for example how, just before such a storm built up around the World Wide Web -- which is really no more than a format (HTML) and a protocol (HTTP) strapped to the Internet with a client (a browser) on one side and a server (a Web or HTTP server) on the other -- there were a handful of proprietary on line services such as Compuserve and Prodigy.  Content and access were published and provided on the service providers' terms and adoption was good, but largely because those services were the only game in town. 

Back then, I worked for Ziff-Davis and we ran a service on Compuserve called ZiffNet. However, the limits to which we could push the interactivity of ZiffNet (with our readers) as well as the publishing environment (in terms of how engaging it was) were completely controlled by Compuserve.  And then the Web came along.  Because of how open it was, Ziff-Davis, which briefly dallied with its own proprietary service (Interchange) to compete with Compuserve  (but that could not interoperate with it), along with just about every other media company embraced the Web almost immediately.  

Millions of users flocked to it and thousands of innovations arose from the foundation technology because of how open it was (and still is). Today, the innovations are showing no signs of slowing down (particularly when it comes to mobilizing the Web) and the world's people visit billions of Web pages a day.  Granted, the Internet is available to many more people than it was 10 years ago, but the Web is clearly the killer application of the Internet that drove the demand for that sort of access. 

But I would  be remiss if I didn't also acknowledge the Web's target market: everybody.  In the world.  Potential market size is relevant when discussing the sort of storm that can gather around an open standard because, if the standard only serves a small market, the storm that gathers around the standard may not be nearly as compelling as the ones that gather around larger markets.  This gives rise to the question of how well people with disabilities have been served in the past by open standards whose theoretical promise has been improved accessibility through increased interoperability and compatibility of products as well as innovation.  In other words, do big enough storms gather around standards for the disabled, or as has been suggested, have those with disabilities been much better served by a much more proprietary ecosystem where one vendor controls the de facto standards, but also has the resources to innovate when necessary (or when forced to capitulate)?

According to Bryon Charlson, most of the leaders who represent people with disabilties -- people like him and Judy Brewer -- are sold on the value of open standards.  Charlson cited a very promising Library of Congresss-endorsed markup language standard known as DAISY for not only synthesizing audio from books, but also for making books easier to read the way people without visual impairments read them.  For example, being able to pause in order to look up the definition of a word.  Another interoperability promise of DAISY is how, if all book publishers use the same standard markup language, then their books should be able to work with any DAISY compliant device.   While Charlson noted the great comfort in knowing that there will be a day where he can buy any book and have it work with the reader of his choice, and while he seemed very optimistic about the long term promise of DAISY, he also pointed out that adoption has been slow when compared to other standards like the Web's that have much broader appeal.

The relevance in this case may have less to do with whether the ODF standard makes sense and more to do with the January 1, 2007 implementation date.  Despite the fact that vendors such as Sun and IBM have promised to gather a storm of accessibility innovation and solutions around ODF, they don't have enough to show right now, nor have they committed to a certain date on which they will deliver specfic functionality.  For example, in IBM's written testimony to the oversight committee, the company said:

IBM is committed to, and is a leader in, providing and ensuring accessible products. We have been working closely with the accessibility community for a number of years and have engaged with them on this specific issue. We have also engaged with the OASIS ODF technical committee to form a sub-committee on accessibility to review the specification in order to enhance, as needed, accessibility compatibility. IBM is committed to working with the Commonwealth of Massachusetts, the accessibility community, and other vendors, including those on the technical committee of OASIS, to create a marketplace of ODF-compliant and fully accessible products, such as our Lotus Workplace managed client, a product developed in Massachusetts.

This however is only an open commitment.  It makes no mention of the specific accessibility requirements that IBM will staisfy in its ODF-compliant solutions, nor does it commit to a delivery date.  In my opinion, this is not good enough for the disabled people who, short of the solutions they're used to working with, are worried about whether they'll be able to do their jobs on January 2, 2007.  It's a legimate worry.

Short of a Microsoft commitment to support ODF in Microsoft Office, a full vetting of the potential for ODF-compliant solutions that meets the needs of those with disabilities must start with a list of requirements (from the disabled) and then, some judgement as to whether or not those requirements are going to be addressed by forthcoming solutions, when those solutions are due to arrive, and how viable those solutions are in the range of scenarios that will be encountered by the state's disabled employees.  For example, in certain situations, a largely server-based solution like IBM's Lotus Workplace Managed Client (one that IBM has promised to be both ODF compliant and very accessible to those with disabilities) may not be appropriate if the rest of the department in which the disable person works isn't prepared to adopt that server based solution.

That said, perhaps between IBM, Sun, Google (now committing bandwidth to OO.o), and other smaller innovators who are positioned to address much smaller slices of the disability market, a storm is gathering but it may be at least another two years before it really reaches a crescendo (in other words, the January 1, 2007 date is simply unreleastic.  Should the committee see promise in an open standard and find that ODF is indeed the most open of standards (the one with the most potential for a storm to gather around), the next most obvious question is how flexible is the January 1, 2007 date.  

How flexible is the January 1, 2007 ODF implementation date that's called for by Massachusetts' Enterprise Technical Reference Model?

I asked this question of ITD general counsel Linda Hamel just before Monday's hearing began, and, as it turned out, the answer was "very."  In fact, by law, according to Hamel, the state cannot cut over to a new technology if the technology represents a step backwards for the state's disabled employees.  This little known fact -- one that is technically a giant relief valve -- has yet to be discussed in any hearing, media coverage, or public discussion that I've been party too.

In conclusion, I'd like to say that, after researching this issue,  I have a newfound respect for people with disabilities.  Not only must they face challenges every day that most of us can't possibly fathom, but, approximately 70 percent of them are unemployed and of the remaining ones who are employed, they must work harder and do more than their co-workers to prove themselves everyday.  Not just to be worthy of the jobs they hold, but also to be worthy of any upward job mobility that may be available to them.  That's not a personal condemnation of their abilities.  Thanks to discrimination, that's the unfortunate truth.  Despite this, a great many of them have the courage and the fortitude to show up on time for work everyday (weathering all sorts of ridiculous obstacles to get there), are given sub-standard tools to get their jobs done, and somehow remain just as productive if not moreso than others in the same job. 

Standardizing on ODF may indeed be the right thing to do.  But it shouldn't be done until after the solutions that are compliant with it are proven not to be a step backward for those with disabilities.

Topics: Microsoft


David Berlind was fomerly the executive editor of ZDNet. David holds a BBA in Computer Information Systems. Prior to becoming a tech journalist in 1991, David was an IT manager.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.