Content Copyright © 2008 Bloor. All Rights Reserved.
This blog was originally posted under: Accessibility
Microsoft has taken accessibility seriously for many years, working closely with Assistive Technology vendors, defining Microsoft Active Accessibility (MSAA) and, more recently, UI Automation, sitting on relevant standards organisations and being a founder of the Accessibility Interoperability Association (AIA).
Its commitment to ensuring that accessibility is baked into all products has recently been boosted by incorporating it into Microsoft’s Trustworthy Computing Initiative. The initiative, as its name implies, started off concentrating on security. But it soon became apparent that the processes and methods needed to ensure security applied equally to a variety of other issues. I have known these issues for many years under the rather uninspiring title of non-functional requirements (NFR)—so named because they were requirements that did not relate to the specific functions a product delivered. These issues include security, privacy, reliability, usability, and maintainability.
The issues have many characteristics in common:
- They only become noticeable when they fail.
- It is difficult to effectively bolt them on to an existing product.
- The same requirement, and often solution, crosses multiple products.
- They require facilities in differently levels of the software stack, possibly from different vendors, to work seamlessly together.
Accessibility has all these characteristics and, like the other areas of Trustworthy Computing, requires engineering excellence to ensure that it works. Engineering excellence can only be guaranteed if there is support from the very top; marketing pressures can never be allowed to compromise quality.
Moving Microsoft’s Accessibility Unit, with its existing director, into the Trustworthy Computing Organisation means that it has been recognised as an essential feature of any future product. It will now have the power to ensure that accessibility will be built into every phase of development: design, code, test, document, educate and roll out.
Even though Microsoft has had a long history of supporting accessibility it is true that many of its products still need to be improved. The new organisation should ensure that improvements are made even if changes will take time. It may not be possible to make all the changes in one tranche so it may require several product releases to make the product fully compatible. What it will mean is that accessibility failures will from now on be taken as seriously as security failures.
I think the new organisation will improve accessibility over the medium term.
Finally I think it should raise questions in the reader’s mind “Where is accessibility in my organisation? Does it have sufficient gravitas and power to ensure accessibility in my products (for vendors) or systems (for corporations)?”