Slashdot Mirror
Open Source Accessibility
tbray writes "The strongest push-back against Massachusetts' effort to institute open, non-proprietary document formats has come from the accessibility community, who claim that Open-Source desktop software lags behind Windows; and thus that a transition to Open Document will amount to discrimination against the blind and those with other disabilities. This is serious stuff. Peter Korn, who's an Accessibility Architect at Sun, has written a massive piece that provides a general introduction to the subject, a discussion of how Open Source is doing on the the accessibility front (things could be worse, but they could be a lot better), and finally, a detailed look at the (interesting) history and (uncertain) future of these issues in Massachusetts. Anyone in Open Source who thinks they can ignore accessibility issues is probably wrong. Getting any younger? Eyes as good as they used to be? This is everybody's issue."
TFA actually has considerable praise for open source's accessibility in 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.
Real Daleks don't climb stairs - they level the building.
Some were incensed at the American's with Disabilties Act (ADA) when it was passed, wondering why they had to go through all this trouble to accomodate a tiny fraction of the population. But the disabled population is not that small and it grows larger every year due to various factors most people don't think about or recognize.
Before getting back into computing, I spent 8 years in social services, working with the autistic and developmentally disabled. You don't realize what challenges there are to everyday living until you see how hard it is for anyone with any type of disability to do the simple tasks we "normals" take for granted.
Ultimately MA is going to have to decide whether it can afford to turn its back on a small slice of its populace or continue the process of inclusion. I'm hoping for the latter, since within the disabled spectrum, there are plenty of people still capable of working and being productive members of society.
Even if I lost the use of my legs, I could still program...
GetOuttaMySpace - The Anti-Social Network
but the fact that not all people can afford to spend over $100 on proprietary software for a proprietary format that is _FORCED_ by a government
.doc files via OpenOffice (which 90% of the time does the job) or they can downloaded the doc viewer from Microsoft. =)
They don't have to.
They can either view
Besides, most of the time, documentation is used internally anyway.
Absolutely -- The cheapest and most obvious route to OpenDocument support for almost every organization is a translation filter for their existing MS Office apps.
Since 3rd party filters are already in development, this whole scrum in Mass. is really pointless. Most agencies will probably just roll out the filter.
Whenever I hear the word 'Innovation', I reach for my pistol.
Not to mention it's 10px Verdana. If you don't have Verdana installed on your system and another font is substituted, it looks about 2px smaller due to Verdana's larger than normal aspect ratio. Given that Mozilla's default is something like 15-16px and many people have to increase the size above the default, I think this isn't the best person to be preaching about accessibility.
Folks, if you have a website, even if it's just a weblog, the most effective thing you can do to increase accessibility is to read Dive Into Accessibility and apply the things you learn to your website.
Bogtha Bogtha Bogtha
Whenever an accessibility issue comes up, I have to remind everyone how it feels to operate a computer in accessibility mode. Turn on all the accessibility stuff you know about, then turn the monitor off and see how you do. We have blind people in our office that use computers with the monitor off -- until you've seen that in person, you can't understand how accessible computers /technology must be.
stuff |
Maybe you should write a letter to some of the folks involved. The article mentions at least these three:
Mass. Commission for the Blind
MATP Massachusetts Assistive Technology Partnership
The National Council on Disability
There may be others that should be included as well, but that would be a start.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
Whoah, hold on! Protecting the rights of the disabled is not, as you say, sinking to the lowest common denominator.
Might it be better to say that protecting the rights of the disabled need not be sinking to the lowest common denominator?
Most if not all accessibility standards can be implemented in ways which do not detract from the ability of those who don't require them work to the best of their abiliy. It would be difficult to argue, for example, that cutting a small ramp into a curb and sidewalk for those who can't step up onto it detracts from the ability of those who don't need the ramp to use the sidewalk or the road.
However, most of those standards can also be implemented in ways which do detract from the the experience fo. Going back to the curb example, if the ramp were to be built out from the curb rather than being cut into it, those using the road would face a small but very real obstacles at the points where the ramps were built. This would be more of an issue for wheeled vehicles than pedestrians, but it would affect a group negatively, and the point of accessibility is to not do that.
If Office were to support OpenDocument, then there would be no problem here: those who require the greater accessibility of Office could use it, while those who preferred OpenOffice.Org and didn't need Office for accessibility could use OOO. Last I checked, the law only mandates a file format, not what app is used to work with the files. As long as an app supports the standardized format, nothing else matters. It could be open-source or closed-source, made by Microsoft or Apple or some loose band of programmers, and it could support whatever other file formats the creators desired. As long as support for this particular format is somewhere on the list of features, nothing else matters, and that is as it should be.
Standards are protocols, not applications. Massachusetts understood this when they passed their OpenDocument law. It's not about screwing Microsoft over, though that may happen if MS continues to stubbornly refuse to support real standards. It's about making documents accessible and interoperable.
Adding ODF support to MS Office was listed in the article as one of the preferable solutions to this issue; indeed, that Microsoft is not doing that and instead wielding the disabled community as a weapon against OpenDocument is one of the points that's clearly made.
Second, OpenOffice's accessibility functionality is not second-tier to MS Office's. Rather, all the useful accessibility functionality is coded not into MS Office but into the 3rd-party solutions which interoperate with it. Sure, the end effect is the same -- but it's considerably harder to blame the suite.
This analogy probably isn't a good one, but it works for me. When Delta wants a change in a plane I doubt they hire their own engineers to figure out how to do it. They tell Boeing or whoever sells them their planes what they want and let the plane manufacturer do it. They care nothing about how planes are put together, they are in business to move people from point a to point b as efficiently as possible.
These people have no interest in developing software. It may sound like they do, but they have no training or know how in software development. They do not want to take the responsibility of hiring people, making sure they are qualified and overseeing a project like this. They want someone to sell it to them so they can concentrate on what their specialty is.
What they need in this case is someone like RedHat or Novell or "New Joe Blow Super Accessible Linux " or whoever to present them with a solution.
I'm work for IBM as one of those 'accessibility experts' and am the module owner for accessibility in Firefox. IBM picked up the Firefox and Gecko accessibility work after AOL lost interest in anything Mozilla-related.
JAWS 7 in fact works with Firefox 1.5. Ask your friend to try that combination -- Firefox 1.5 RC 2 is avalable on mozilla.org. Your friend can also try Window-Eyes 5.5 with Firefox 1.5 -- it works great.
It took me since 2001 to get all of the APIs implemented that were required for Mozilla accessibility on Windows. We also had tons of keyboard, focus and UI issues to fix. Then there is the new stuff -- accessibility for JavaScript/DHTML/AJAX applications. Firefox 1.5 is the first browser to provide the ability for authors to make custom DHTML widgets accessible. See http://www.mozilla.org/access. So we're going beyond the status quo.
For any application with any kind of document viewer or editor application with its own engine, accessibility requires a lot of work in the code. After that it requires a great deal of cooperation from screen reader companies so that two complex systems interact correctly.
Aaron Leventhal
http://www.mozilla.org/access
I think it's down to the fact that most 3rd party accessibility tools are written for Windows/MS Office. This is a result of Microsoft having the greatest market share, rather than any specific features that MS Office has over OpenOffice.
Still, if the lack of accessibility tools is a barrier to increased market share, then it's down to the Open Source community to provide them. And this doesn't have to mean unpaid coders - these tools could come from Sun, Novell, IBM etc.
Agree.
Same thing happens with software documentation:
Analysis, Requirements specifications document.
Design: Design Specification document [with or without UML, DTDs, etc].
Quality control/assurance: (Quality testing metrics documents).
Nobody (at least not programmers) likes to spend their time doing that, which results in a lot of good Open Source projects (just look at sf.net) that have only the source code available. So, when/if someone wants to start helping (be it a programmer or a non programmer) they must dive into the source code, reverse engineer it and (to their better understanding) see how is the program working.
When developing a propietary software for anyone, documentation is the one most important thing, and often the one that programmers hate to do. That is why System designers are better paid than programmers.
In open-source world, nobody cares about documenting [and mantaining the domcumentation] of their software. My personal experience is with VirtualDimension multi-desktop software. I wanted to enhance the program with some ideas I had, but I hated that the only place to understand how it worket was the CVS repository C++ files. Although I know C++ (and I am good at it if-u-ask-me) it is the "logic" of the program what I wanted to find and, well, my time is worth more than what I needed to understand the inners of the program.
The same happened with jabref. I would like to contribute to those projects with programming, but bah, at the end, all of them are just a mess.
Returning to the accessibility issue. The only way accessibility could be handled is by creating a base framework (from the GTK, or QT or JSwing or any other GUI toolkits) that provides accessiblity features to the interfaces. This means that the application developers will not need to worry (too much) about accessibility because the "text control" will contain the features by default*(and this is the "most-most-important-issue"*. And, the programmer will just have to addere to a set of minimum accessibility rules (like using system defined colors and fonts [something, the great Mark's sysinternals process explorer doesn't do for example, as after I changed my font DPI to 144, the process list font is not changed and I also use background color as Black and font as white, but it is not adopted by this program)).
* Talking on this "default state" of the features, it is the same story with accessibility as with security. For an example, I know that Java has some interfaces wich allow for accesibility properties (although I have not used them). It also has some classes for secure comunication. But these are not the DEFAULT classes which everyone uses.
Iff Java had implemented security and accessibility in the common controls/classes used by everyone, of course it would be more work for the developers but it would help them to LEARN to implement those features.
Ubuntu is an African word meaning 'I can't configure Debian'