Website Accessibility Evaluation Methodology

Being an Accessibility Enthusiast, I generally get a question – How to evaluate accessibility of a website? Is there any approach or methodology which guarantees the accessible website? Well, I don’t think any methodology would guarantee a 100% accessible website until you get the website tested from real users – the users who face the pain of inaccessible websites.

Anyway, when the question became too common – I thought it's time to work on this and here I am presenting a methodology to evaluate accessible website. This methodology is evolved from fine tuning of industry’s best practices and Website Accessibility Conformance Evaluation Methodology by W3C.

This methodology includes the different phases of accessibility evaluation starting from collecting the baseline information to the last phase of retesting the fixed issues. This methodology can be used for existing websites and during earlier development stages of the website. This methodology can be used for evaluating static, dynamic, mobile and other types of websites.

Draw a Line
The objective of this phase is to collect the information and understand the accessibility requirement of the customer. This is accessibility evaluation preparation phase wherein tester collects prerequisite information such as target website, business nature, current accessibility status, identification of Assistive Technology and conformance standards to be implemented.

Let’s Explore
The tester explores the target website to get thorough understanding of website functionality, use and purpose. The exploration carried out in this phase helps in later stages when evaluation of target website takes place. The objective of this phase is to identify:
• Critical web pages of the website – The website is explored to identify mandatory functionality and critical web pages which are core of the website and might directly impact the business. The outcome of this step is the list of all critical web pages and mandatory functionality that user performs on the website.
• Common web pages of the website – The website is explored to identify the common web pages of the website. These web pages are generally directly linked to home page and main navigation of website and sometimes represent the different states of website. The outcome of this step is the list of all common web pages on the website.
• Dynamically generated web pages – The website might have web pages which are generated dynamically based on user input and important for the website. For example, product listing page on a website. The website is explored to identify such web pages on the website.
• Other relevant web pages – Here, the website is explored to identify the web pages that are more relevant to users with disabilities and accessibility of website such as web page informing about the website accessibility features, settings, shortcuts etc. The outcome of this step is list of such web pages.
• Variety of web page types – The target website may have web pages of variety of styles, templates, layout and structure, navigation and visual design etc. In this step, the website is explored to identify such web pages on the website. The outcome of this step is the list of all such web pages differentiated by varieties.

Collect the Samples
The objective of this step is to pick up the sample of all type of web pages which represent the target website. The purpose of this sampling procedure is to ensure the good enough accessibility evaluation of website with reasonable confidence. The sample set should include:
• Sample set of all critical web pages of the target website
• Sample set of Common web pages of the website
• Sample set of each dynamically generated web pages
• Sample set of Other Relevant web pages
• Sample set of each web page type
• Sample set representing the complete process
The sampling procedure could be skipped where it is feasible to evaluate all web pages in the target website; all the web pages are considered for accessibility procedure in such situation.
The selected sample sets are further evaluated to identify the common components such as navigation menu bars, headers and footers, search form etc. which do not require the re-evaluation on each occurrence.

Use Automation Tools
During this step, the selected sample set of web pages are evaluated by multiple automation tools as per the conformance standard selected in first step. The objective of automatic testing is to quickly identify the accessibility issues in the selected set of web pages of the website. The outcome of testing in this phase is:
• a list of confirmed accessibility issues which are failed to meet success criterion of selected conformance standard
• a list of potential accessibility risks which require manual intervention before next action
• a list of features which meets with the success criteria of selected conformance standard

Manual Testing with Assistive Technology
The tester further evaluates the selected set of web pages of target website manually to conformance with each success criterion of selected standard. The objective of this step is to identify the issues a disable user might be facing in using the target website. All content of the website is evaluated:
• to find out any occurrence of failure to meet success criteria of selected conformance standard
• to find out any occurrence of failure during the interaction of each web page and web page state along with complete process
• to find out any occurrence of failure in using the website with assistive technologies selected in first step
• to verify the list of potential accessibility risks generated in previous step
• to ensure that all content is supported by accessibility features

Make a Report, Retest
This step focuses on the analysis of reports collected from automated testing and observation made during manual testing process. The purpose is to identify all false positives and false negative before reporting the issues in the bug tracker. A report is produced with analysis outcome and recommendations and suggestions for all stakeholders.

Further, a decision should be made on retesting based on the outcome of the analysis. Retesting would have similar approach of testing - using automation tools followed by manual testing with AT.

