I explained this already: A file format cannot be “accessible” or “inaccessible.” It can merely have accessibility features. The state of Massachusetts wants to standardize on an open XML document format, but the entire discussion of accessibility thus far has been about how well a blind person can use Microsoft Office with Jaws, a separate topic altogether.
Proponents of the unpublished and closed document format known as Microsoft Word are trying to snow the organizing committee on this point. Surely these proponents must be able to differentiate between software and file format. They seem to be relying on Massachusetts state representatives’ inability to tell the two apart.
A recent Weblog entry is exhaustive, but requires correction.
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.
You’ve got till 2007 to fix it.
According to Bray’s story, “[the inevitable Curtis] 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.”
Please stop using inaccurate terminology (and perpetuating through quotation). I assume Chong referred to Braille displays.
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.”
For a blind person, maybe. Not every disabled employee is blind.
Anyway, I challenge Chong to prove that using Microsoft Office on Macintosh with a screen magnifier is any harder than doing so on Windows.
[Jerry] Berrier even enthusiastically demonstrated the degree to which Microsoft’s combination of Windows and Office made it easy for someone like him who is blind to work with documents. Using the current crop of ODF-compliant applications as the basis for their argument, all spoke against the ODF standard….
Let’s just put a stop to this argument with a quick question: If Microsoft Office could output ODF documents tomorrow, would the blind employees stop complaining?
I think they wouldn’t. Nonetheless, they have the issue backwards: They should be complaining to Microsoft for refusing to listen to customer needs. The real problem is Microsoft’s refusal to support ODF export and import in the software they use accessibly.
[H]ow 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?
Both formats can contain accessibility features, like alternative texts (annoyingly referred to as “ALT tags” in the article).
What’s not clear from the various assessments of Microsoft Office versus StarOffice and [OpenOffice] 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.
They’re only talking about accessibility of application software. It’s actually perfectly clear.
This is a incredibly important distinction that’s key to any analysis of the situation.
And it’s an easy one to make.
If the lion’s share of a document’s accessibility to the disabled is largely indepedent of its file format… is it Microsoft’s refusal to support ODF with its “accessibility tool” (Microsoft Office) that’s getting in the way[?]
Yes. Plus the near-total inability of blind people to imagine using any computer system other than Windows.
[A] software company could be using its current advantage in accessibility as leverage over the state.
Indeed, and blind people are aiding and abetting that.
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.
It’s Braille displays we’re talking about, but they too require drivers. Not many blind people read Braille, and fewer still have jobs that require the use of these expensive and rare devices. That is not an argument for disregarding their necessity, but Braille displays simply cannot bubble to the top of the list of obstacles to be overcome. They simply aren’t that important.
Even [Bryan] Charlson readily concedes that if Microsoft decided to support ODF that his technical and functional concerns about accessibility would be assuaged.
Finally somebody’s making sense.
[T]here is perhaps no one who knows better than Judy Brewer about how accessibility is a never-ending quest.
Brewer is not an expert in accessibility of application software. I expect lots of people know better than her.
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 not just the blind, either.
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.
That’s another way of saying if it doesn’t work perfectly now, don’t do it. Manufacturers have 14 months to get accessibility right.
Fun historical fact
Get this juicy gem from the dark prehistory of Web accessibility (same entry):
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 4 and Windows 95, several leaders of the disability community, including Charlson…, 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.
IE3 was accessible? Anyway:
In what Charlson and his associates viewed as an insensitive brush-off, Microsoft went ahead with its plans anyway.
[…] 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 inaccessibility of [IE prior to its release]. When we discovered that IE4 would not comply with [Section 508] (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, or 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 … the unusual and great lengths that the state may have to go to should future feature requests be met with similar defiance.