Apply accessibility to web projects

Recently, I see there' re many persons misunderstand about Accessibility. Someone can not distinguish it with Usability. So, I post this entry to help you have a general overview about this.
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:

1. What is accessibility?
   
   
   
   1. WCAG (Web Content Accessibility Guidelines)
   
   
   2. ATAG (Authoring Tool Accessibility Guidelines)
   
   
   3. UAAG (User Agent Accessibility Guidelines)
   
   
   4. EARL (Evaluation and Report Language)
   
   
   5. WAI-ARIA (Accessible Rich Internet Application)
   
   
2. Why we need to support accessibility?
3. 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.

Each guideline has one or many checkpoints with 3 types of priority: 1(MUST) , 2 (SHOULD), 3 (MAY).

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!

Basic course for junior web developers

While working in Pyramid Consulting, I’ve had a chance to work with Mr. Truong Lap Vi. He was one of Technical Architects of Pyramid Consulting. I’ve learned a lot of things from him. Based on his original training course, I’ve added some customizations to create a newer version of the Basic course for junior web developer.
This basic course takes only 3-4 hours. The purpose of this course is:
+ Based on the Web model to explain the vision and road map of a web developer.
+ Explain what good code is.
The original structure of this course has 2 parts:
1. Web model
2. Good code
2.1. What is good code
2.2 Good function
2.3 Good class
I’ve changed its structure a little bit and add more sections:
1. Web model
2. Good code
2.1. What is good code
2.2 Good piece of code
2.3 Good function
2.4 Good class (make the definition clearer)
3. Best practices in coding

You can find the slide for this course here:
Basic course for junior web developers

Javascript programming

While working with a lot of web development teams, I found a truth: most of developers (at least: Vietnamese developers) do not think Javascript is important. Most of them use javascript as tips and tricks - just google and apply every script they found to solve their problem. Parts of them try to prevent using javascript with complex technique into their project - with them Javascript is a nightmare.

I agree that writing Javascript to make the code run cross browser is complex and difficult with some developer. However, that’s not a big problem if you have a deep knowlege about Javascript. Everything has a little bit difficult starting. Right?

In this series of posts, I don’t want to dig into old knowledge about syntax, basic types, … in Javascript. If you want to know about that, you can get them with google. This series of post only focuses into these points:

1. Javascript introduction

2. Object oriented programming in Javascript

3. Unit testing with Javascript

4. Introduce some Javascript frameworks nowadays.

I am writing these parts and will post them one by one.

Wait ‘n enjoy.