Web A11y* Beyond Guidelines

(A11y* - Accessibility)

Think about accessibility testing of a website - "WCAG" - the first word which comes in mind (Section 508, in some cases), why?

We are so obsessed of following the guidelines. When I second these guidelines are important piece of information, we also need to understand that these guidelines are mere documents for reference, they are not the laws. We shall start thinking of accessibility beyond the guidelines. The presentation is an attempt to point out the issues of blindly following the guidelines and how can we get over such issues.

Questions are welcome :)

Audio Accessibility

In my last blog post, I discussed about making the accessible videos. This post is dedicated to audio accessibility. The mind map presented below provides an insight on audio accessibility.

For Questions, Suggestions and Feedback; please leave your comment below.

Making Videos Accessible – 7 tips for making videos accessible on the website

A website has many ways to share the information with their users such as textual content, Pictures, Audios and Videos. As a picture is worth a thousand words, similarly, a video is worth a thousand pictures. Thousands of articles, blog posts and white papers are written and available over internet on how to make images accessible for users with different abilities but there is not much information on how to make videos accessible to the users.

The little information which is available is not much helpful as either it is incomplete or it revolves more around visual and auditory disabilities and does not focus on other kind of disabilities. The possible reason for this could be that the less number of videos are published when compared to the images on any website. But this should not allow web masters to ignore the accessibility around the videos. The purpose of writing this article is to provide a feasible solution for making the videos accessible for all class of users of the websites.

Why Videos should be made accessible?

A video is more informational than any other medium. For example, an image can only show how to use a device but a video can be more informative by mimicking the uses of the device; this makes a video more user friendly for the users. Making videos accessible will help the different classes of users who can’t effectively use the videos for whatever reasons.

How to make videos accessible for the users?

The ideas listed below are outcome of brainstorming I did on the subject and can be used to make the videos accessible for any class of website users.

Remember, these ideas do not help web masters to make accessible videos; they help web masters to make videos accessible for their website users.

1. Provide Captions/ Script Transcriptions along with the videos

The Captions help users with aural disabilities to learn the content of the video. There are two types of captions – Open and Closed. The Open captions are burned-in with the video while Closed Captions are written in separate file which run with video. Personally, I think that Closed Captions should be used with videos because user can control them by switching on/off.

Script Transcriptions are the text content of the video’s provided in separate file. They are similar to Closed Captions file except time stamp is not needed for Transcriptions.

2. Alternative Text for Videos

Does this sound weird to you to provide alternative text for videos as it is supposed to be for images and not for videos?

What is a video? – A collection of moving visual images.

The first guideline to make any website accessible is to provide alternative text for all meaningful images; then why videos are exceptional. It is perhaps because of videos make more sense to user. So, why do we need alternative text for videos?

We need alternative text for those videos which do not make sense to the users. For example, when I watched the movie ‘The Matrix’ for the first time, I liked the action sequences in the movie but the story didn’t make much sense. By the second time, the movie made some more sense to me; but still a few things were unclear. Then, I read the plot of the movie and I got the gist of it. Next time, it was all clear. In fact, reading the plot of the first part of this movie made it easier for me to understand the rest of the sequels.

Decision of providing alternative text with the videos should be context – based. For example, if Caption/Script Transcription is already available and descriptive enough, the alternative text can be ignored. But, a video with no audio should have alternative text to explain the content to users with visual/cognitive disabilities.

3. Accessible Media Player

An accessible media player could help more than anything else to make the video content accessible for the users. For Example,

• Having a keyboard accessible media player can help users with visual, aural, mobility or cognitive disabilities.
• For low vision/partial blind users, I advise users to use media player with Full Screen and zoom options so that users can set the video to adequate size to view it.
• Providing a volume control in the media player can be a good idea for the users who are hard of hearing. They can set the volume to an adequate hearing level.
• The web media player being used should also have features such as Play/Pause, Forward/Backward and Captions On/Off buttons. These features might seem common and available in almost every web media player but they do help the website users to a great extent. For example, If a user is hard of hearing, he can go back to hear the missed word or a user with cognitive disability might want to control the video and play according to his comfort.

If your media player has such features, don’t disable them. Let the users use them.

4. Validate Videos with PEAT

An animated segment of a film promoting the 2012 London Olympics was blamed for triggering seizures in people with photosensitive epilepsy. The charity Epilepsy Action received telephone calls from people who had seizures after watching the film on television and online. In response, it was reported that London 2012 Olympic Committee removed the offending segment from its website. (Courtesy: Wikipedia)

