I also post some ideas related to the way we apply Accessibility into web project under 2 views: Company view and Project view.
Outline of this post:
- What is accessibility?
- WCAG (Web Content Accessibility Guidelines)
- ATAG (Authoring Tool Accessibility Guidelines)
- UAAG (User Agent Accessibility Guidelines)
- EARL (Evaluation and Report Language)
- WAI-ARIA (Accessible Rich Internet Application)
- Why we need to support accessibility?
- How to apply accessibility?
What is accessibility?
This is the Web accessibility definition from W3C
Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.
You can find here some scenarios that People with Disabilities Using the Web
From now, when we talk about Accessibility - we're talking about the ways to support people with disabilities to use the web.
So, do not confuse this definition with Usability.
Web standards for Accessibility
W3C composed a standard for Accessibility called WAI. These are a collection of guidelines to help us create web site and tools to support Accessibility.
There are 5 standard groups in WAI
1. WCAG (Web Content Accessibility Guidelines):
These are guidelines for web content. If we are a web based solution company - we should follow this. I need to explain to you more detail about this because this is what we have to support in our web projects.
In this document, there are 14 guidelines:
- 1. Provide equivalent alternatives to auditory and visual content.
- 2. Don't rely on color alone.
- 3. Use markup and style sheets and do so properly.
- 4. Clarify natural language usage
- 5. Create tables that transform gracefully.
- 6. Ensure that pages featuring new technologies transform gracefully.
- 7. Ensure user control of time-sensitive content changes.
- 8. Ensure direct accessibility of embedded user interfaces.
- 9. Design for device-independence.
- 10. Use interim solutions.
- 11. Use W3C technologies and guidelines.
- 12. Provide context and orientation information.
- 13. Provide clear navigation mechanisms.
- 14. Ensure that documents are clear and simple.
If you can support all checkpoints with level 1, you get Conformance Level "A".
If you can support all checkpoints with level 1, 2, you get Conformance Level "Double-A".
If you can support all checkpoints with level 1, 2,3 you get Conformance Level "Triple-A".
2. ATAG (Authoring Tool Accessibility Guidelines)
These are accessibility guidelines for tool to create content. Eg: WYSIWYG Editors, media tools, ...
3. UAAG (User Agent Accessibility Guidelines)
These are accessibility guideline for Web browsers, media players, and other user agent.
4. EARL (Evaluation and Report Language)
Evaluation and Report Language (EARL) is a machine-readable format for expressing test results. The primary motivation for developing EARL is to facilitate the processing of test results, such as those generated by Web accessibility evaluation tools, using a vendor-neutral and platform-independent format.
5. WAI-ARIA (Accessible Rich Internet Application)
WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies
Why we need to support Accessibility?
- Provide equal access and equal opportunity to people with disabilities
- Web accessibility is required by laws and policies in some cases. You can see here some list of relevant laws and policies around the world
- This is a new trend in 2.0 web sites. If you can support this, it is an added value to your customer.
How to apply accessibility?
In my point of view, I think we have 2 views to apply this.
Apply under organization view
The first thing we need to do is: training for web developers about Accessibility and its importance. Your developers must understand about WHY they need to follow it.
Second, you should have HTML coding standard document. This is a guideline to help your development team can follow it and transfer to the new one. Before doing this step, you should select the conformance level that your company will support by default. Actually, I haven't seen any site get the Conformance Level "Triple-A" (except http://www.w3.org/WAI/)
Apply under project view
If you want to apply WCAG. You should create a process to support this. In my point of view, the simple process should have 3 below roles:
1. HTML designer: he/she must make sure the output HTML design follow WCAG standard.
2. Web developer: he/she must apply HTML design into the code by proper way that create the final version matching WCAG standard.
3. Content checker or QC: check the final output.
4. Content developer: when your site is deployed into production, content developer takes responsibility of creating/editing content. He must has knowledge about Accessibility to follow that.
As a process, you must have document, guidelines and checklist to support it.
Roles in process are up to you. I just raise some default roles in a simple way. You can create your customized version to follow the default support conformance level (of your company) in WCAG.
Good luck!
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=f1695ecb-b2e7-4cf2-b51d-eb29b62e869d)
