Accessibility Testing
Definition
Accessibility is
the degree to which a product, device, service, or environment is available to
as many people as possible. Accessibility can be viewed as the "ability to
access" and benefit from some system or entity. The concept is often used
to focus on people with disabilities or special needs (such as the Convention
on the Rights of Persons with Disabilities) and their right of access to
entities, enabling the use of assisting technology.
Web
accessibility refers to the inclusive practice of making websites usable by
people of all abilities and disabilities. When sites are optimally designed,
developed and edited, all users can have equal access to information and
functionality. For example, when a site is coded with semantically meaningful
HTML, with textual equivalents provided for images and with links named
meaningfully, this helps blind users using text-to-speech software and/or
text-to-Braille hardware.
Background
The Americans with Disabilities
Act (ADA) of 1990 is a law that was enacted by the U.S. Congress in 1990. The
ADA is a wide-ranging civil rights law that prohibits, under certain
circumstances, discrimination based on disability. Also, in 1998 the US
Congress amended the Rehabilitation Act to require Federal agencies to make
their electronic and information technology accessible to people with
disabilities. Section 508 was enacted to eliminate barriers in information
technology, to make available new opportunities for people with disabilities, and
to encourage development of technologies that will help achieve these goals. The
ADA and the above amendment paved way for Web Content Accessibility Guidelines
(WCAG 1.0), that are a part of a series of Web accessibility guidelines
published by the W3C's Web Accessibility Initiative. They consist of a set of
guidelines for making content accessible, primarily for disabled users. The
guidelines were published in 1999.
Accessibility testing is
the technique of making sure that your product is accessibility compliant.
Basically accessibility
problems can be classified into following four groups, each of them with
different access difficulties and issues:
1. Visual
impairments - such as blindness, low or restricted vision, or color blindness.
User with visual impairments uses assistive technology software that reads
content loud. User with weak vision can also make text larger with browser
setting or magnifying setting of operating system (in Windows go to Start à
All Programs à
Accessories à
Accessibility à
Magnifier or Start à
All Programs à
Accessories à
Accessibility à
Narrator).
2. Motor
skills - such as the inability to use a keyboard or mouse, or to make fine
movement (in Windows go to Start à All Programs à Accessories à Accessibility à
On Screen Keyboard).
3. Hearing
impairment - such as reduced or total loss of hearing
4. Cognitive
abilities - such as reading difficulties, dyslexia or memory loss.
Before
moving on to testing we must make sure that the developers are aware of the
following Web Content Accessibility
Guidelines. The guidelines must be taken into consideration
while designing requirements for web accessibility of an application.
1.
Provide equivalent alternatives
to auditory and visual content - Provide content that, when presented to the
user, conveys essentially the same function or purpose as auditory or visual
content.
2.
Don't rely on color alone -
Ensure that text and graphics are understandable when viewed without color.
3.
Use markup and style sheets and
do so properly - Mark up documents with the proper structural elements. Control
presentation with style sheets rather than with presentation elements and
attributes.
4.
Clarify natural language usage -
Use markup that facilitates pronunciation or interpretation of abbreviated or
foreign text.
5.
Create tables that transform
gracefully - Ensure that tables have necessary markup to be transformed by
accessible browsers and other user agents.
6.
Ensure that pages featuring new
technologies transform gracefully - Ensure that pages are accessible even when
newer technologies are not supported or are turned off.
7.
Ensure user control of
time-sensitive content changes - Ensure that moving, blinking, scrolling, or
auto-updating objects or pages may be paused or stopped.
8.
Ensure direct accessibility of
embedded user interfaces - Ensure that the user interface follows principles of
accessible design: device-independent access to functionality, keyboard
operability, self-voicing, etc.
9.
Design for device-independence -
Use features that enable activation of page elements via a variety of input
devices.
10.
Use interim solutions - Use
interim accessibility solutions so that assistive technologies and older
browsers will operate correctly.
11.
Use W3C technologies and guidelines
- Use W3C technologies (according to specification) and follow accessibility
guidelines. Where it is not possible to use a W3C technology, or doing so
results in material that does not transform gracefully, provide an alternative
version of the content that is accessible.
12.
Provide context and orientation
information - Provide context and orientation information to help users
understand complex pages or elements.
13.
Provide clear navigation
mechanisms - Provide clear and consistent navigation mechanisms -- orientation
information, navigation bars, a site map, etc. to increase the likelihood that
a person will find what they are looking for at a site.
14.
Ensure that documents are clear
and simple - Ensure that documents are clear and simple so they may be more easily
understood.
As
per WCAG 1.0 following priorities are defined:
Priority 1: Web developers must satisfy these
requirements (the above 14 points); otherwise it will be impossible for one or
more groups to access the Web content. Conformance to this level is described
as A.
Priority 2: Web developers should satisfy these
requirements; otherwise some groups will find it difficult to access the Web
content. Conformance to this level is described as AA or Double-A.
Priority 3: Web developers may satisfy these
requirements, in order to make it easier for some groups to access the Web
content. Conformance to this level is described as AAA or Triple-A.
WCAG 2.0 was published in December, 2008. It
defines the comprehensive list of
techniques for web accessibility.
Typical
test scenarios for accessibility might look similar to the following examples -
·
Make sure that all functions are
available via keyboard only (do not use mouse)
·
Make sure that information is
visible when display setting is changed to High Contrast modes.
· Make sure that screen reading
tools can read all the text available and every picture/image has corresponding
alternate text associated with it.
·
Make sure that product defined
keyboard actions do not affect accessibility keyboard shortcuts.
·
Examining each page with wide
range of browser.
·
Examining each page using screen
readers.
·
Examining each page using a
variety of analyzers and validators.
·
Examining each page using a
screen magnifier.
·
Ensure that all information
conveyed with color is also available without color.
·
Provide a text equivalent for
every non-text element that conveys information (including images, graphical
representations of text (including symbols), image map regions, animations
(e.g., animated GIFs), applets and programmatic objects, ASCII art, frames,
scripts, images used as list bullets, spacers, graphical buttons, sounds,
stand-alone audio files, audio tracks of video, and video.).
·
Provide text-only pages with equivalent
information and functionality if compliance with accessibility provisions
cannot be accomplished in any other way. The pages, in such a Web site should
be readily accessible, and facilitate the use of screen readers and other
assistive devices.
·
Organize documents so they are
readable without requiring an associated style sheet.
Preliminary Testing for Accessibility
A preliminary testing can quickly
identify some accessibility problems on a web application. A preliminary review
does not check every accessibility issue and will not catch all of the problems
on a site. Thus the method described below is not sufficient to determine if a
web app conforms to Web accessibility guidelines.
A preliminary review combines some
manual checking of representative pages on a website, along with the use of
several semi-automatic accessibility evaluation tools. Reviewers do not need to
know Web mark-up languages, but should be able to download software and
familiarize themselves with some evaluation tools, and change certain settings
on their browser. To conduct a preliminary review, all five tasks below must be
completed.
From the website to be reviewed,
select a ‘representative sampling’ of pages that match the following criteria:
§ Include all pages, which people are most
likely to visit your web application (e.g. ‘welcome page’, ‘landing page’,
etc.).
§ Include a variety of pages with
different layouts and functionality, e.g.:
Ø Web pages with tables, forms, or
dynamically generated results,
Ø Web pages with informative images
such as diagrams or graphs,
Ø Web pages with scripts or applications
that perform some function.
Following test cases can be executed
over graphical user interface (GUI) browser (such as Firefox, Internet Explorer, Netscape
Navigator, Opera, Safari, or others). Examine the selection
of pages while adjusting some settings in your browser or operating system as
follows:
Test Step#
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
1
|
Login to the application using any
browser (e.g. IE8)
|
Login must be successful
|
||
2
|
Go to Tools --> Internet
Options. Turn off images. Refresh page OR logout/login.
|
Appropriate alternative text for
the images is available.
|
||
3
|
Go to Tools --> Internet
Options. Turn off the sound. Refresh page OR logout/login.
|
Audio content is still available
through text equivalents
|
||
4
|
Go to Tools --> Internet
Options. Use browser controls to vary font-size.
|
The font size changes on the screen
accordingly. The page is still usable at larger font sizes.
|
||
5
|
Change the screen resolution by
using the Display Controls. Refresh page OR logout/login.
|
Horizontal scrolling is not
required
|
test with different browsers, or
examine code for absolute sizing, to ensure that it is a content problem not
a browser problem
|
|
6
|
Resize the application window to
less than maximum. Refresh page OR logout/login.
|
Horizontal scrolling is not
required
|
test with different browsers, or
examine code for absolute sizing, to ensure that it is a content problem not
a browser problem
|
|
7
|
Go to Tools --> IE Options. Use
browser controls to change the display color to gray scale. Refresh page OR
logout/login.
|
Observe whether the color contrast
is adequate
|
||
8
|
Without using the mouse, use the
keyboard to navigate through the links and form controls on a page (e.g. use
Tab key on MS Windows)
|
All the links must be accessible
and the links clearly indicate where they lead to (on IE it will be displayed
on Status Bar)
|
||
9
|
Repeat the above test cases with
other browsers e.g. Chrome, Firefox, Safari, IE8, IE9 etc.
|
The cases must be successful
|
For reviewers who have disabilities,
following tasks may be done with another person who does not have the same
disability.
Examine pages using specialized
browsers
A voice browser or a text browser (e.g. Lynx) can be used to examine the
selection of pages while answering these questions:
1.
Is equivalent information available through the voice or text
browser as is available through the GUI browser? For example, the images and
videos must have the ALT text present for them.
2.
Is the information presented in a meaningful order if read
serially?
Experienced users of screen readers
may substitute a screen reader for a voice or text browser, but if blind, may
need a sighted partner to compare information available visually; if sighted,
listen to it with eyes closed, then open eyes and confirm whether the
information is equivalent.
Detailed Inspection for Validating Accessibility
There are two components to detailed
testing:
·
Tool-based testing: where the evaluator uses a tool to probe how
the various bits of a web site are working together.
·
Manual Testing: where the evaluator looks directly at the code and
assets of a web site to scour for problems.
Tools for Accessibility Testing
Even though it
is suggested that Manual Testing by the real (disabled) users is the best way
to assess and application for web accessibility, tools can also be used. There
are several tools available which can be used to evaluate a website for
accessibility compatibility:
1.
The following website can be directly used to
evaluate a website:
This tool is a free web accessibility evaluation tool. It is used to aid humans in the web
accessibility evaluation process. Rather than providing a complex technical
report, WAVE shows the original web page with embedded icons and indicators
that reveal the accessibility of that page. If you have files/applications that
are not publicly available on the internet, you can use the link within this
app to validate them too. The above page contains relevant link for that.
2.
AChecker - AChecker is
an open source Web accessibility evaluation tool. It can be used to review the
accessibility of Web pages based on a variety international accessibility
guidelines. Automated accessibility checkers can only identify a limited number
of barriers in Web content with certainty. A human must interact with an
accessibility review to make decisions on potential problems automated tools
cannot identify. Evaluating accessibility with AChecker is an interactive
ongoing process. AChecker knows when it is unable to identify a potential
problem and will ask the evaluator to manually check for the problem. Because
Web content often changes, AChecker can be used to monitor the accessibility of
Web content as it evolves. AChecker also allows users to create accessibility
guidelines, if for instance they are working in an enclosed environment that
requires a specific level of accessibility. It also allows users to create new
checks for the system as technology develops and makes it possible to check
issue that may not have previously been possible. For more details see the
following link:
3.
Accessibility
Inspector - It is a free Mac application, which can be used to test the website
on a Safari. For more details please click here.
4.
VoiceOver - It is a screen reader built into
Apple Inc.'s Mac OS X, iOS and iPod operating systems. By using VoiceOver, the
user can access their Macintosh or iOS device based on spoken descriptions and,
in the case of the Mac, the keyboard. The feature is designed to increase
accessibility for blind and low-vision users, as well as for users with
dyslexia. On iOS devices it can accessed through Settings à General à Accessibility.
5.
Color Contrast
Analyzer – This online webpage can be used directly to assess the contrast of
two colors. It determines color visibility based on algorithms suggested by the
W3C - Two colors are considered to provide good color visibility if the
brightness difference and the color difference between the two colors are
greater than a set range. In addition to analyzing contrast for normal vision
it also calculates results for three types of color blindness (Protanopia,
Deuteranopia and Tritanopia).
6.
Accessibility
Evaluation Toolbar (for Firefox) - It can support web developers in testing web
resources for accessibility features.
7.
NVDA -
NonVisual Desktop Access (NVDA) is a
free and open source screen reader for the Microsoft Windows operating system.
Providing feedback via synthetic speech and Braille, it enables blind or vision
impaired people to access computers running Windows for no more cost than a
sighted person. Major features include support for over 35 languages and the
ability to run entirely from a USB drive with no installation.
8.
JAWS -
JAWS (Job Access With Speech) is a computer screen reader program for Microsoft
Windows that allows blind and visually impaired users to read the screen either
with a text-to-speech output or by a Refreshable Braille display.
There are
several other tools which can be
used for testing of web accessibility. Their usage will depend upon you
application and specific requirements.
Manual Testing
WCAG 2.0 splits
its best practice criterion into four principles. Content and functionality
must be:
·
Perceivable
·
Operable (for example, it should be possible to
interact with a web site without a mouse and navigate it with a screen reader).
·
Comprehensible (for example,
copy should not be more complicated than it needs to be and the web site should
operate in a predictable manner).
·
Robust (for example, web sites should be
interoperable with different user agents and navigation should be consistent).
Perceivable
One subset of perceivable
problems revolves around the provision of alternative media of various types.
In the Preliminary test cases we have seen the validation of the ‘alt’ text for
images and videos. Following are some of the test cases that be executed to
validate whether the website is perceivable or not:
Note – Some test
steps might overlap with preliminary test cases discussed earlier.
Test Step#
|
Principle to be tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
1
|
Login to the application using any
browser (e.g. IE8)
|
Login must be successful
|
Note that these settings are
for IE8. Other browsers will vary in navigation of controls.
|
||
2
|
Perceivable
|
Go to Tools --> IE Options. Turn
off images. Refresh page OR logout/login.
|
Appropriate alternative text for
the images is available.
|
||
3
|
Perceivable
|
Check the images that have been
used only for decorative purposes.
|
No alternative text must be
visible.
|
||
4
|
Perceivable
|
Check the images being used as
links.
|
Alternative text must be visible.
Otherwise the link address may be visible.
|
||
5
|
Perceivable
|
Check the Form Buttons
|
Alternative text must be visible Or
the button action must be displayed.
|
||
6
|
Perceivable
|
Go to Tools --> IE Options. Turn
off the sound. Refresh page OR logout/login.
|
Audio content is still available
through text equivalents
|
||
7
|
Perceivable
|
Go to Tools --> IE Options. Turn
off the sound. Refresh page OR logout/login.
|
Some text description of Video
content must be available.
|
||
8
|
Perceivable
|
Go to Tools --> IE Options. Turn
on the Videos. Refresh page OR logout/login. For a particular plugin (e.g.
Windows Media Plugin) open Windows Media Player and adjust the Accessibility
Settings (such as captions and audio descriptions, volume etc.) and check the video on the web
page.
|
The content must be visible as per
the settings done in the tool.
|
||
9
|
Perceivable
|
Go to Tools --> IE Options.
Select 'default' settings. Refresh page OR logout/login. Check for sufficient
color contrast of all text with respect to their background.
|
The contrast must be suffient. All
the text must be properly visible.
|
It is advisable to use Juicy Studio
CSS Analyser for this.
|
|
10
|
Perceivable
|
Go to Tools --> IE Options.
Increase text size by 2-5 steps Refresh page OR logout/login.
|
The content must not be hard to
read.
|
The results might not be pixel
perfect.
|
|
11
|
Perceivable
|
Go to Tools --> IE Options.
Select 'default' settings. Refresh page OR logout/login. Zoom into the page
to some 200%.
|
The content must not be hard to
read.
|
The results might not be pixel
perfect.
|
|
12
|
Perceivable
|
Go to Tools --> IE Options. On
the General tab, click Color. Deselect Use Windows Colors. Select same color
for Text and Background. Click OK.
|
On the displayed page the color
must not be changed. It must override this setting.
|
||
13
|
Perceivable
|
The IE Options window must be open.
Click on Accessibility. Select 'Ignore colors specified on webpages'. Click
OK.
|
The displayed webpage color will
change such that the font color and background color is same, as changed
above.
|
||
14
|
Perceivable
|
Go to Tools --> IE Options. On
the General tab, click Fonts. Change something different from 'default font'.
Click OK.
|
On the displayed page the fonts
must not be changed. This setting must be overridden.
|
||
15
|
Perceivable
|
Turn of the images and click OK
|
The alt text for images must be
visible.
|
||
16
|
Perceivable
|
The IE Options window must be open.
Click on Accessibility. Select 'Ignore font styles specified on webpages'.
Click OK.
|
On the displayed webpage fonts will
change to the above
|
||
17
|
Perceivable
|
Carry out the above test cases on
other browsers also.
|
All the cases must pass
|
Note that the above settings are
for IE8. Other browsers will vary in navigation of controls.
|
Operable & Comprehensible
Health and safety is a
crucial, though rarely considered, part of making a website operable. A good
way to test the operability of websites is simply to try to see if you can
access all essential content and functionality with different devices.
Note – Some test
steps might overlap with preliminary test cases discussed earlier.
Test Step#
|
Principle to be tested
|
Action
|
Expected Result
|
Actual Result
|
Comments
|
1
|
Login to the application using any
browser (e.g. IE8)
|
Login must be successful
|
|||
2
|
Operable
|
Look out for any flashing/blinking
content on the website.
|
•There must not be more than three
general flashes and no more than three red flashes within any one-second
period, or
•The combined area of flashes occurring concurrently must not occupy more than a total of one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 by 768 pixels. |
Please use the Open Source
Photosensitive Epilepsy Analysis Tool (http://trace.wisc.edu/peat/)
Note - Design Web pages that do not
cause the screen to flicker with a frequency greater than 2 Hz and lower than
55 Hz.
|
|
3
|
Operable
|
Try to access all the controls via
the keyboard.
|
The current focus must always be
clearly indicated. All the functionality must be accessible via the keyboard.
|
||
4
|
Operable
|
Operate the website with a
touchscreen device
|
The controls must be accessible and
the respective pages navigable
|
This can be a part of digital
device testing.
|
|
5
|
Operable
|
Test your web application using the
voice commands (e.g. say - link name, Go to Favorites Name)
|
The relevant link (defined by name)
must open.
|
For Opera for Windows, its Voice
Add-On can be used. Mac OS X has MacSpeech Dictate built in for this. See http://www.exaq.com/DNS/QR10/IE.html
for a comprehensive list for IE)
|
|
6
|
Operable and Comprehensible
|
Test your web application using a screen
reader
|
1. All the relevant text can be
heard from the standard output.
2. The punctuation must be correct
and comprehensible.
|
1. Microsoft Windows operating
systems have included the Microsoft Narrator screen reader since Windows
2000. Apple Inc. Mac OS X includes VoiceOver, a feature-rich screen reader.
2. Use Juicy Studio’s
Readability Test tool for assessing readability of the web page.
|
|
7
|
Operable and Comprehensible
|
Carry out the above step on all the
web pages
|
1. All the relevant text can be
heard from the standard output.
2. The punctuation must be correct
and comprehensible.
|
1. Microsoft Windows operating
systems have included the Microsoft Narrator screen reader since Windows
2000. Apple Inc. Mac OS X includes VoiceOver, a feature-rich screen reader.
2. Use Juicy Studio’s
Readability Test tool for assessing readability of the web page.
|
|
8
|
Operable
|
Test your web application using a voice
browser
|
1. All the relevant text can be
heard from the standard output.
2. The punctuation must be correct
and comprehensible.
|
The Internet Explorer can have a
toolbar which can help in voice browsing (http://www.voicebrowsing.net/). Following commands can be tested
-
back - forward - refresh - reload (same as refresh) - search - new window - home |
|
9
|
Operable and Comprehensible
|
Carry out the above step on all the
web pages
|
1. All the relevant text can be
heard from the standard output.
2. The punctuation must be correct
and comprehensible.
|
||
10
|
Operable and Comprehensible
|
Test the application with a Screen
Magnifier
|
The content must be consistent and
predictable.
|
It is better if the application has
been tested for Usability (Consistency and Predictability). Such an
application easy to navigate using a screen magnifier. E.g. 1) The Headings
must follow a hierarchy. 2) Menu items must be links leading to pages which
are same in design as sending page.
3) Popup windows must be avoided.
4) The webpage content must not change on a mouse-over event (Whenever a
script changes the content of a page, the change must be indicated in a way
that can be detected and read by a screen reader.)
5) Link appearance must change on
mouse-over.
|
|
11
|
Operable
|
Test the application for CAPTCHA
Image
|
The CAPTCHA can be ‘listened to’
also.
|
Robustness
Testing whether content is robust involves checking that
technologies are being correctly used. At a very basic level, you can run
markup and code through linters such as:
Hence we can see that Accessibility
Testing involves a lot of stuff to be tested under the non-functional testing
realm. It has aspects that are critical to current day application development
and testing. Hence, accessibility testing must be carried out with sincerity in
an organization seeking a wide audience.
No comments:
Post a Comment