If your videos have red flashes, it is advised to use PEAT (Photosensitive Epilepsy Analysis Tool) to validate the videos to identify the seizures risk.

5. High Quality/High Definition Videos

The quality of the videos is reduced when viewed in full screen mode or zoomed-in, making it difficult for user to view the videos; especially users with low vision. To avoid degraded video quality and better viewing, it is advised to provide high quality videos.

6. Explicitly mention if there is ‘No Sound’

Most of users think that Captions/Transcript scripts are not needed for videos with no sound but that is an incorrect perception. Providing Caption or Transcription Script for such videos is also as important as compared to videos with audio. For example, if not informed about ‘No Sound’, a user with aural disabilities might think that supported transcript is not provided and may feel discomfort about it. In such cases, mentioning it explicitly can help user in a great way as he can concentrate totally on the video without having to look elsewhere for the transcript.

7. Keep the Content Simple

Keep the content of the video simple, if possible. Using small sentences/dialogs and simple words can make the content more accessible for users with cognitive disabilities. Provide alternative text for complex or third parties videos where content can’t be controlled as webmaster.

Why Sign Language translation can be avoided?

Although, WCAG 2.0 suggests using Sign Language Translation; I personally feel that using Sign Language Translation is not a mandate and can be avoided for various reasons listed below:

• The sign language could differ in different geographical locations
• The approach is costlier than any other approach such as providing Transcription Script or Captions.
• Limited user base – Sign Language Translation would be useful only for single class of users suffering with aural disabilities.

These ideas are based on my understanding with the subject. Let me know if you think otherwise.

Thanks to Jyothi Rangaiah for reviewing this article coming back with her valuable feedback.

Should you really follow BEST PRACTICES?

Once upon a time, not long ago, a developer created his own personal website. To keep the unauthorized users away, he added the login page. Being an internet savvy himself, he always knew how hackers plan their attack. So, instead of displaying direct error message for login fields, he showed a common message as “Username/Password is incorrect. Try again”. This was a smart move from him as now hacker couldn’t know which input was wrong. He showed this message to one of his developer friends and he followed the same. Similarly, it became BEST PRACTICE to display the common error message on the Login page.

The only best thing about BEST PRACTICES is that they are best in some contexts and worst thing is that people have tendency to follow the best. In fact, sometimes they are followed by everyone and hence become common. There can’t be hundred best students in class of hundred. Only one could be best in each subject among the hundred; others could be good, very good, average and poor.

The story said above is not a story, it is reality. The idea to change the error message worked for first developer but it didn’t work for his friend. Why? Let’s see.

• The unauthorized user entered the invalid username and password, system displays an error message “The email address or password you entered isn’t correct. Please try again”. Quite good. The user doesn’t know which is incorrect – username, password or both. (This is similar to what first developer did and other followed.)

• Then user opened “Forgotten your password?” page and entered the same email id. The system displayed the error message that entered email is not registered with website. Boom. The security provided by the previous error message is violated by this message. Now this unauthorized user knows that this is not the correct user name so he can put his energy to find the correct user name. He has got a direction to move. (In our story, first developer didn’t provide the Forgot Password page but others did. So his solution worked for him but not for others.)

The problem is people are so obsessed of following best practices that context is side-lined in most of the cases. See the below example:

• Here, if an unauthorized user enters an invalid Email address – system clearly tells him that account doesn’t exist.

• In other case, when user enters correct email and incorrect password, system displays “Email/Password combination is wrong” (BEST PRACTICE). From previous message, it is obvious that only password can be wrong in this case but as I already said that people are obsessed of following the BEST PRACTICES that they miss the tweaks.

There are two important learning from above examples:

• The BEST PRACTICES are best in their contexts and might not work for you if context differs. Do what work for you and that will be your “BEST PRACTICE”. Moreover, it doesn’t make sense to me that if everyone is following the same then how it can be called as “BEST PRACTICE”. It should be called as “GENERAL PRACTICE”.
• Don’t forget to verify linking between error messages in your application. We have seen in above scenarios that one error message is violating the rule of other. (The linking between Error messages might be new to many and should be practiced.)

If I were testing the same Forgot Password page for the website displayed above, I would ask developer to place a message like “An email will be sent shortly to registered email if it’s valid”.

Now, don’t make this as BEST PRACTICE.