I found this list in a group discussion on LinkedIn.com: Top 10 Things CIOs Need to Know About Accessibility
I particularly like numbers 2 and 3.
"Designing in accessibility is much more cost effective than trying to “fix” deployed resources, so accessibility must be a part of the planning process for new and updating existing IT resources and services."
I have been called on by development teams to "check the accessibility" of a product, feature, service; after it has been built, after it has been incorporated into a product, after the ink has dried on the contract. The development team expected a completed checklist filled with check-marks in the "passed" column but nothing in the "failed" column. But checking items off a list never insures anything. (Winberg) What becomes of the features that did, in fact, fail? I have had to be the one to request that a beautifully designed and engineered feature be removed from a product because it just couldn't be make accessible.
Accessibility must be a included in purchasing requirements and RFPs. Accessibility testing must be integrated into the evaluation of products for purchase. Products will only become more accessible when vendors are held accountable to accessibility standards. (Emphasis mine)
I heard an interesting story during a tutorial at a conference. A university was considering a service for the purchase of tickets to the university's sporting events. When the service was tested for accessibility, it failed so the web master rejected to proposal to use the service until that service was accessible. The web master took a lot of heat for that decision, but, because the accessibility was added globally, all users of that service benefited.
Enjoy the list.
Reference:
Winberg, Fredrik. (1999). Discount Accessibility Engineering: Haven’t we Met Before. INTERACT 99 Workshop: Making Designers Aware of Existing Guidelines for Accessibility.
No comments:
Post a Comment