Unformatted Attachment Preview
Please, using the Absolute Minimum Accessibility Inspection document, and the Accessibility
Inspection template do your first accessibility inspection, on the homepage of any university that
you choose. You must use your screen reader to do this.
if you have a Mac laptop/desktop and have VoiceOver installed, download a screen reader onto
your PC. You can choose which one you want to download.
http://www.freedomscientific.com/Downloads/JAWS (note: you will get a 40-minute version
which is free. just re-boot after 40 minutes)
http://www.nvaccess.org/ (for NVDA)
http://www.windoweyesforoffice.com/ (to get a free copy of window eyes if you have Office
2010 or later)
Absolute Minimum Accessibility Inspection (AMAI):
A Discount Usability Engineering Approach
Introduction
Very often, I am asked “how do you check if a web site is accessible?”
There are lots of different ways to check if a web site is accessible. One of
the most common methods is to use an automated software tool, such as
WorldSpace, Compliance Sherriff, or A-Prompt. But these automated tools
have their limitations. These automated tools tend to require manual
checks, where a feature on a web page COULD be a problem, but human
expertise is required to determine if that is the case. There are examples
when an automated tool detects the existence of alternative text, and
therefore rates the web page as accessible on that requirement, even
when the alternative text is something like “alternative text,” which is
meaningless. Or there are examples where mouseovers are purely
decorative, and provide no actual content, so an automated software tool
would require non-mouse equivalent event handlers, even when they
would not actually enhance the accessibility of the page in any way.
Therefore, automated tools can sometimes provide confusing and
misleading results. And by relying on an automated tool, it in no way
increases the existing human knowledge on accessibility. If the tool
identifies accessibility problems, you may fix them, but you may not really
understand the cause of the problem, and you may be likely to make the
same mistake in the future while designing web pages. What is needed
more is human understanding of what accessibility means.
A few previous research articles have noted the limitations of automated
tools, and have found that the most effective method for evaluating the
accessibility of a web page is to have a human expert examine the web
page using a screen reader, followed by a manual inspection of the code.
That sounds complex, but it doesn’t need to be. There are many
challenges to doing accessibility inspections. Government web
accessibility guidelines often don’t give specific guidance on how to
implement the guidelines and evaluate interfaces. Guidelines documents
from international standards organizations are thorough, but often so
detailed that they overwhelm people. Often, web developers don’t have
expertise or access to expertise in the area of accessibility. They do not
have time or money in their project to spend on accessibility. They do not
have access to users with disabilities. Well, this discount usability
approach does not require money, purchasing software, hiring experts, or
testing with users. Furthermore, it increases human understanding of
accessibility, which is important for decreasing accessibility violations in
the future.
Let me be clear-using these guidelines will not ensure that your entire web
site is accessible over time. This is a discount usability approach to doing a
point-in-time evaluation of web page accessibility. Finding where the
problems exist does not translate into those problems being fixed. Even
making a web page accessible doesn’t mean that it will stay accessible
over time, and user-centered design methods, involving actual users with
disabilities, are needed. This method isn’t 100% perfect and may not find
every single accessibility flaw. Multiple experts doing through reviews may
be more effective. But we need to stop focusing on being perfect, and
instead focus on getting better.
The reality is that a majority of web sites have accessibility problems, most
people don’t understand how to evaluate a web page for accessibility, and
a full code inspection sounds too challenging. So, we don’t need a perfect
solution, instead, we need an easy to understand method for guiding
people through accessibility evaluation. We need to lower the entry costs
to doing an accessibility evaluation, and make it so that we increase the
human knowledge on accessibility, by having developers and others
involved in web design use the same techniques as users with
impairments, to understand WHY a specific accessibility violation causes a
problem. Really, “it violates a regulation” isn’t the reason to make a web
site accessible. You need to understand why the regulation was created,
by understanding what the root accessibility problem is.
Note that this approach, as listed in the document, is based on current US
Federal Law and Maryland State Law, both of which use the same
technical standards. It is important to note that the current Section 508 (as
of 2015), uses technical standards that are based on the original WCAG
1.0 from 1999. There is a newer set of international technical standards,
WCAG 2.0, but it hasn’t been adopted yet by the Federal Government as a
part of their “508 Refresh.” It is expected, sometime soon, that Section 508
(and the Maryland equivalent), will be upgraded to WCAG 2.0, at which
point, this document will need to change. Generally, the WCAG 2.0
guidelines are an upgraded version of WCAG 1.0, but address the same
types of issues.
Methodology
The methodology for this accessibility evaluation requires 3 major steps:
listening to a web page with a screen reader, navigating through the web
page using typical blind user strategies, and inspecting the code manually.
A screen reader is a software program used by blind individuals, which
provides computer-synthesized speech output of what appears on the
screen and in the back end code. The major screen reader applications
are JAWS, Window-Eyes, VoiceOver, and NVDA.
Why do blind users seem to always get more attention in the accessibility
evaluation process? Because they face the most challenges on web sites.
Because web sites are still designed to be primarily visual, without regard
to user diversity or flexibility. Furthermore, when you approach a web page
from the point of view of the blind user (who typically cannot use a pointing
device), you also understand issues for people with motor impairments
who may not use pointing devices, and may do input either keyboard-only
(like blind users), or using an alternative keyboard or speech recognition.
Regardless, users with many different types of disabilities are keyboardonly and cannot use pointing devices.
STEP 1—LISTEN TO THE WEB PAGE
The first step is to listen to a web page using a screen reader. Note that
the typical blind person will not just listen to the screen reader run through
the entire web page, but will instead use a different approach to actively
look for the information that they want. But for the accessibility evaluation,
you should listen to the screen reader read through the entire web page.
Make sure to set the voice speed on JAWS relatively slow. You will be
taking notes on what you hear, so you may need a bit more time. Don’t
worry about the web accessibility guidelines at this point. Just listen to the
screen reader and take good notes.
As you listen to the web page, try and pay close attention to what you
hear, and also, leave the screen on so that you can visually follow what
you are hearing (typically, experts tell you to turn off the screen, but please
do not do that). Are all of the phrases that you hear logical? Do you hear
any links that are just garbage or long strings of numbers? Do you hear
any links or images that are actually files names which do not represent
anything useful (like left58.jpg)? Do you hear link names which are
repetitive and meaningless (such as click here, click here, click here)? If
you were listening to the web page, could you logically understand what
each link and picture represented? Now, as you are watching the screen
while listening, do you see any pieces of content, links, or which appear on
the screen, but you did not hear from the screen reader? That’s a common
problem. Were there any pop-up boxes which disrupted the flow of the
screen reader? Does the page include links to any files in other formats
(such as MS-Word, PDF, or anything else?) Take notes on anything you
hear that doesn’t seem right, so that you can follow up later during your
code inspection.
STEP 2—USE COMMON BLIND USER SEARCHING STRATEGIES
After first listening to the web page, next, you want to interact with the web
page in the same methods as a blind user. As previously stated, most blind
users don’t just let the screen reader read through the entire web page.
Most blind users utilize a goal-directed approach to find the content that
they want on a page. The three most common approaches are:
1. Using the links list (INS-F7 on JAWS)
2. Exploring the headers on the page
3. Using the “find” feature to find the specific word that they are looking for.
So, next, you need to examine the web page using all three of these
methods. First, bring up the links list. Look at the wording of all of the links.
Do all of the link names represent something meaningful? Are there any of
the aforementioned file names, “click here” or other meaningless wording?
Can you understand what each link might represent? Note any problems.
Second, examine the web page by navigating through the headers. In
JAWS, you would use the “H” key to navigate through the different
headings. It’s important for your purposes to determine if there are
headings present, and if so, do the headings make sense? Would they
help you navigate if you heard those headings?
Third, search for a few key words on the page and make sure that you can
access them using the find feature. A problem you might run into is if text
appears in graphical format, without any textual equivalent, so that you
cannot access the text using the find feature. Take a careful look at any
portions of the web page where content looks like it comes from another
source or is updated regularly. Can the screen reader access that content
using a keyword search? Try doing a few keyword searches.
After you have completed both listening to the web page and using blind
user searching strategies, you should have a detailed set of notes on what
you found, on what didn’t seem right, or on what might be questionable.
You should use those notes as a basis for the next step, the code
inspection.
STEP 3-CODE INSPECTION
Let’s face it—very few people hear “code inspection” and are happy. Nontechnical people say that they can’t do a code inspection. Technical people
can do a code inspection, but do not like the detail and time involved. This
is a quick approach to code inspection, using both the guidelines from the
U.S. Federal Government, and the notes that you took in the previous two
steps. Keep those notes in mind as you check the web page for
compliance with each paragraph. And realize that, due to the nature of this
shortcut approach, you may not identify every single accessibility violation.
Make sure that you have a copy of the U.S. Federal Guidelines, known as
Section 508, handy when you reach this step. Note: you aren’t required to
use U.S. Federal guidelines, it’s just that an explanation for each guideline
and how to check for it, is necessary, so you could use other accessibility
guidelines if they are very similar. Note that a code inspection doesn’t
mean that you must go through a web page and read every single line of
code. Often, the best way to do a code inspection is to identify the relevant
HTML tag, and then use the “find” feature to find where in the code there is
an instance of that tag. I repeat: don’t read through the entire code. Use
the find feature to find the HTML tags that are relevant to the specific
accessibility violation that you are investigating. Here is a list of the current
regulations for web sites from Section 508, and a common-sense
description of how to check for violations. Keep your notes from STEP 1
and STEP 2 in mind as you check for violations of each of these
guidelines. Often, when you hear things that just “don’t sound right,” you
can identify the actual cause of the problem during the code inspection,
using your experience from previous steps.
Regulation
from Section
508, 1194.22
Paragraph AAlt text
Paragraph BMultimedia
Paragraph CColor
Common-sense description for how to determine if
there is a violation
- Follow up and check on any misleading or missing alt
text from steps 1 and 2
- Do searches on all tags and make sure that you
have alt text (unless the is for something without
any content, like spacing)
Does the page have any audio or video? If so, make
sure that there is captioning for video with a soundtrack,
textual descriptions for video without a soundtrack, and a
transcripts for audio
Are there any parts of the web page where a change in
text color signifies something (for instance, form fields
that are required), aside from the fact that text is a
hyperlink? Would the page cause problems if you were
viewing it in black and white? Is there enough color
contrast between text and background (use a tool like
http://colorfilter.wickline.org/) if you can’t easily determine
Paragraph DStyle Sheets
Paragraph E
and F-Server
Side Image
Maps
Paragraph G
and H-Tables
Paragraph IFrames
People with disabilities often apply their own cascading
style sheet (CSS) to a web page. See what the web
page looks like when the CSS is disabled. It’s easy to
change the web browser settings to disable style sheets.
Make sure that the content still makes sense. It doesn’t
have to be the same or look perfect, it just must be
readable.
Does the page have clickable image maps (where you
click on a different portion of a graphic to either access a
different link or to access content?) If there are no
clickable image maps, move on to the next guideline. If
there are clickable image maps, see if there is a way to
access the content (or the links) using only the
keyboard. If so, it’s accessible. If not, it’s a problem.
Look at the web page. Do you see any data tables? Do a
keyword search for the HTML tag. If tables are
used, but only for presenting layout, move on to the next
paragraph. If there are tables used for presenting data,
make sure that there is a lot of markup, using techniques
such as the for a labeling each column in the top
row of the table, a summary using the
attribute, to give the table a title, and the
attribute to describe the location of each
cell in the table. Accessible tables are a complex topic.
When in doubt, listen to the table using a screen reader
and see if it makes any sense. For more information on
accessible tables, go to:
http://jimthatcher.com/webcourse9.htm
Do a keyword search and see if there are any
or tags in the code. If there are no frames,
move onto the next paragraph. If there are frames,
determine if the tags have meaningful titles.
TITLE=”left, top, or bottom” would be meaningless and
inaccessible. Title=”maincontent, navigation, or search”
would be useful. And make sure that there are
tags if you use frames.
Paragraph Jblinking and
flashing
Paragraph KText-only
page
Paragraph LScripting
Languages
Look at the web page. Does the web page have any
flashing or blinking text or images? Is there scrolling text
or anything which might make someone dizzy or have an
epileptic seizure? If there is anything blinking or flashing
which potentially could be a problem, you can use a tool
like http://tools.webaccessibile.org/test/check.aspx to
check it.
This paragraph allows that, if you cannot make the web
page accessible, that you can have a link to a text-only
page, and that will then qualify as accessible. If there’s a
link to a text-only page, as long as the content is up-todate, that’s considered to be accessible, but it’s pretty
rare nowadays that organizations do that, as it’s not
encouraged. So this paragraph is rarely “violated.”
This is the most challenging paragraph to evaluate.
Scripting comes in many different forms, including
JavaScript, Ajax, and Active X. To do a thorough
complete review, you need to be familiar with any
scripting languages used. For instance, you could do a
keyword search for , and see if there are
equivalent event handlers for keyboard use. That
means, for example, for every mouse-related Javascript
event handler (such as onMouseOver), you need to
have an equivalent keyboard event handler (such as
onFocus). Note that this would probably not identify
every single usage of scripting, and furthermore, you
should only be interested in scripting that relates to
actual content. A purely decorative mouseover, where
an object changes color when you roll the mouse over it,
but there is no actual content provided by the event
handler, is not an accessibility problem. You should be
concerned by event handlers that provide content (for
instance, rolling over a section of seats in a map of the
symphony hall, and the price of those seats appears),
not decorative ones.
Another way to approach this is to look through the web
page visually, looking for any portions of the web page
where either 1) content is automatically being updated
and changing, or 2) where the content being displayed
changes based on user actions (such as moving the
mouse over an object). Once you identify those areas,
Paragraph MApplets and
plug-ins
Paragraph NForms
Paragraph OSkip
Navigation
Paragraph PTimed
response
then you should attempt to access the same content
using your screen reader, and only using your keyboard
, and see if you can access the same content.
If the page provides any content using either an applet
or a plug-in (such as Adobe Acrobat, MS-Word or MSExcel), is the plug-in accessible, and does the page
include a link to download the plug-in? Often, having a
link, on the page, to an accessible version of the plug-in
is what is forgotten
Do a keyword search in the code on and then
determine if all of the form labels make sense. Are they
called “form1, form2, form3” or something meaningless,
or are they called names such as “first name, last name,
mobile phone number, etc.”
When you listened to the top of the web page, is there a
link called something like “skip to main content” or “skip
navigation” so that users can follow that link and start at
the main content of the page, rather than having to listen
to all of the navigation first? Technically, this is easy, but
many site designers forget about this.
Are there any tasks on the page with a time limit? Any
user actions with a limited amount of time? This often
occurs with a login or entry of sensitive or securityrelated data. If there are any tasks with a time limit,
make sure that the user has the option to request more
time
It’s important to note, that there is one very important component of
accessibility that is not really addressed in the current version of the
federal guidelines. PDF files (viewed with Adobe Acrobat reader) are often
a problem for accessibility. It’s not that PDF files are inherently
inaccessible, it’s just that there are multiple ways to create a PDF file, and
some of these approaches are inaccessible. In addition, after you have
turned a source data file (such as an MS-Word file) into PDF, you may
need to add a small amount of additional markup. Try taking a PDF file and
listening to it using a screen reader. There are also features in Adobe
Acrobat (the full version, not just the Acrobat Reader) that will check for
accessibility. For more information, go to
http://www.adobe.com/accessibility/products/acrobat/. The accessibility of
Adobe Acrobat files is a surprisingly large problem. It’s not a technically
challenging problem to solve, it’s just that not enough people pay attention
to it.
SUMMARY OF OVERALL ACCESSIBILITY
There you go—you have completed an accessibility evaluation of a web
page. What you need to do is immediately make a list of which paragraphs
of Section 508 were violated, and where. It’s not enough to just say that
there was a violation. You should note the specific content, the specific
location on the screen, or location within the code, where you found a
violation. There’s an ongoing debate about which is a more important
statistic—the number of actual violations, or the number of guidelines that
were violated. If there were 10 violations of paragraph A (alt text), that will
take some time to solve, but at the same time, if there were 10 different
paragraphs violated, with one instance in each paragraph, that will likely
take even more time. The important thing is that you used the same tools
that a blind user would use. You didn’t just have an automated tool inspect
the code for you, but you gained a greater understanding of the causes of
accessibility problems. You were able to incorporate a web accessibility
inspection into your day, without additional budget, or without hiring
experts. Did you find every single accessibility problem? Probably not. But
that’s OK. Is this as good as having accessibility experts evaluate the web
page, or having actual users with disabilities evaluate the web page? Of
course not. But we need to get beyond that fact. Often, developers decide
that they don’t have the resources or time to do a thorough, proper web
accessibility evaluation. It’s not an all-or-nothing proposition. There are lots
of things that you can do, without hiring experts, and without purchasing
tools, to help understand and evaluate a web page for accessibility.
NAME OF SITE:
Your name:
Screen reader/version used:
Paragraph
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
Time completed:
Date completed:
Violation (Y/N)
Browser used:Chrome
# of violations?
Comments/locations of
violations