Accessibility Testing Report Name: Naisargi Shah SCS Email: npshah@scs.ryerson.ca
Table of Contents Overview- What is accessibility testing? Why is accessibility necessary? WCAG o History of WCAG Guidelines of WCAG 2.0 Tools for accessibility testing My insights
Overview of Accessibility Testing: There are many tests that a software tester has to do in order to make the software usable. One of the test is Accessibility Testing, which is a subset of usability testing. In accessibility testing, software is tested to make sure that it is usable by everyone, including people with or without disabilities. This type of testing is basically done to decide the accessibility of the software for those with disabilities. (McKay 2014) When doing accessibility testing, software tester has to follow many standards and guidelines that are out there for this testing type. One of them is called Web Content Accessibility Guidelines (WCAG). There are many versions of WCAG but the latest one is 2.0 which will be discussed further. Other legislative requirements that may be considered includes Disability Discrimination Act (mostly in UK, Australia) and Americans with Disabilities Act (ADA). It is easier for a software to meet the accessibility requirements if the software tester follows the appropriate requirements and guidelines. (Henry 2005) Why is it necessary? It is important for a software tester to keep in mind that the software must first be accessible in order to make it usable. The software should be usable by everyone, including people with disabilities. It involves a wide range of disabilities which are mentioned below. Software tester should keep in mind the people with: Blindness or low vision Deafness or hearing loss Limited movement Photosensitivity Speech disabilities Reading disorders Neurological disabilities By performing accessibility testing, tester should not only keep people with disabilities in mind because software should be accessible for older people too. Due to aging, people will start having these problems too. (WCAG 2008) WCAG: A bit of history of WCAG: The Web Content Accessibility Guidelines Working Group (WCAG WG), part of the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI), developed the technical documents of WCAG. The web accessibility initiative (WAI) keeps updating the techniques and understanding of WCAG 2.0 regularly. There are also translations of WCAG available in many
other languages such as Arabic, Hindi, Korean and etc. WCAG 2.0 was published on 11 December, 2008 and WCAG 1.0 was published in May 1999. There are only some differences in the approach and guidelines between WCAG 1.0 and WCAG 2.0. The WCAG 2.0 concentrates mainly on advanced technologies which is more preferable for accessibility testing in present. (WCAG 2008) Guidelines for WCAG 2.0: WCAG is a collection of guidelines, which states the accessibility standards for web software. It has 4 principles which consists of 12 guidelines. The four principles of accessibility are as follows: Perceivable-Information and user components presented to all users must be viewable for all. The software should have text alternatives for non-text section, captions for multimedia section, and should be easier for users to hear and see content. So basically the software should have the ability to be able to present in many different ways. Operable-All parts of the interface should be operable by all users. All functionality should be available from a keyboard, users should not have limited time to read and use the software, and users should be able to navigate through and find what they intend to find. Understandable-All users must be able to understand the information and operation of the interface. The text should be readable for all users. Robust-Content should be robust so that it is accessible by range of user agents, including assistive technologies. The compatibility with future and present user tools should be maximized. It is stated on the W3C website that if one of the principle is not true, then web is not accessible by people with disabilities. For each guidelines under the four principles, there are also success criteria, which have three levels: Level A- Minimum level of conformance and satisfies all the Level A success criteria. Level AA- Satisfies all Level A and Level AA success criteria. Level AAA- Satisfies all level A, AA and AAA success criteria. The principles above are explained in terms of the guidelines. Therefore, here is the actual list of guidelines in each principles: Perceivable: Guideline 1-There should be text alternatives for non-text parts so that it can change its form for people who need large print, simpler language, or speech symbols. Guideline 2-There should be alternatives for time-based media. Users should get enough time for video or audio media and the captions should be synchronized accordingly to that time.
Guideline 3-The content should be adaptable for presenting it in different ways. It should be easy to switch to simpler layout without losing the structure or information. Guideline 4-The content should be distinguishable so it is easier for users to see and hear content. Some of the ways to make it easier for users are separating foreground from background, controlling automatic audio, and should have contrast between text and images. Operable: Guideline 5-The keyboard should be accessible for the particular software. The keyboard interface should be operable for the functionality of the content. Guideline 6-The users should be provided with enough time for reading and using content. If there are any time limits set by content, users should be able to change that at their convenience. Guideline 7-It should be designed in such a way that it causes seizures. Guideline 8-The software should be navigable so it should help users find the content that they intend to find. The pages should be titled, section headings and purpose of any links should be stated. Understandable: Guideline 9-The software s content should be readable and understandable for all users. There should be a mechanism that provides definitions for unusual words and meaning of abbreviations. There is also a mechanism available which determines the pronunciation of words. Guideline 10-The software should operate in a predictable way. Guideline 11-The software should be able to help users for input by correcting and avoiding their mistakes. Robust: Guideline 12-The software should be compatible for all types of future and current technologies or any other user agents. (WCAG 2008) Tools for accessibility testing: In order to test the accessibility of a particular software, many software programs and online services are available to evaluate the accessibility. Some of the tools include: Accessibility Color Wheel-It is created by Giacomo Mazzocato and released on April 27, 2013. This tool helps the software developer to make the choice of color pair to use in the software. With the help of three kinds of
color blindness, the tool would show if the colors are accessible or not. I also tested this tool on my own and found out that this tool is really easy to use and helpful for software developers. It would output a checkmark for accessible colors and X mark for colors that are not accessible. AChecker-This tool is created by Inclusive Design Research Center and was released on September 19, 2008. This tool is meant for HTML pages as it checks single HTML pages for the accessibility standards. I tested this tool myself as well and found it easy to test. You can upload your HTML file or paste the URL in the box and the accessibility of it will be check automatically. WCAG Compliance Auditor-It was created by Funnelback and released on October 01, 2011. This tool check entire websites against WCAG guidelines. It provides recommendations on how to fix errors, identifies failures and provides a standard against which accessibility can be measured over time. There are many more tools which can be used to check accessibility and they can be found at this website: http://www.w3.org/wai/er/tools/ (Eggert and Shadi, 2006) Some Insights: The testing plan for accessibility testing would be same as the usual testing activities. Although, in some parts you would keep accessibility in your mind while creating the test plan. For example, in the planning process you would identify different disabilities of people as the test items. The exit criteria would be when your software/page is fully tested from different tools and stated as accessible. I believe that accessibility testing is very important for all software or websites. There are many disable users out there so it is very important to make software accessible for them as well. I also believe that a software developer should always keep all user s needs in mind when testing/developing the software. Each and every user should get equivalent access. The software developers and testers should use all the resources/tools out there to make the software accessible for everyone. And thus, accessibility testing should be done for all software testing as it is really necessary in real world.
References "Web Content Accessibility Guidelines (WCAG) 2.0." Web Content Accessibility Guidelines (WCAG) 2.0. W3C, 11 Dec. 2008. Web. 11 Mar. 2015. McKay, Judy. "10. Usability and Accessibility Testing." The Software Test Engineer's Handbook. By Graham Bath. 2nd ed. N.p.: Rocky Nook, 2014. N. page. E-book. Henry, Shawn Lawton. "Web Content Accessibility Guidelines (WCAG) Overview." WCAG Overview. N.p., July 2005. Web. 14 Mar. 2015. Mazzocato, Giacomo. Accessibility Color Wheel. Program documentation.accessibility Color Wheel. N.p., 27 Apr. 2013. Web. Eggert, Eric, and Shadi Abou-Zahra. "Web Accessibility Evaluation Tools List." Web Accessibility Evaluation Tools List. N.p., Mar. 2006. Web. 16 Mar. 2015