Barrier Walkthrough
Heuristic evaluation guided by accessibility barriers.
$Revision: 1.7 $ $Date: 2009/03/31 18:00:24 $
The purpose of this method is to fill a gap concerning evaluation
of web accessibility. In fact, the most often used method is the
standards review (or conformance testing) coupled with WCAG
1.0/2.0 guidelines or Section 508 requirements (or other similar
principles). On the other side there are methods that are used less
often, like user testing. Both methods can be used for assessing
accessibility levels, but there are shortcomings in both cases.
Conformance testing is difficult to apply correctly as it is based
on general and abstract principles that are often difficult to
specialize in order to make them relevant and operational.
On the other hand, user testing requires more effort and
capabilities to do it right (it requires more skills, it is not easy
to recruit users that belong to appropriate user categories for the
website being tested or have the appropriate experience level in
using the required assistive technology or in using the PC and Internet;
it is more complex to set up the environment for the test execution,
etc.). In addition, the most frequent problems arising from this kind
of tests are usability defects of the website, rather than
accessibility ones.
Subjective assessments are much less demanding but also less
effective, as they are bound to yield only user opinions (rather than
observations on users behavior), very fragmented and unsystematic
(since test participants explored the areas of the websites that most
suited them, rather than those suiting the experimenters).
For more details see the paper Web
Accessibility testing: When the method is the culprit; and Beyond
Conformance: the role of Accessibility Evaluation Methods for a wider
discussion on evaluation methods.
The method that is described in this page is an adaptation of the
heuristic walkthrough method used for usability investigations where
the principles are replaced by barriers. The basic underlying
idea is that, for testing and assessment purposes, it is better to
start from known types of problems rather than using general
design guidelines. (This is the same approach you would
follow when assessing security of a web site: you'll start from known
vulnerabilities.)
A barrier is any condition that hinders the user's
progress towards achievement of a goal, when the user is a disabled
person. A barrier is described in terms of:
- the category of user and the type of disability
- the type of assistive technology being used
- the failure mode, that is the activity/task that is hindered
and how it is hindered, and
- which features in the page raise the barrier.
Barriers included in this page derive from an interpretation of known
accessibility principles and guidelines in the context of generic
scenarios.
Application of the BW method requires:
- to define the relevant user categories
- to define the relevant goals, and hence the relevant pages to
be tested and the relevant scenarios to be considered
- to cross check relevant barriers with the selected pages,
and
- to
determine the severity of each barrier.
In order to apply the method the following user categories could
be considered:
- Blind persons
Users of screen readers or of speaking browsers; sometimes users
also of Braille readers.
This category could also include users that can see, but who
have to use some disabling technology: browsers that don't display
images, voice portals.
- Low-vision users
Low-vision users of screen magnifiers; sometimes they only use
the accessibility features offered by the operating system, like
reducing screen resolution, increasing font-size, contrast levels and
color polarity.
Such a category could also include users of disabling
technology, like smart phones and PDAs with reduced screen and reduced
interaction facilities.
- Deaf users
Persons that cannot hear or with significantly reduced hearing
abilities.
Such a category could also include users that have to use a
website in a context where the audio is not available or possible
(like when in library or during a conference or lecture).
- Color-blind users
Persons that cannot distinguish certain colors.
Such a category could also include users of devices that change
or reduce the gamut of colors, for example gray-scale screens.
- Motor impaired users
Persons that have no complete control of their upper body, arms
and/or hands.
Such a category could also include persons that are temporarily
disabled (e.g. with a broken arm) or persons that have to use a
website in unusual postures (e.g. standing while giving a lecture).
- Cognitive disabilities
Persons with limited ability to process and memorize
information, to take decisions or to learn; these include learning
disabilities (affected by dyslexia and dysgraphia), attention
disorders, developmental disorders (Down's syndrome, autism) or
neurological disorders (Alzheimer).
Such a category could also include people that have to use a
website under stress conditions (e.g. in a hurry, in a noisy and
distracting environment, while carrying out some other important
task).
In addition, foreign language users of the website tend to face
similar barriers.
- Users of browsers where JavaScript is disabled
Users of browsers that cannot process JavaScript
instructions. For example, microbrowsers within cellular phones or
PDAs; users of proxy systems, transcoders, gateways that for some
reason (including security) prevent them from using JavaScript.
Also artificial agents, like search engine spiders or automated
testing tools, cannot process JavaScript code.
- Users with Photosensitive Epilepsy
Users of browsers that have an epilepsy that is
photosensitive for whom seizures are triggered by
flickering or flashing light. Only 5 percent of the persons with
epilepsy may have photosensitive epilepsy.
More details can be read on www.epilepsy.org.uk.
- Search engines
Obviously, these are very different users! In many cases though,
spiders of search engines face the same kinds of barriers that are faced
by humans.
Of course, for more specific analysis, additional user categories
could be included, like for example users of small mobile devices or
seniors. In addition, to support more precise investigations,
additional information could be included for considered user
categories, like the level of experience that a user is assumed to
possess with respect to the Internet, the assistive technology, the
domain of activity, and the particular website being tested. The
definition of personas (one or more per user category) is
particularly useful.
A second important ingredient of the usage scenarios to be
considered when applying this method is the set of
goals that users want to achieve when using the
site.
User goals with respect to a web application
are generally listed in the use cases upon which the
application has been built. For each use case there will be one or a few
possible tasks (i.e. different ways to achieve that goal), and each
task will span a certain set of pages (or user interface windows).
User goals for information websites (where
browsing is the predominant activity) are more difficult to
characterize. The problem is that there are many possible user
goals, one for each possible information need that can be fulfilled by
the website. In addition each goal is generally achievable through
many possible tasks (all the possible paths that users can follow to
reach the pages that contain the required information).
I suggest to select some of them using these criteria: the most
frequently sought information or the most valuable information provided for that kind of user. Once these
relevant goals are selected, then you need to select
some of the tasks (i.e. paths) that users can follow to achieve
them. Again adopt criteria like: the shortest route, the route that
requires less knowledge to be followed, the route that overlaps with
already known routes. At this point you have implicitly selected also
the set of pages to be evaluated.
Finally define the relevant scenarios, that is, the relevant user
goals, relevant pages, and possibly the personas involved.
The following lists of types of barriers are examples of the
barriers that should be included in an investigation, grouped by type
of users. The lists are aimed to capture the most frequently
encountered barriers, and while being quite large, they may not be
exhaustive. Feel free to email me further suggestions.
For each barrier, relevant accessibility checkpoints (WCAG 1.0)
are listed for additional information on its causes.
List of barriers for blind persons
User category: Users of screen readers or of speaking browsers; sometimes users
also of Braille readers. This category could also include users that can see, but who
have to use some disabling technology: browsers that don't display
images, voice portals.
- Rich images lacking equivalent text
- Video with no captions
- Color is necessary
- Inaccessible frames
- Moving content
- Image maps with no text
- Functional images embedded in the background
- Functional images lacking text
- Generic links
- Ambiguous links
- Dynamic menus in JavaScript
- Mouse events
- Opaque objects
- keyboard traps
- ASCII art
- Spaced titles
- Too many links
- Form with redirect
- Non separated links
- New windows
- Forms with no LABEL tags
- Forms that are badly linearized
- Too short timings
- Data tables with no structural relationships
- Data tables with no summary
- Layout tables
- Page without titles
- Frame without title
- Language markup
- No page headings
- Images used as titles
- No keyboard shortcuts
- Skip links not implemented
- Text-only page
- Window without browser controls
- Dynamic changes
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1 1.1.1
- Italian law:
3
- Cause:
The page contains some image that provides information (e.g. a
diagram, histogram, picture, drawing, graph) but only in a
graphical format; no equivalent textual description appears in
the page.
- Failure mode:
The user, even if s/he perceives that there is an important
image, has no way to get the information it contains. In
addition s/he spends time and effort trying to find out where in
the page or site that information is buried.
- Effect:
The user cannot use the information conveyed by the
image. Significant reduction of effectiveness; also user
productivity can be reduced.
- Fix:
Add an equivalent textual description to the image: by using
the ALT attribute of IMG, and if not sufficient by using the
OBJECT tag and specifying the text in the content of the
tag. Should this still be insufficient, then add a link in the
vicinity of the image that leads to a specific page where the
textual description is present.
Another strategy is to place the equivalent text close to the
image so that it can be seen also by those who can see the image.
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
1.1, 1.4
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.7, 1.2.8, 1.2.9
- Italian law:
3,18
- Cause:
A multimedia file with a video or an animation that has no
textual description of the scenes.
- Failure mode:
The user has no way to perceive the
content of the video frames except by listening to the audio.
- Effect:
Reduction of effectiveness.
- Fix:
Enrich the multimedia file with textual descriptions that are
synchronized with video frames. Link each video scene with
captions that textually describe the relevant events that are
happening in the video (for example, a closeup on the naked and
silent feet of the killer that approaches the designated victim
from behind). Languages like SMIL have to be used in order
that assistive technology and browsers get to know about the
availability of such a text; in addition they can synchronize
the different channels (visual, textual, audio).
Alternatively, or in addition to, provide also
audio descriptions (i.e. clips) that are synchronized with the
video and are compatible with the existing audio tracks; these
clips should supply additional descriptions of the video (for
example, as a narrating voice in the background).
Consider also adding to the video a track with a sign
language interpreter for the benefit of people with hearing
disabilities.
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
2.1
- Wcag 2.0:
1.4: 1.4.1
- Italian law:
4
- Cause:
The page contains material (text, images, background, videos)
where color is used as the sole mean to distinguish two or more
different information items. For example, raws in a table
providing balance figures, when black figures are positive
amounts and red ones are negative amounts.
Another common negative example is the use of color alone to
distinguish between followed and unfollowed links.
- Failure mode:
The user would have no way to perceive any
difference between the information items.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Use redundant means to distinguish between two
information items. Use typographic conventions that are based
not only on colors, but have in addition an audio effect when read
aloud. For example, use additional words or symbols; don't rely
only on a typographical effect like bold-face or italics style.
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
12.1 12.2
- Italian law:
2
- Cause:
The page is based on frames.
- Failure mode:
Users of old versions of screen readers (for example JAWS
v. 3.5) would not be able to access to any of the frames that the
page is based on.
- Effect:
Effectiveness drops to zero.
- Fix:
Remove all the frames from the page, possibly by using DIVs
and appropriate CSS rules to simulate the positive effects of frames.
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
7.3
- Wcag 2.0:
2.2, 2.2.2
- Italian law:
5
- Cause:
Images or text that moves (for example running text, animated
GIF).
- Failure mode:
The user cannot perceive that the content has changed (for
example because the screen reader does not notify it to the
user) since the last time that she/he heard it.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid using moving content, and always give the user the
flexibility to decide when to move on.
- Users:
Blind persons
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1, 1.1.1
- Italian law:
3
- Cause:
The page contains (client side) image maps whose areas
that have no ALT
attribute.
- Failure mode:
The user would be unable to understand what the different
regions mean, and would have no way to select the desired
one.
- Effect:
Reduction of effectiveness.
- Fix:
Add a textual description of the destination of each
clickable region.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
1.1
- Wcag 2.0:
1.3, 1.1, 1.3.1, 1.1.1
- Italian law:
3
- Cause:
The page background contains images that have a functional
role. For example they are positioned in a way that they
correspond to clickable areas, to buttons, or to labels of form
controls or of categories of items.
- Failure mode:
The user has no way to determine whether there is any content
associated to the image, especially if it contains text. In fact
it is not possible to use the normal techniques to associate
equivalent text to the image. The only way to use the image is
to overlap it with the rest of the page content.
- Effect:
Significant reduction of effectiveness, since the
user has to follow a trial and error approach in order to find the
possible buttons, links or form controls.
- Fix:
To fix this problem remove all the images from the
background, and include them in the HTML code of the page. Then
use the CSS to obtain the desired graphical effect.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
1.1, 3.1
- Wcag 2.0:
1.1, 1.1.1, 1.4, 1.4.5
- Italian law:
3
- Cause:
The page contains functional images (clickable links, form
buttons, image maps) that don't have alternative equivalent
text. Similarly for Flash buttons and links.
- Failure mode:
The user cannot understand the role of the image (for example
the screen reader reads aloud only the URL of the link) and
therefore the user would not be able to select the proper link
or button.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Include the attribute ALT for the images and the image maps
AREAs; include a textual content for the OBJECTs. Write the text
so that it is informative and that it allows the user to
understand the effects of activating the link.
Consider
doing this also for advertising banners.
Avoid using the
empty ALT (i.e. ALT="") for clickable images (i.e. included
within an A) because they can be reached with the keyboard, and
in such a case the browser does not give any information to the
user who wonders why tabbing brought her/him there.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
13.1
- Wcag 2.0:
2.4, 2.4.4, 2.4.9
- Italian law:
19
- Cause:
The page contains links with anchor text that is not
informative as it does not provide clues (for example, "click
here" or "More").
- Failure mode:
The screen reader user has no way to select such links when
they are shown out of context, in a dialog window that contains
all the links of the page. This happens because the link label
(i.e. text anchor) is not informative enough (it has a poor
information scent).
- Effect:
Significant reduction of effectiveness.
- Fix:
Modify all the link labels so that they provide clues as to
which page will be opened. Do not use "click here", but rather
"details on product XYZ".
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
13.1
- Wcag 2.0:
2.4, 2.4.4, 2.4.9
- Italian law:
19
- Cause:
The page contains links with labels (anchor text) that are
ambiguous, because the same text is used to represent
several different URLs; for example "click here" or "buy" that
are repeated many times in the page.
- Failure mode:
The screen reader user has no way to select a link when it is
shown out of context, i.e. in a dialog window that contains all and
only the links of the page. This occurs because there are many
links that share the same identical label.
The user has to explore each single link (by following it and
most often by backing up) before finding the desired page.
- Effect:
Reduction, even total lack, of effectiveness and productivity.
- Fix:
Modify the anchor text of links so that they are informative
and different from each other. Never use the same text for two
different links.
If this should not be possible, at least use the TITLE
attribute to add distinguishing text for different links.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 6.5, 8.1
- Wcag 2.0:
2.1, 2.1.1, 2.1.3, 4.1, 4.1.2
- Italian law:
17, 15
- Cause:
The page contains JavaScript code so that, as soon as the
user moves the focus of interaction onto an element, a menu
drops down in a given area of the page.
- Failure mode:
The screen reader cannot detect that the menu has
appeared, and it could fail to notify the user of such a
change. The result is that the menu cannot be used by the user.
- Effect:
Significant reduction of effectiveness.
- Fix:
All navigation options and commands (for example menu
entries) should be selectable also when JavaScript is not
enabled.
If needed, provide an alternative page with redundant links
and options; make sure that such a page can be reached from the
original one.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 9.3
- Wcag 2.0:
2.1, 2.1.1, 2.1.3
- Italian law:
16
- Cause:
The page is based on JavaScript in order to obtain specific
effects. JavaScript functions are invoked through event handlers
("onclick", "onmouseover", "onmouseout", ...) that are
mouse-oriented.
- Failure mode:
For people that use only the keyboard to interact (and no
mouse), those events never occur and therefore those JavaScript
functions are never invoked. Thus the interaction with the
page will differ significantly.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Use also logical event handlers ("onfocus", "onkeypress",
...) in addition to mouse-oriented ones.
It would be even better if the functionalities achieved
through event handlers could be achieved also without JavaScript.
- Users:
Blind persons
- Group:
Perception, Operability
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1, 1.1.1
- Cause:
The page contains components (eg. a Flash object) that is
totally opaque to screen readers (and other assistive
technologies). For example a menu that cannot be opened using
the keyboard, that cannot be read aloud by the screen reader,
etc.
- Failure mode:
There would be no way to use the object.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Make sure the object is accessible (for example, follow the
Flash guidelines ); or remove it.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 9.3
- Wcag 2.0:
2.1, 2.1.2
- Italian law:
16
- Cause:
The page contains components (eg. a Flash intro) that lock
the user once s/he moves the keyboard focus on them. For
example, it may happen that a user tabs into a Flash intro and
then cannot escape using the keyboard alone (that is, cannot
move the keyboard focus out of the object).
- Failure mode:
For people that use only the keyboard to interact (and no
mouse), a keyboard trap would be a very severe problem. The user
would need to reload the page to restart, and then would need to
remember when not to hit the tab key.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Provide a way to move the keyboard focus out of the
object. Sometimes (eg. Flash) this is achieved by a invoking a
"move to parent object" function.
Use also logical event handlers ("onfocus", "onkeypress",
...) in addition to mouse-oriented ones.
It would be even better if the functionalities achieved
through event handlers could be achieved also without JavaScript.
At the very least, warn the user about the trap before s/he
has chances to hit it.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
1.1, 13.10
- Wcag 2.0:
1.1,
- Italian law:
3
- Cause:
The page contains text that represents decorations rather
than words. For example, symbols like "==>" or smileys or
horizontal lines like "----------".
- Failure mode:
The user listens to the pronunciation of characters included
in the symbol and would probably do not understand its meaning.
For example, a user might not understand what an utterance
like "equals equals right angular parenthesis" might mean, which
is what a screen reader might pronounce when reading "==>".
However certain symbols are so commonly used that their
comprehension can be
taken for granted in general. For example the use of ">" as a
separator in a list of breadcrumbs links.
- Effect:
Reduction of productivity and satisfaction.
- Fix:
Remove symbols and decorations implemented through text. If
necessary replace them with appropriate images associated to an
equivalent ALT text.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
3.1
- Wcag 2.0:
1.4, 1.4.5, 1.4.9
- Cause:
The page contains words or terms that contain extra spaces,
like in "W E L C O M E", in order to achieve a certain visual effect.
- Failure mode:
The screen reader when reading "W E L C O M E" will utter the
following words: "doublew e el ce ou em e", making it impossible
to understand.
- Effect:
Reduction of effectiveness, of productivity and of satisfaction.
- Fix:
Use CSS rules to implement the same graphical effect.
- Users:
Blind persons
- Group:
Comprehension, user control
- Wcag 1.0:
12.3
- Wcag 2.0:
2.4, 2.4.10
- Cause:
The page contains too many links, that are perhaps not well
organized in clearly labeled groups.
- Failure mode:
A large number of links requires that users perform a
lengthy and exerting activity when listening to all of them before
deciding whether there is one that is worth following. While listening
users have to memorize them and be able to eventually
find them again once a decision is taken regarding which link to
follow.
If the links are badly organized and not grouped into meaningful
categories or have anchor text that is ambiguous or generic then
the problem is even worse.
- Effect:
Reduction, even total lack, of effectiveness and
productivity. Motivation to use the website is reduced too, and
navigation error chances increase.
- Fix:
Reduce the number of links in the page. If this is not
possible then organize them properly into groups. Implement the
groups with proper tags; for example use a list (UL/OL) rather
than including the links in a table. Separate different groups
with page headings (H2, H3, etc.) so that users can jump
directly to a page section. Spread the links into more
intermediate pages.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
7.5
- Cause:
The page contains a form where some controls, as soon as they
are used, cause a submit to the server which returns a new,
updated, page. This is achieved by using specific JavaScript event
handlers. AJAX is not considered here: this is not the normal
way it is used.
- Failure mode:
The major problem is that once an entry is selected, the
browser waits a couple of seconds, and then displays a new page
repositioning the focus of interaction to the
beginning of the page. The user therefore has to understand that
the browser is displaying essentially the same page as before
and then has to move the focus beyond the point where she/he
left it in the previous page. Only then can the user continue
with her/his task.
The problem is even worse if the page
lacks a proper organization, skip-links links, keyboard
shortcuts, and page headings.
- Effect:
Reduction, even total lack, of effectiveness and of productivity.
- Fix:
Avoid, whenever possible, the constant refresh caused by the
browser sending data back and forth to the server. If this is
not possible then implement a page-level navigation system that
supports users of keyboard and of screen readers. Namely, use
tags like H2-H6 and DIV to split the page contents into
manageable chunks, implement skip-links links to enable users to
jump directly to the page content, assign proper ACCESSKEY
attributes to form controls so that the focus can be moved
directly to them with a few keystrokes.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
10.5
- Cause:
The page contains a sequence of links (like navigation bars)
that are not separated by characters or symbols that can be read
aloud (even though they might be appropriately
separated by white space, for example).
- Failure mode:
The user has to listen to a list of links with no separation
or pause between them, and will face many difficulties in
understanding where one link ends and the next begins. The user
will not be able to detect which are the links that can be
activated and even when this can be done, the user will face
difficulties in activating the desired one.
- Effect:
Reduction of effectiveness.
- Fix:
Separate links with characters that can be pronounced (like
"|" or "-") or with images with a not null ALT; you can also end
the link text with a full stop (".") or a column (";"). In this way
the screen reader will be able to read the separator aloud or at
least make a pause.
Alternatively you can use an HTML list (UL) with appropriate
CSS rules so that the list is displayed in a single line with
no bullets.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
10.1
- Wcag 2.0:
3.2, 3.2.1, 3.2.5
- Italian law:
1
- Cause:
The page contains HTML or JavaScript code that opens new browser
windows either when the user activates links/buttons or, even
worse, after the page has been loaded.
- Failure mode:
The user does not realize that a new window is opened and
that the interaction context changed; and therefore that
both content and set of commands/controls have changed.
This is especially annoying when it happens out of the blue, in the
middle of a user task (typically this happens with popup windows
that are not relevant with the user task).
Also the BACK button of the browser (if available) does not
work anymore.
- Effect:
Reduction of effectiveness and productivity.
- Fix:
Avoid opening new windows in general, and provide some sort
of explanation of such behavior so that it can be read to the
user before the window is opened.
If this is really needed or is a de-facto standard (for example
when selecting a date from a JavaScript popup calendar window) then
make sure that at the very beginning of the new window there is
a link/button called "Close window" so that users understand
that this is a new window and the button gives them the immediate
opportunity to close it.
Don't forget to define an informative title for the page
displayed in the new window, like "Calendar: select the date".
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
10.2, 12.4
- Wcag 2.0:
2.4, 2.4.7, 1.3, 1.3.1
- Italian law:
14
- Cause:
The page contains a form whose controls are not marked up
with LABEL tag and FOR attribute.
- Failure mode:
The user of the screen reader in a "form controls" mode (
jumping directly between form controls) cannot use such a facility
because the form controls are lacking any connection to the
words that represent their labels. When the user moves the
interaction focus to a given control the screen reader might not
be able to locate the appropriate text that represents its
label, and the user will not get any description regarding the
meaning (and possibly syntax) of the data to enter for that control.
- Effect:
Significant reduction of effectiveness.
- Fix:
Always wrap the text (or image) representing the label of each
control with the LABEL tag and FOR attribute. When this is not
possible, use at least the TITLE attribute.
In this way, for controls like checkboxes and radiobuttons,
also the text of the label is clickable, increasing the
clickable area and improving users' productivity.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
5.3, 9.4, 10.3
- Wcag 2.0:
1.3, 1.3.2, 2.4, 2.4.3
- Italian law:
13
- Cause:
The page contains a form that is layed out using tables that
are not linearized properly; that is, when reading the contents
of the layout table in the order in which it is written in HTML,
it doesn't make any sense.
Consider for example a form layed out in two rows, where the
first row contains the labels of the fields and the second one
the text fields.
Note: this problem occurs also if the controls are properly
marked up with LABEL/@FOR.
- Failure mode:
The user might hear sequences of labels that are read one
after the other followed by a sequence of controls. The problem
is that the user will have no idea of the meaning of the
controls that are heard. Or, even worse, he or she might assume
that the first control being heard is related to the last label
being read, and will try to submit the wrong data.
By switching the screen reader to the "form controls" mode
the user will be able to regain control, provided that the form
is properly marked up with LABEL/@FOR.
- Effect:
Significant reduction of effectiveness.
- Fix:
If you use tables for layout then make sure that when you
drop the table markup the content is organized in a sequence
that makes sense.
- Users:
Blind persons
- Group:
Operability
- Wcag 1.0:
7.4, 7.5
- Wcag 2.0:
2.2, 2.2.1, 2.2.4, 3.2, 3.2.5
- Italian law:
20
- Cause:
The web page is automatically refreshed after a certain time
has elapsed (that is, its content is changed and/or a new page
is reloaded by the browser without the user asking for it).
- Failure mode:
Users of screen readers usually need more time than usual to
read the page and use it because the page content is spread over
time, rather than over space. He
or she will not be able to complete the task and achieve the
desired goal because the system has changed state.
In addition, even if the same page is being reloaded
automatically, the
browser will automatically reset the focus of the interaction to
the beginning of the page, forcing the user to move the focus
forward to the place that was reached before the reload event
took place.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid time-based actions that change the status of the page
if the user does not consciously initiate them.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
5.1, 5.2
- Wcag 2.0:
1.3, 1.3.1
- Italian law:
9, 10
- Cause:
The page contains data tables (e.g. bus schedules, calendars,
statistical data, lists of tabular data - where items within a
row are all related to a single entity) that are not properly
coded (using TH/@SCOPE/@ID, TD/@HEADERS).
- Failure mode:
The user is prevented from taking advantage of the "table
navigation mode"
offered by screen readers to jump between adjacent table cells
in any order (rather than having to follow the strict row-by-row
order). When moving to a cell the screen reader would not tell
the user what the headers of the cell are and how to interpret
the meaning of the cell data.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Use TH to distinguish cells that are headers from cells that
contain data (TD). Use attributes like TH/@SCOPE or TH/@ID plus
TD/@HEADERS to specify structural relationships between data
cells and their corresponding header cells.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
5.5, 5.6
- Italian law:
9
- Cause:
The page contains data tables (e.g. bus schedules, calendars,
statistical data, lists of tabular data - where items within a
row are all related to a single entity) that don't have proper
SUMMARY attribute and/or CAPTION tag.
- Failure mode:
The user has to explore and understand most of the content of
the table to figure out if the table is relevant to her/his
needs.
- Effect:
Significant reduction of productivity.
- Fix:
Use the TABLE/@SUMMARY attribute to describe in clear and
concise text what the table is about (the SUMMARY attribute will
not be displayed by the browser). Use the TABLE/CAPTION
tag to specify the caption associated with the table (the CAPTION
element will be displayed by the browser - and it can be
controlled via CSS rules).
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
3.3,5.3, 5.4
- Wcag 2.0:
1.3, 1.3.1, 1.3.2
- Italian law:
13
- Cause:
The page layout is based on tables that cannot be properly
linearized (that is, their content when read row by row, does
not make sense).
Sometimes the layout table contains also the SUMMARY
attribute and the markup needed for data tables (TH/@SCOPE,
TD/@HEADERS).
- Failure mode:
The user does not understand the information and links that
are positioned in the page using the layout table, since the
order in which they are read does not make sense. This usually
happens when the visual order implemented through visual cues
(white space, lines or boxes) differs from the linearization
order.
Furthermore, for each table, the screen reader reads aloud
sentences like "table 4 with 5 rows and 8 columns" which, for
layout tables, not only gives zero information to users, but
slows them down.
Even worse if the table contains markup like TH, HEADERS,
etc. since the screen reader reads even more useless
words. Consider also that giving spacial indications to users
regarding what and where it is located in the page is not
useful, as it offers no direct way to get to those
locations.
- Effect:
Reduction of effectiveness and of productivity.
- Fix:
Get rid of layout tables and use CSS2 properties for
positioning elements in the graphical view of the page.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
13.2
- Wcag 2.0:
2.4, 2.4.2
- Cause:
The page lacks a TITLE tag, or its content provides no
information (like "Untitled document") or it is the same for all
the pages of the website.
- Failure mode:
Every time a user goes to a new page, the page title (which
is shown on the title bar of the browser window) is the first
thing that the screen reader reads. If the title provides no
information or does not change when pages are changed, it gives the
wrong hint to the user who might not understand that the page
has changed at all.
- Effect:
Reduction of effectiveness.
- Fix:
Always write page titles that are unique and informative for
the page.
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
12.1
- Wcag 2.0:
2.4, 2.4.1, 4.1.2
- Italian law:
2
- Cause:
The page contains a frame (FRAME tag within a FRAMESET) has
no TITLE attribute; or the value of TITLE is the same as the
value of NAME.
- Failure mode:
The user can only access the content of the page one frame at the
time, and must explicitly choose the frame she/he
intends to visit. If
the NAME attribute of the frame contains values like "top",
"left" or "f2", the user will get no clues as to which frame
contains what.
- Effect:
Reduction of effectiveness.
- Fix:
Always add the TITLE attribute to every single frame.
Make sure that its value is comprehensible and informative,
allowing the user to select the frame that contains what she/he
needs.
Even better if frames aren't used at all. The
same effects can be achieved with CSS (even
clipping).
- Users:
Blind persons
- Group:
Comprehension
- Wcag 1.0:
4.1, 4.3
- Wcag 2.0:
3.1, 3.1.1, 3.1.2
- Cause:
The page has no attribute LANG in the HTML tag and/or any
time a word or phrase in a foreign language is included in the
text of the page.
- Failure mode:
The screen reader will pronounce those words with the
phonemes of the language that is set by the user. If the website
contains pages in multiple languages it is up to the user to
reset the language used by the screen reader, once he or she
detects that the language is not the one she/he has chosen.
Even worse, if the page contains phrases in different
languages. To get a correct pronunciation, the user will have to
set and reset the language for each occurrence of these
phrases. For example, in an Italian page the word "check in"
will be pronounced as "kek in", making them apparently sound funny but
annoying and even misleading.
- Effect:
Reduction of effectiveness.
- Fix:
Add the attribute LANG to the top-level HTML tag; use values
like "it", "en", "de".
In addition, any time there are words in a language other
than the main language of the page, use markup like "<span
lang="en">Check in<span/>".
- Users:
Blind persons
- Group:
Comprehension, user control
- Wcag 1.0:
3.5
- Wcag 2.0:
2.4, 2.4.10, 1.3.1
- Cause:
The page does not contain tags H1, H2, ..., H6 for organizing
its content into sections.
- Failure mode:
A screen reader allows the user to list all the section
headings and to jump from one to another. In this way the user
can quickly get an overview of the page content, and she/he can
skip unwanted content immediately and focus on relevant
items instead.
This is especially important when the user visits
unwanted pages; he or she will quickly understand that it is not
the desired page and move back.
Also in cases where most
of the pages share the same structure (like in a multi-stage
form process), the user will have the opportunity to jump
directly to the most interesting section.
- Effect:
Reduction of productivity and also of effectiveness.
- Fix:
For each type of content in the page (e.g. navigation bar,
breadcrumbs, sequence of paragraphs, boxed contents) add a new
heading. It can even be hidden using appropriate CSS rules.
Remember to respect their nesting levels: do not skip levels.
- Users:
Blind persons
- Group:
Comprehension, Perception
- Wcag 1.0:
3.1
- Wcag 2.0:
1.4, 1.4.5
- Cause:
The page contains titles of categories (e.g. a group of news,
a group of related links) that are implemented through images
that have no ALT text. This occurs for example when certain
items (for example, news) are grouped in a box, and the box is
given a title which is implemented through an image.
- Failure mode:
The screen reader would not be able to pronounce any
informative text (except for the URL of the image), and
therefore the user would not be able to take advantage of help in
terms of orientation and contextualization provided by the image.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid using images for titles of categories. Use CSS rules
to achieve the desired graphical effect on actual text titles.
If this cannot be done, then add the ALT attribute to the
images with the same text as the one painted in pixels within the
image.
- Users:
Blind persons
- Group:
User control
- Wcag 1.0:
9.5
- Cause:
The page has links/buttons/form controls that are repeated on
many other pages (like in a web application) and no
keyboard shortcut is defined with ACCESSKEY.
- Failure mode:
The user, who can use only the keyboard, cannot move quickly
through the interactive elements of the page (among
links/buttons/form controls). He or she has to use the TAB key
and move sequentially or switch the screen reader to the form
control mode and jump between form controls.
The problem is even worse if the page lacks "skip links",
links for jumping from section to section, or section headings.
- Effect:
Reduction of flexibility, and therefore of productivity and
satisfaction.
- Fix:
For the controls which are repeated on many pages and when,
from the users' perspective it is worthwhile to learn keyboard
shortcuts for such controls, add the attribute ACCESSKEY to A,
INPUT, BUTTON elements. Remember to avoid using keys that are
associated to menu labels of the browser (like "f" for file) or
numbers (Firefox uses them to jump from tab to tab). Be also
careful not to use characters that interfere with the way a
screen reader (or other assistive technology) works.
Remember to make sure that access keys are described in a
help page and that they are consistently associated with the
same controls.
- Users:
Blind persons
- Group:
User control
- Wcag 1.0:
13.6
- Wcag 2.0:
2.4, 2.4.1
- Italian law:
19
- Cause:
The page does not allow the user to jump directly to the
content, skipping over preliminary stuff,links like logos,
breadcrumbs, search boxes, global navigation bars).
- Failure mode:
The user is forced to listen the screen reader reading, for
every page that is being visited, the preliminary stuff, even
though the user is interested in the content of the page.
This is especially bad for web applications where there are
form controls that force a refresh of the page and a reset of
the interaction focus to the page (like a sequence
of SELECT elements, each one of them sending a request to the
server to get an update of the page).
- Effect:
Reduction of productivity, and sometimes of effectiveness.
- Fix:
Add, at the very beginning of the page, a link that would
allow the user to jump directly to the main content of the page.
Implement a link that is visible to everybody; if this is not
possible then implement the "skip-links" link in a hidden way,
by using "display: none" as a CSS rule or a clickable spacer
image whose ALT says "main content".
- Users:
Blind persons
- Group:
User control
- Wcag 1.0:
6.2 11.4
- Italian law:
22
- Cause:
The page contains a link that leads to a text-only page or a
low-graphics page.
However the text-only page contains less links, less
information or is not as updated as the original page.
- Failure mode:
The user cannot use those pages because they are less
reliable, less accurate, less complete than the graphical
counterparts.
- Effect:
Reduction of effectiveness and total drop of satisfaction.
- Fix:
Text-only pages may be a good thing, but they need to be well
implemented. They should present no accessibility barriers, they
should have the same content as their graphical counterparts,
and they should be easily reachable.
In this way, text-only pages are just another user interface
to access the website, in many cases supporting a faster and
more flexible interaction.
- Users:
Blind persons
- Group:
User control
- Wcag 1.0:
9.4, 9.5
- Cause:
The page has been opened within a new browser window but the
usual browser controls (address bar, back, next, refresh
buttons, ...) are missing.
- Failure mode:
The user has to scan the entire page in order to find links
or buttons to move back to previously visited pages.
Not even the page address can be changed as the address bar
is missing.
- Effect:
Reduction of effectiveness.
- Fix:
Never disable browser controls.
The only viable exception is when opening temporary popup
windows (with a prominent "close" button).
- Users:
Blind persons
- Group:
Perceivability
- Wcag 1.0:
6.3 8.1
- Wcag 2.0:
4.1, 4.1.2 3.3.1, 3.3.2, 3.3.3
- Italian law:
15
- Cause:
The page is part of a web application based on AJAX where
dynamic changes of the DOM occur. For example, notification
messages from the server are shown asynchronously
in a certain area of the page; this may occur without the user taking
any particular action, and without a page refresh.
- Failure mode:
If no audible cues are provided, the
user might not be aware that something in the page has changed,
leading to confusion, errors, several trials and errors.
Even in cases where the user may be aware of that, s/he might be unable
to move the focus of the screenreader on that area.
- Effect:
Reduction, possibly total, of effectiveness. High frustration,
low productivity.
- Fix:
The asynchronous (with respect to user actions) changes to the DOM
that AJAX permit are a problem for users of screenreaders and
screen magnifiers. For this problem there aren't many solutions,
other than building a separate user interface not based on AJAX,
built with plain HTML+CSS.
See the ARIA guidelines.
List of barriers for low-vision users
User category: Low-vision users of screen magnifiers; sometimes they only use
the accessibility features offered by the operating system, like
reducing screen resolution, increasing font-size, contrast levels and
color polarity. Such a category could also include users of disabling
technology, like smart phones and PDAs with reduced screen and reduced
interaction facilities.
- Rich images that are badly positioned
- Rich images included in the page background
- Color is necessary
- Insufficient visual contrast
- Inaccessible frames
- Moving content
- Image maps
- Functional images embedded in the background
- Functional images lacking text
- Too long tooltips
- Dynamic menus in JavaScript
- Internal links are missing
- Too long lines of text
- Too many links
- Form with redirect
- Widely formatted forms
- Overlapping windows
- Too short timings
- Images used as titles
- No keyboard shortcuts
- Text cannot be resized
- Inflexible page layout
- Missing layout cues
- Skip links not implemented
- Window without browser controls
- Sortable data table
- Dynamic changes
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
1.1, 6.1, 13.8,
- Wcag 2.0:
1.3, 1.3.1, 1.3.2
- Italian law:
11,12,14
- Cause:
The page layout is suboptimal because there are no graphical
cues that suggest that there is an important image.
- Failure mode:
The user cannot know that there is an
important image if this is located outside the field of vision
and perhaps in some remote corner of the page (e.g. top
right). This can happen also if the page is based on a graphical
layout that provides wrong cues (like horizontal or vertical
lines or drawings that can be interpreted as graphical margins
and suggesting the end of the page area. As a consequence the
image cannot be seen, and the information it conveys cannot be
utilized.
- Effect:
Reduction of effectiveness.
- Fix:
Change the page layout so that it does not
provide wrong visual cues.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
1.1, 6.1
- Italian law:
3,4,6
- Cause:
Images that convey information are included as
background (using CSS); hence there is no way to attach
any equivalent text to them.
- Failure mode:
These images cannot be perceived at all by
users since screen readers do not even signal the presence of
these images, let alone reading aloud any attached text.
- Effect:
Reduction of effectiveness.
- Fix:
Include images in the HTML of the page, using
tags like IMG or OBJECT. And specify appropriate values for the
attribute ALT (or for the content of the OBJECT tag). If needed
add also a link that leads to a page specifically aimed at
providing a rich description of the image content.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
2.1
- Wcag 2.0:
1.4: 1.4.1
- Italian law:
4
- Cause:
The page contains material (text, images, background, videos)
where color is used as the sole mean to distinguish two or more
different information items. For example, raws in a table
providing balance figures, when black figures are positive
amounts and red ones are negative amounts.
Another common negative example is the use of color alone to
distinguish between followed and unfollowed links.
- Failure mode:
A common problem for people with low-vision is the inability
to perceive colors as those with normal vision
capabilities. Such people would be unable to distinguish between
two information items.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Use redundant means to distinguish between two
information items. Use typographic conventions that are based
not only on colors, but have in addition an audio effect when read
aloud. For example, use additional words or symbols; don't rely
only on a typographical effect like bold-face or italics style.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
2.2
- Wcag 2.0:
1.4: 1.4.3, 1.4.6
- Italian law:
6
- Cause:
The page contains foreground material placed against a
background. The colors used to paint both of them have to little
contrast. The background can be a box with a solid color, based
on a gradient, with some texture or including a picture. The
foreground material can be text and/or images.
The
contrast can be based on differences in brightness or in
differences in the hues of the colors.
Sometimes the
problem arises only when the content of the page is rearranged;
for example because the text size has changed, or because the
window geometry has changed.
- Failure mode:
Users will have to make an effort to distinguish between
fore and background items, and in some cases will be totally
incapable of recognizing, and perhaps even detecting, the
foreground items.
This problem may occur also when the background is implemented
through an image and users disable CSS (for example, to get rid
of defects of the layout). Default colors used by the browser may result
having a small contrast level with the colors contained in the image,
leading to inability to distinguish certain information.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Remove any background image, or
change them so that they could never interfere with perception
and interpretation of the foreground content.
Additionally, an appropriate choice of colors that have a
high level of brightness contrast (this can be tested by viewing
the page in a gray-scale display) and a high level of hue
contrast will definitely solve this problem.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
12.1 12.2
- Italian law:
2
- Cause:
The page is based on frames.
- Failure mode:
The user might click on some link/button in one of the frames
of the page whose effect is shown into another frame, that might
be located outside the current field of vision of the user.
- Effect:
Reduction of productivity.
- Fix:
Remove all the frames from the page, possibly by using DIVs
and appropriate CSS rules to simulate the positive effects of frames.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
7.3
- Wcag 2.0:
2.2, 2.2.2
- Italian law:
5
- Cause:
Images or text that moves (for example running text, animated
GIF).
- Failure mode:
Moving content can be positioned in an area of the page that
is located outside the field of vision of the user, with the
consequence that its changes go totally unnoticed by the user.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid using moving content, and always give the user the
flexibility to decide when to move on.
- Users:
Low-vision users
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1, 1.1.1
- Italian law:
3
- Cause:
The page contains (client side) image maps, even with
appropriate alternative text.
- Failure mode:
The user would face difficulties in identifying the focus,
when it moves from area to area: the outline has often poor
color contrast or the area might be very small or the tab
sequence is not predictable by the user.
A related issue is the difficulty of identifying the target
of an area; for example, in a geographical map, one might not
know where to look for a given country, and if there is no
visible textual label then it would be difficult to find it.
In many cases turning images off does not help.
- Effect:
Reduction of effectiveness.
- Fix:
Add a visible textual description of the destination of each
clickable region and change the rendering style when the focus
is on a region.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
1.1
- Wcag 2.0:
1.3, 1.1, 1.3.1, 1.1.1
- Italian law:
3
- Cause:
The page background contains images that have a functional
role. For example they are positioned in a way that they
correspond to clickable areas, to buttons, or to labels of form
controls or of categories of items.
- Failure mode:
The user who tries to enlarge the text size, or to change the
width and height of the window of the browser, runs the risk of
rearranging the content of the page in a way that there is a
misalignment of the background elements with respect to the
foreground contents. The consequence is that the images are not
displayed in the context they were meant to.
Furthermore
the user might want to disable the page style sheets and use
her/his own. In such a case she/he would not be able to perceive
the content of the page at all.
- Fix:
To fix this problem remove all the images from the
background, and include them in the HTML code of the page. Then
use the CSS to obtain the desired graphical effect.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
1.1, 3.1
- Wcag 2.0:
1.1, 1.1.1, 1.4, 1.4.5
- Italian law:
3
- Cause:
The page contains functional images (clickable links, form
buttons, image maps) that don't have alternative equivalent
text. Similarly for Flash buttons and links.
- Failure mode:
The user would not be able to enlarge the images (if not
using a screen magnifier) and therefore she/he would not be able
to read them or to interpret them. Similarly, if the user wants
to replace the colors and styles of the page with her/his own,
she/he would not be able to do anything with the images.
- Fix:
Include the attribute ALT for the images and the image maps
AREAs; include a textual content for the OBJECTs. Write the text
so that it is informative and that it allows the user to
understand the effects of activating the link.
Consider
doing this also for advertising banners.
Avoid using the
empty ALT (i.e. ALT="") for clickable images (i.e. included
within an A) because they can be reached with the keyboard, and
in such a case the browser does not give any information to the
user who wonders why tabbing brought her/him there.
- Users:
Low-vision users
- Group:
Perception/operability
- Wcag 1.0:
-
- Wcag 2.0:
-
- Italian law:
-
- Cause:
The page contains links or images that are associated to tooltips
(shown when hovering with the mouse), whose text is relatively long.
The problem may occur when the TITLE attribute is associated
to links, images, DIVs or to any element on which a display:block CSS
rule is applied.
- Failure mode:
A user of a screen magnifier that adopts a large magnification level
(8x, 16x, 32x), when the tooltip activates, will be able to see only
the tooltip, which would cover most of the visible part of the page.
The user will be unable to get rid of the tooltip as the
underlying object will fill the viewport.
If the tooltip is associated to non-visible elements (eg. a DIV),
then there might be no apparent reason for it.
- Effect:
Reduction, even total lack, of effectiveness and productivity.
High frustration.
- Fix:
Modify the tooltip text and make it shorter.
Make sure that the tooltip is actually needed.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 6.5, 8.1
- Wcag 2.0:
2.1, 2.1.1, 2.1.3, 4.1, 4.1.2
- Italian law:
17, 15
- Cause:
The page contains JavaScript code so that, as soon as the
user moves the focus of interaction onto an element, a menu
drops down in a given area of the page.
- Failure mode:
The screen magnifier user could be seeing a section of the
page that is far from the area where the menu appears. The menu
therefore could easily be located outside the visual field of
the user, who won't be able to use it at all.
- Effect:
Significant reduction of effectiveness.
- Fix:
All navigation options and commands (for example menu
entries) should be selectable also when JavaScript is not
enabled.
If needed, provide an alternative page with redundant links
and options; make sure that such a page can be reached from the
original one.
- Users:
Low-vision users
- Group:
Operability, user control
- Cause:
The page, which is complex and full of contents that usually
cannot be used completely in a window without requiring
scrolling, does not have internal links that would allow the
user to jump from section to section, or to return to the beginning
of the page.
- Failure mode:
The user, in order to move up the content of the page, has to
constantly shift the field of vision from the page content area
to the scroll bar area. This is particularly taxing in those
cases where section headings are aligned to the left, and don't
get close to the scroll bar located on the right hand side of
the page.
If the page contains complex forms, the consequence is even
worse, as the user might not be aware of the existence of some
required field/control.
- Effect:
Reduction of effectiveness and of productivity.
- Fix:
Add navigation links to the end (or the beginning) of each
section (correctly marked up with tags like H2, H3 and similar
ones). They should lead to the beginning of the previous and
next sections, and to a table of contents of the page. You don't
need to add the links leading to the top of the page or to its
end, as this function is normally already fulfilled by the
"Home" and "End" keys.
- Users:
Low-vision users
- Group:
User control
- Cause:
The page contains text lines that are too long
for the user's field of vision.
- Failure mode:
Text lines longer than the width of the user's field of
vision require that the user constantly moves the enlarged area
of the screen from left to right, and then to the beginning of
the subsequent line of text. If the page requires horizontal
scrolling then the problem is even worse as the user has to
move the field of vision to the bottom of the page, drag the
cursor onto the horizontal scroll bar, and then go back to the
line that she/he was reading.
- Effect:
Reduction of productivity and most probably of effectiveness
as well.
- Fix:
The best way to avoid this problem is to implement a liquid
layout for the page so that the line length automatically adapts
to the width of the window. In this way users could enlarge the
text as much as needed, maximize the window size, and still be
able to read the page without having to struggle with extra
movements of the field of vision.
Furthermore no horizontal scrolling will be needed.
- Users:
Low-vision users
- Group:
Comprehension, user control
- Wcag 1.0:
12.3
- Wcag 2.0:
2.4, 2.4.10
- Cause:
The page contains too many links, that are perhaps not well
organized in clearly labeled groups.
- Failure mode:
The large number of links requires that users perform a
lengthy and exerting activity when scanning them all before
deciding if there is one that is worth following. During
scanning users have to memorize them and be able to eventually
find them again once a decision is taken regarding the link to
follow.
If the links are badly organized and not grouped
into meaningful categories, with anchor text that is ambiguous
or generic, then the problem is much worse.
And if the
page requires horizontal or vertical scrolling then it is even
worse.
- Effect:
Reduction of productivity, satisfaction and effectiveness.
- Fix:
Reduce the number of links in the page. If this is not
possible then organize them properly into groups. Implement the
groups with proper tags; for example use a list (UL/OL) rather
than including the links in a table. Separate different groups
with page headings (H2, H3, etc.) so that users can jump
directly to a page section. Spread the links into more
intermediate pages.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
7.5
- Cause:
The page contains a form where some controls, as soon as they
are used, cause a submit to the server which returns a new,
updated, page. This is achieved by using specific JavaScript event
handlers. AJAX is not considered here: this is not the normal
way it is used.
- Failure mode:
The major problem for the user is that once the user selects
an entry, the browser waits a couple of seconds, and then
displays a new page repositioning the focus of
interaction to the beginning of the page. The use therefore to
understand that the browser is displaying the same page as
before and then has to move the focus beyond the point where
she/he left in the previous page. Only then the user can
continue with her/his task.
The problem is even worse if the page lacks a proper
organization, skip-links links, keyboard shortcuts, and page headings.
- Effect:
Reduction, even total lack, of effectiveness and of
productivity.
- Fix:
Avoid, whenever possible, the constant refresh caused by the
browser sending data back and forth to the server. If this is
not possible then implement a page-level navigation system that
supports users of keyboard and of screen readers. Namely, use
tags like H2-H6 and DIV to split the page contents into
manageable chunks, implement skip-links links to enable users to
jump directly to the page content, assign proper ACCESSKEY
attributes to form controls so that the focus can be moved
directly to them with a few keystrokes.
- Users:
Low-vision users
- Group:
Operability
- Cause:
The page contains a form whose controls are spread on a wide
region of the page and they are arranged on more than one visual
column.
- Failure mode:
The user might not be able to detect that there are controls
located in peripheral areas of the page (like top-right or
bottom-right), and therefore might submit incomplete forms.
- Effect:
Reduction of effectiveness and productivity.
- Fix:
Layout the form with sufficient visual cues suggesting where
it ends (especially at right and at the bottom). Prefer a
one-column layout of labels and controls side by side.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
10.1
- Wcag 2.0:
3.2, 3.2.5, 3.2.5
- Italian law:
1
- Cause:
The page contains JavaScript or HTML code that
opens new windows that are overlapping with the window that is being
used and cover it completely/substantially.
- Failure mode:
The user does not distinguish the new window from the
previously used one, and therefore the new interaction context
(content, layout, links, buttons, form controls) can be very
confusing.
For example it can happen that the user does not understand
that the scroll bar that he or she sees is the one of the
background window. But when he or she clicks on that scroll bar
(with the intention of moving the content of the foreground
window) the result is that the two windows switch position, and
the content that the user was looking at and trying to move has
disappeared, covered by the other window that has been brought
to the foreground. The user might not have any clue as to what
has happened and why.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid opening new windows in general, and provide some sort
of explanation of such a behavior so that it will be read to the
user before the window is opened.
If this is really needed or is a de-facto standard (for example
when selecting a date from a JavaScript popup calendar window) then
make sure that at the very beginning of the new window there is
a link/button called "Close window" so that users understand
that this is a new window and the button gives them the immediate
opportunity to close it.
Avoid placing the new window in such a way that it overlaps
completely (or almost completely) with the main window.
- Users:
Low-vision users
- Group:
Operability
- Wcag 1.0:
7.4, 7.5
- Wcag 2.0:
2.2, 2.2.1, 2.2.4, 3.2, 3.2.5
- Italian law:
20
- Cause:
The web page is automatically refreshed after a certain time
has elapsed (that is, its content is changed and/or a new page
is reloaded by the browser without the user asking for it).
- Failure mode:
If the user needs more time to read the page and use it (for
example to read a license and press the "Accept" button) then he
or she will not be able to complete the task and achieve the
desired goal because the system has changed state.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid time-based actions that change the status of the page
if the user does not consciously initiate them.
- Users:
Low-vision users
- Group:
Comprehension, Perception
- Wcag 1.0:
3.1
- Wcag 2.0:
1.4, 1.4.5
- Cause:
The page contains titles of categories (e.g. a group of news,
a group of related links) that are implemented through images
that have no ALT text. This occurs for example when certain
items (for example, news) are grouped in a box, and the box is
given a title which is implemented through an image.
- Failure mode:
The user will not be able to use only the browser to utilize
the website. In fact the browser cannot be used to enlarge the
text painted in pixels within the images. Although the user
might be able to enlarge the text size (expanding therefore the
items contained in the box having that title), the title itself
will not change.
The user will be forced to use a screen magnifier, with the
consequence that her/his field of vision will be further reduced
and similarly for her/his control.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid using images for titles of categories. Use CSS rules
to achieve the desired graphical effect on actual text titles.
- Users:
Low-vision users
- Group:
User control
- Wcag 1.0:
9.5
- Cause:
The page has links/buttons/form controls that are repeated on
many other pages (like in a web application) and no
keyboard shortcut is defined with ACCESSKEY.
- Failure mode:
The user could use the access keys to quickly and accurately
move the interaction focus to the part of the page that is more
interesting, without having to use scroll bars or having to
explicitly drag the enlarged area to those parts.
- Effect:
Reduction of flexibility, and therefore of productivity and
satisfaction.
- Effect:
Reduction, even significant, of productivity.
- Fix:
For the controls which are repeated on many pages and when,
from the users' perspective it is worthwhile to learn keyboard
shortcuts for such controls, add the attribute ACCESSKEY to A,
INPUT, BUTTON elements. Remember to avoid using keys that are
associated to menu labels of the browser (like "f" for file) or
numbers (Firefox uses them to jump from tab to tab). Be also
careful not to use characters that interfere with the way a
screen reader (or other assistive technology) works.
Remember to make sure that access keys are described in a
help page and that they are consistently associated with the
same controls.
- Users:
Low-vision users
- Group:
User control
- Wcag 1.0:
3.4, 11.2
- Wcag 2.0:
1.4, 1.4.4
- Italian law:
12
- Cause:
The page contains text that cannot be resized because of the
way in which the font
size has been specified (deprecated FONT tag, or absolute units
in CSS like px, pt, in).
The page might also contain text that is painted in pixel
within images.
- Failure mode:
Depending on the browser being used, the user might not be
able to increase the font size of the text. As a consequence the
user will be forced to use the screen magnifier to access the
website.
- Effect:
Reduction of productivity and satisfaction.
- Fix:
To specify font size always use CSS properties that are based on
relative units, like em and %.
And never use images to represent text; implement appropriate
CSS rules.
- Users:
Low-vision users
- Group:
User control
- Wcag 1.0:
3.4
- Wcag 2.0:
1.4, 1.4.4
- Italian law:
12
- Cause:
The page has a layout that is not liquid; that is, it does
not adapt to window size nor does it adapt to resized text. If
the user enlarges the window then its content does not adapt to the
changes; if the user increases text size then objects in the window
overlap or are clipped.
- Failure mode:
Even if the user will maximize the window (to extend as much
as possible the field of vision) he or she will not
be able to take advantage of the larger size. He or she will be
forced to use the screen magnifier.
The user will not be able to increase the text size because
the parts that will overlap or that will clip some words will
prevent he or she from reading and understanding the
page. Again, the user will be forced to use the screen magnifier, or
to disable CSS completely.
This barrier is particularly relevant to users with a mild
low-vision.
- Effect:
Reduction of effectiveness. High frustration.
- Fix:
Use CSS rules to position elements within the page, and use
relative units (except for margins, padding and borders, where
absolute units are also OK). Refrain from using layout tables,
and especially avoid using spacer images to set the width or
height of columns or rows with absolute units (like 145px).
- Users:
Low-vision users
- Group:
Perception, understanding
- Wcag 1.0:
-
- Italian law:
-
- Cause:
The page uses graphical cues to help understanding
its contents (eg. vertical alignment, indentation, colors, white
space, horizontal lines) that may disappear when using high magnification
levels.
- Failure mode:
When enlarging the page and moving the viewport on certain
areas of the page, some of these cues may actually fall outsize the
viewport (eg. a vertical bar); the user might not understand that
the content is continuing below the bottom edge of the window. This
occurs frequently in news websites that include ad banners in the
middle of articles: the banner may be interpreted as signalling that
the article is finished.
Colors may be distorted at high magnification levels (or they
can be changed by users) with the consequence that their ability
to function as visual cues is reduced.
The user will be unable to see that there are other important
contents in the page.
- Effect:
Reduction of effectiveness.
- Fix:
Make sure that you use more than one clue to tell users
what is the visual structure of the page. Pay special attention to
horizontal separation elements that might be wrongly interpreted.
- Users:
Low-vision users
- Group:
User control
- Wcag 1.0:
13.6
- Wcag 2.0:
2.4, 2.4.1
- Italian law:
19
- Cause:
The page does not allow the user to jump directly to the
content, skipping over preliminary stuff,links like logos,
breadcrumbs, search boxes, global navigation bars).
- Failure mode:
The user has no way to quickly set the focus of interaction
(and hence her/his field of vision) on the page content.
- Effect:
Reduction of productivity.
- Fix:
Add, at the very beginning of the page, a link that would
allow the user to jump directly to the main content of the page.
Implement a link that is visible to everybody; if this is not
possible then implement the "skip-links" link in a hidden way,
by using "display: none" as a CSS rule or a clickable spacer
image whose ALT says "main content".
- Users:
Low-vision users
- Group:
User control
- Wcag 1.0:
9.4, 9.5
- Cause:
The page has been opened within a new browser window but the
usual browser controls (address bar, back, next, refresh
buttons, ...) are missing.
- Failure mode:
The user has to scan the entire page in order to find links
or buttons to move back to previously visited pages.
Not even the page address can be changed as the address bar
is missing.
- Effect:
Reduction of effectiveness.
- Fix:
Never disable browser controls.
The only viable exception is when opening temporary popup
windows (with a prominent "close" button).
- Users:
Low-vision users
- Group:
Operability
- Cause:
The page contains a data table whose column headers can be
clicked in order to sort table rows.
- Failure mode:
The user has to continuosly move back and forth the field of
vision in order to focus on the table cells s/he is interested
in and the headers in order to re-sort the rows.
- Effect:
Low productivity. The user spends time and effort to move
back and forth; in addition the interested rows can be lost when
the table is re-sorted.
- Fix:
Not obvious: you might want to try using a filter to restrict
the set of data the user might be interested in (rather than
providing the sorting functionality).
In addition, use alternating (or different) colors to
differentiate among columns and among rows.
- Users:
Low-vision users
- Group:
Perceivability
- Wcag 1.0:
6.3 8.1
- Wcag 2.0:
4.1, 4.1.2 3.3.1, 3.3.2, 3.3.3
- Italian law:
15
- Cause:
The page is part of a web application based on AJAX where
dynamic changes of the DOM occur. For example, notification
messages from the server are shown asynchronously
in a certain area of the page; this may occur without the user taking
any particular action, and without a page refresh.
- Failure mode:
If the change falls outsie the current viewport,
the user might not be aware that something in the page has changed
leading to confusion, errors, several trials and errors.
Even in cases where the user may be aware of that, s/he might be unable
to move the focus of the screen magnifier on that area because s/he
does not know where that area is located.
- Effect:
Reduction, possibly total, of effectiveness. High frustration,
low productivity.
- Fix:
The asynchronous (with respect to user actions) changes to the DOM
that AJAX permit are a problem for users of screenreaders and
screen magnifiers. For this problem there aren't many solutions,
other than building a separate user interface not based on AJAX,
built with plain HTML+CSS.
See the ARIA guidelines.
List of barriers for color-blind users
User category: Persons that cannot distinguish certain colors. Such a category could also include users of devices that change
or reduce the gamut of colors, for example gray-scale screens.
- Color is necessary
- Insufficient visual contrast
- Users:
Color-blind users
- Group:
Perception
- Wcag 1.0:
2.1
- Wcag 2.0:
1.4: 1.4.1
- Italian law:
4
- Cause:
The page contains material (text, images, background, videos)
where color is used as the sole mean to distinguish two or more
different information items. For example, raws in a table
providing balance figures, when black figures are positive
amounts and red ones are negative amounts.
Another common negative example is the use of color alone to
distinguish between followed and unfollowed links.
- Failure mode:
Users could be unable to distinguish between two or more
information items; for example, if green and red would be shown
to a color-blind person.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Use redundant means to distinguish between two
information items. Use typographic conventions that are based
not only on colors, but have in addition an audio effect when read
aloud. For example, use additional words or symbols; don't rely
only on a typographical effect like bold-face or italics style.
- Users:
Color-blind users
- Group:
Perception
- Wcag 1.0:
2.2
- Wcag 2.0:
1.4: 1.4.3, 1.4.6
- Italian law:
6
- Cause:
The page contains foreground material placed against a
background. The colors used to paint both of them have to little
contrast. The background can be a box with a solid color, based
on a gradient, with some texture or including a picture. The
foreground material can be text and/or images.
The
contrast can be based on differences in brightness or in
differences in the hues of the colors.
Sometimes the
problem arises only when the content of the page is rearranged;
for example because the text size has changed, or because the
window geometry has changed.
- Failure mode:
Users will have to make an effort to distinguish between
fore and background items, and in some cases will be totally
incapable of recognizing, and perhaps even detecting, the
foreground items.
This problem may occur also when the background is implemented
through an image and users disable CSS (for example, to get rid
of defects of the layout). Default colors used by the browser may result
having a small contrast level with the colors contained in the image,
leading to inability to distinguish certain information.
- Failure mode:
Users could be unable to perceive the existence of the
foreground content.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Remove any background image, or
change them so that they could never interfere with perception
and interpretation of the foreground content.
Additionally, an appropriate choice of colors that have a
high level of brightness contrast (this can be tested by viewing
the page in a gray-scale display) and a high level of hue
contrast will definitely solve this problem.
List of barriers for motor impaired users
User category: Persons that have no complete control of their upper body, arms
and/or hands.Such a category could also include persons that are temporarily
disabled (e.g. with a broken arm) or persons that have to use a
website in unusual postures (e.g. standing while giving a lecture).
- Cascading menu
- Mouse events
- Opaque objects
- keyboard traps
- Internal links are missing
- Too many links
- Links/buttons that are too close to each other
- Links/buttons that are too small
- New windows
- Forms with no LABEL tags
- Too short timings
- No keyboard shortcuts
- Skip links not implemented
- Window without browser controls
- Users:
Motor impaired users
- Group:
Operability
- Cause:
The page contains hierarchical cascading menus, where entries
of one menu correspond to a second-level menu (implemented
through nested SELECT or through JavaScript code).
- Failure mode:
The user cannot correctly and easily move the mouse pointer
onto the desired entries; it may be especially difficult to open
secondary menus and to keep them open while moving to the
desired entry.
- Effect:
Reduction of effectiveness and of satisfaction.
- Fix:
Avoid using cascading menus; if possible implement separate
menus, even better if flat option lists are used (selectable
by clicking on links or by setting radio buttons).
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 9.3
- Wcag 2.0:
2.1, 2.1.1, 2.1.3
- Italian law:
16
- Cause:
The page is based on JavaScript in order to obtain specific
effects. JavaScript functions are invoked through event handlers
("onclick", "onmouseover", "onmouseout", ...) that are
mouse-oriented.
- Failure mode:
The user, who is likely to prefer using the keyboard rather
than the mouse for certain activities, is in a situation where
the functionalities appear to be available but they do not work.
- Effect:
Reduction of effectiveness.
- Fix:
Use also logical event handlers ("onfocus", "onkeypress",
...) in addition to mouse-oriented ones.
It would be even better if the functionalities achieved
through event handlers could be achieved also without JavaScript.
- Users:
Motor impaired users
- Group:
Perception, Operability
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1, 1.1.1
- Cause:
The page contains components (eg. a Flash object) that is
totally opaque to screen readers (and other assistive
technologies). For example a menu that cannot be opened using
the keyboard, that cannot be read aloud by the screen reader,
etc.
- Failure mode:
There would be no way to use the object.
- Effect:
Reduction, also total lack, of effectiveness.
- Fix:
Make sure the object is accessible (for example, follow the
Flash guidelines ); or remove it.
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 9.3
- Wcag 2.0:
2.1, 2.1.2
- Italian law:
16
- Cause:
The page contains components (eg. a Flash intro) that lock
the user once s/he moves the keyboard focus on them. For
example, it may happen that a user tabs into a Flash intro and
then cannot escape using the keyboard alone (that is, cannot
move the keyboard focus out of the object).
- Failure mode:
The user, who is likely to prefer using the keyboard rather
than the mouse for certain activities, a keyboard trap would be
a very severe problem. The user would need to reload the page to
restart, and then would need to remember when not to hit the tab
key.
- Effect:
Reduction of effectiveness.
- Fix:
Provide a way to move the keyboard focus out of the
object. Sometimes (eg. Flash) this is achieved by a invoking a
"move to parent object" function.
Use also logical event handlers ("onfocus", "onkeypress",
...) in addition to mouse-oriented ones.
It would be even better if the functionalities achieved
through event handlers could be achieved also without JavaScript.
At the very least, warn the user about the trap before s/he
has chances to hit it.
- Users:
Motor impaired users
- Group:
Operability, user control
- Cause:
The page, which is complex and full of contents that usually
cannot be used completely in a window without requiring
scrolling, does not have internal links that would allow the
user to jump from section to section, or to return to the beginning
of the page.
- Failure mode:
The user has to constantly move the mouse pointer between the
page content to the scroll bar, especially if the page contains
form controls.
In those cases where the user does not utilize the mouse, the
page requires a more frequent use of moving keys (tab, arrows,
page-up and page-down).
- Effect:
The time required to complete a task increases, and so does
also the number of errors and slips (for example, in using
correctly the small buttons of the scrollbar). Productivity
drops as well as effectiveness.
- Fix:
Add navigation links to the end (or the beginning) of each
section (correctly marked up with tags like H2, H3 and similar
ones). They should lead to the beginning of the previous and
next sections, and to a table of contents of the page. You don't
need to add the links leading to the top of the page or to its
end, as this function is normally already fulfilled by the
"Home" and "End" keys.
- Users:
Motor impaired users
- Group:
Comprehension, user control
- Wcag 1.0:
12.3
- Wcag 2.0:
2.4, 2.4.10
- Cause:
The page contains too many links, that are perhaps not well
organized in clearly labeled groups.
- Failure mode:
The large number of links requires that users perform a
lengthy and exerting activity when scanning them all before
deciding if there is one that is worth following. When scanning
links, users have to move from one to the next. If they use the
keyboard to select the required link, then they have to go
through a lengthy sequence of tabbing. On the other hand, if
they use the mouse, then they might need to use frequently the
scroll bars, which are difficult to use due to the small size of
the scrolling buttons.
- Effect:
Reduction of productivity, satisfaction and effectiveness.
- Fix:
Reduce the number of links in the page. If this is not
possible then organize them properly into groups. Implement the
groups with proper tags; for example use a list (UL/OL) rather
than including the links in a table. Separate different groups
with page headings (H2, H3, etc.) so that users can jump
directly to a page section. Spread the links into more
intermediate pages.
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
10.5
- Italian law:
21
- Cause:
The page contains a sequence of links/buttons that are too
close to each other (vertically or horizontally).
- Failure mode:
The user will often get into errors (slips) when using the
mouse to hit links or buttons that are located close to each
other. In fact very often the user will hit the wrong
link/button.
- Effect:
Reduction of productivity.
- Fix:
Make sure that links/buttons either cover a relatively large
clickable area, or that they are well separated by white
space.
- Users:
Motor impaired users
- Group:
Operability
- Italian law:
21
- Cause:
The page contains links/buttons that are too small.
- Failure mode:
The user will face many difficulties in using the mouse to
hit links or buttons that are very small.
- Effect:
Reduction of productivity and perhaps also of effectiveness.
- Fix:
Make sure that links/buttons cover a sufficiently large
clickable area so that they can be hit even when the mouse is
used with a low precision.
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
10.1
- Wcag 2.0:
3.2, 3.2.1, 3.2.5
- Italian law:
1
- Cause:
The page contains HTML or JavaScript code that opens new browser
windows either when the user activates links/buttons or, even
worse, after the page has been loaded.
- Failure mode:
If the link/button for closing the new window is small, the
user will face many difficulties to hit it. Even worse if the
page displayed in the popup window does not have any close
button/link. The user has to use the (very small and very close
to other buttons) generic button in the
window title bar that closes the window.
- Effect:
Reduction of productivity.
- Fix:
Avoid opening new windows.
If this is really needed or is a de-facto standard (for example
when selecting a date from a JavaScript popup calendar window) then
make sure that at the very beginning of the new window there is
a large link/button called "Close window".
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
10.2, 12.4
- Wcag 2.0:
2.4, 2.4.7, 1.3, 1.3.1
- Italian law:
14
- Cause:
The page contains a form whose controls are not marked up
with LABEL tag and FOR attribute.
- Failure mode:
Some controls have a clickable area that is very small (that
is radiobuttons and checkboxes), and the user will struggle to
hit them correctly.
- Effect:
Reduction of productivity.
- Fix:
Always wrap the text (or image) representing the label of each
control with the LABEL tag and FOR attribute. When this is not
possible, use at least the TITLE attribute.
In this way, for controls like checkboxes and radiobuttons,
also the text of the label is clickable, increasing the
clickable area and improving users' productivity.
- Users:
Motor impaired users
- Group:
Operability
- Wcag 1.0:
7.4, 7.5
- Wcag 2.0:
2.2, 2.2.1, 2.2.4, 3.2, 3.2.5
- Italian law:
20
- Cause:
The web page is automatically refreshed after a certain time
has elapsed (that is, its content is changed and/or a new page
is reloaded by the browser without the user asking for it).
- Failure mode:
If the user needs more time to read the page and use it (for
example to read a license and press the "Accept" button) then he
or she will not be able to complete the task and achieve the
desired goal because the system has changed state.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid time-based actions that change the status of the page
if the user does not consciously initiate them.
- Users:
Motor impaired users
- Group:
User control
- Wcag 1.0:
9.5
- Cause:
The page has links/buttons/form controls that are repeated on
many other pages (like in a web application) and no
keyboard shortcut is defined with ACCESSKEY.
- Failure mode:
The keyboard is often the preferred input device. Therefore
accesskeys improve a lot usability of the website.
- Effect:
Reduction of flexibility, and therefore of productivity and
satisfaction.
- Effect:
Reduction, even significant, of productivity.
- Fix:
For the controls which are repeated on many pages and when,
from the users' perspective it is worthwhile to learn keyboard
shortcuts for such controls, add the attribute ACCESSKEY to A,
INPUT, BUTTON elements. Remember to avoid using keys that are
associated to menu labels of the browser (like "f" for file) or
numbers (Firefox uses them to jump from tab to tab). Be also
careful not to use characters that interfere with the way a
screen reader (or other assistive technology) works.
Remember to make sure that access keys are described in a
help page and that they are consistently associated with the
same controls.
- Users:
Motor impaired users
- Group:
User control
- Wcag 1.0:
13.6
- Wcag 2.0:
2.4, 2.4.1
- Italian law:
19
- Cause:
The page does not allow the user to jump directly to the
content, skipping over preliminary stuff,links like logos,
breadcrumbs, search boxes, global navigation bars).
- Failure mode:
The user has no way to quickly move to the desired link. The
only mechanism that is available might be the "text search"
function provided by the browser. However this functionality
might not be known to the user, there might be several targets
for the string search, and it might require substantial
typing.
A further problem which worsen this barrier is the
difficulty with which one detects how the browser focus moves
along the elements in the page; expecially if the tabbing order
differs from the visual ordering.
- Effect:
Reduction of productivity.
- Fix:
Add, at the very beginning of the page, a link that would
allow the user to jump directly to the main content of the page.
Implement a link that is visible to everybody; if this is not
possible then implement the "skip-links" link in a hidden way,
by using "display: none" as a CSS rule or a clickable spacer
image whose ALT says "main content".
- Users:
Motor impaired users
- Group:
User control
- Wcag 1.0:
9.4, 9.5
- Cause:
The page has been opened within a new browser window but the
usual browser controls (address bar, back, next, refresh
buttons, ...) are missing.
- Failure mode:
The user has to scan the entire page in order to find links
or buttons to move back to previously visited pages.
- Effect:
Reduction of effectiveness.
- Fix:
Never disable browser controls.
The only viable exception is when opening temporary popup
windows (with a prominent "close" button).
List of barriers for deaf users
User category: Persons that cannot hear or with significantly reduced hearing
abilities. Such a category could also include users that have to use a
website in a context where the audio is not available or possible
(like when in library or during a conference or lecture).
- No captions for audios
- Video with no captions
- Missing synchronization
- Users:
Deaf users
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.9
- Cause:
The page contains a multimedia file that has an audio
channel that describes something, but there are no textual
descriptions nor captions for what is being said.
- Failure mode:
The user has no way to perceive and
utilize the information that is provided through the audio.
- Effect:
Reduction of effectiveness.
- Fix:
Add to the multimedia file also the textual description of
the voice. This can be easily implemented through a link to a
page that contains the textual transcription of the dialog. The
OBJECT tag can be used to achieve this result.
However
such a solution is not suitable for those cases where the dialog
is synchronized with images or video frames. In these cases you
need to caption the video by adding textual transcriptions of
the dialog for each scene of the video and by adding textual
description of relevant audio events (noise, sounds). SMIL can
be used to implement this kind of synchronization.
- Users:
Deaf users
- Group:
Perception
- Wcag 1.0:
1.1, 1.4
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.7, 1.2.8, 1.2.9
- Italian law:
3,18
- Cause:
A multimedia file with a video or an animation that has no
textual description of the scenes.
- Failure mode:
The user has no way to understand dialogs and interpret other sounds that occur during the video scenes.
- Effect:
Reduction of effectiveness.
- Fix:
Enrich the multimedia file with textual descriptions that are
synchronized with video frames. Link each video scene with
captions that textually describe the relevant events that are
happening in the video (for example, a closeup on the naked and
silent feet of the killer that approaches the designated victim
from behind). Languages like SMIL have to be used in order
that assistive technology and browsers get to know about the
availability of such a text; in addition they can synchronize
the different channels (visual, textual, audio).
Alternatively, or in addition to, provide also
audio descriptions (i.e. clips) that are synchronized with the
video and are compatible with the existing audio tracks; these
clips should supply additional descriptions of the video (for
example, as a narrating voice in the background).
Consider also adding to the video a track with a sign
language interpreter for the benefit of people with hearing
disabilities.
- Users:
Deaf users
- Group:
Perception and user control
- Wcag 1.0:
1.4
- Wcag 2.0:
1.2: 1.2.2
- Italian law:
18
- Cause:
A multimedia file, audio or video, that does not contain nor
is somehow linked to textual descriptions that are equivalent
and synchronized.
- Failure mode:
The user has no way to perceive the information conveyed in
the dialogs nor those conveyed by relevant background noises
(for example, the quiet steps of the killer that is walking up
the stairs).
- Effect:
Reduction of effectiveness.
- Fix:
Enrich the multimedia file with textual descriptions that are
synchronized with the video scenes. Add captions (textual
descriptions of the noises) and subtitles (textual descriptions
of the dialogs)
to the video scenes. Use SMIL to implement an appropriate
synchronization between the three channels (visual, auditory, and
textual).
List of barriers for cognitive disabilities
User category: Persons with limited ability to process and memorize
information, to take decisions or to learn; these include learning
disabilities (affected by dyslexia and dysgraphia), attention
disorders, developmental disorders (Down's syndrome, autism) or
neurological disorders (Alzheimer).Such a category could also include people that have to use a
website under stress conditions (e.g. in a hurry, in a noisy and
distracting environment, while carrying out some other important
task).In addition, foreign language users of the website tend to face
similar barriers.
- Rich images lacking equivalent text
- Video with no captions
- Moving content
- Generic links
- Ambiguous links
- Internal links are missing
- Missing icons
- Complex text
- Complex site
- Too many links
- Text fields with no example
- New windows
- Too short timings
- No page headings
- Text-only page
- Complex data table
- Acronyms and abbreviations without expansions
- Users:
Cognitive disabilities
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1 1.1.1
- Italian law:
3
- Cause:
The page contains some image that provides information (e.g. a
diagram, histogram, picture, drawing, graph) but only in a
graphical format; no equivalent textual description appears in
the page.
- Failure mode:
The user might not be able to grasp the meaning of some of
the information displayed in the picture. For example, a
correlation between variables in a complex scatter plot.
- Fix:
Add a textual description to the image that is close to the
image so that it can be seen also when looking at the image. A
good caption should provide an explanation of the
information contained in the picture.
- Users:
Cognitive disabilities
- Group:
Perception
- Wcag 1.0:
1.1, 1.4
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.7, 1.2.8, 1.2.9
- Italian law:
3,18
- Cause:
A multimedia file with a video or an animation that has no
textual description of the scenes.
- Failure mode:
The user has no way to view the video at the speed that is
most appropriate to her/him, for example to review some of the
scenes, or to better understand which character in the video
says what.
- Effect:
Reduction of effectiveness.
- Fix:
Enrich the multimedia file with textual descriptions that are
synchronized with video frames. Link each video scene with
captions that textually describe the relevant events that are
happening in the video (for example, a closeup on the naked and
silent feet of the killer that approaches the designated victim
from behind). Languages like SMIL have to be used in order
that assistive technology and browsers get to know about the
availability of such a text; in addition they can synchronize
the different channels (visual, textual, audio).
Alternatively, or in addition to, provide also
audio descriptions (i.e. clips) that are synchronized with the
video and are compatible with the existing audio tracks; these
clips should supply additional descriptions of the video (for
example, as a narrating voice in the background).
Consider also adding to the video a track with a sign
language interpreter for the benefit of people with hearing
disabilities.
- Users:
Cognitive disabilities
- Group:
Perception
- Wcag 1.0:
7.3
- Wcag 2.0:
2.2, 2.2.2
- Italian law:
5
- Cause:
Images or text that moves (for example running text, animated
GIF).
- Failure mode:
Moving content can be difficult to interpret and understand by the user, if it is relatively complex and stays visible for too short a time.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid using moving content, and always give the user the
flexibility to decide when to move on.
- Users:
Cognitive disabilities
- Group:
Operability
- Wcag 1.0:
13.1
- Wcag 2.0:
2.4, 2.4.4, 2.4.9
- Italian law:
19
- Cause:
The page contains links with anchor text that is not
informative as it does not provide clues (for example, "click
here" or "More").
- Failure mode:
Links generally draw the attention of the eye. However the user
is not always able to examine also the text or the images that
are located close to the link. In the end the result is
similar to those that have a very narrow field of vision: they
see the label in a context-free fashion.
- Effect:
Reduction of effectiveness.
- Fix:
Modify all the link labels so that they provide clues as to
which page will be opened. Do not use "click here", but rather
"details on product XYZ".
- Users:
Cognitive disabilities
- Group:
Operability
- Wcag 1.0:
13.1
- Wcag 2.0:
2.4, 2.4.4, 2.4.9
- Italian law:
19
- Cause:
The page contains links with labels (anchor text) that are
ambiguous, because the same text is used to represent
several different URLs; for example "click here" or "buy" that
are repeated many times in the page.
- Failure mode:
Links in the page generally draw the attention of the
eye. However the user is not always able to examine also the
text or the images that are located close to the link. In the
end the result is similar to those that have a very narrow field
of vision: they see the label in a context-free fashion.
Furthermore the user could activate the wrong link by
mistake, because she/he thought that that was the link she/he
saw a few seconds before.
- Effect:
Reduction of effectiveness.
- Fix:
Modify the anchor text of links so that they are informative
and different from each other. Never use the same text for two
different links.
If this should not be possible, at least use the TITLE
attribute to add distinguishing text for different links.
- Users:
Cognitive disabilities
- Group:
Operability, user control
- Cause:
The page, which is complex and full of contents that usually
cannot be used completely in a window without requiring
scrolling, does not have internal links that would allow the
user to jump from section to section, or to return to the beginning
of the page.
- Failure mode:
The user will struggle in understanding the structure of the
page, and to remember which section contains which
information. He or she will also struggle in scanning the
document and to reach the beginning of a particular section.
- Effect:
Reduction of effectiveness.
- Fix:
Add navigation links to the end (or the beginning) of each
section (correctly marked up with tags like H2, H3 and similar
ones). They should lead to the beginning of the previous and
next sections, and to a table of contents of the page. You don't
need to add the links leading to the top of the page or to its
end, as this function is normally already fulfilled by the
"Home" and "End" keys.
- Users:
Cognitive disabilities
- Group:
Comprehension
- Wcag 1.0:
14.2
- Cause:
The page lacks icons associated to links and other content of
the page. The page has also too little colors that would help
people understand better how the page is organized and what kind
of contents are shown.
Typically text-only pages have this kind of defect.
- Failure mode:
The user struggle to understand the function of what she/he
can see (for example the anchor text of a link). Time and effort
are spend in order to decide if the item is relevant to the task
at hand.
Furthermore it will be difficult for the user to later recall
the meaning and function of the same item the next time she/he
encounters it.
- Fix:
Couple to each link an icon so that it can more easily
perceived and understood.
Use different background colors to distinguish different
areas of the page.
- Users:
Cognitive disabilities
- Group:
Comprehension
- Wcag 1.0:
14.1, 4.2
- Wcag 2.0:
3.1, 3.1.3, 3.1.5
- Cause:
The page contains text that is complex to read because of the
complexity of the sentences, phrases or words; also because the
text is ridden with acronyms and abbreviations or because of
spelling errors.
- Failure mode:
The user will struggle in understanding the content and in
navigating through it.
- Effect:
Reduction, even total lack, of effectiveness. Significant
reduction of productivity.
- Fix:
Simplify as much as possible the structure of sentences and
the lexicon used. Avoid using jargon. Make sure there are no
spelling errors.
If possible provide an audio rendering of the next, with a
narrating voice.
If abbreviations or acronyms are included, always code them
with ABBR or ACRONYM. Provide a glossary in the website with
appropriate definition of technical terms.
- Users:
Cognitive disabilities
- Group:
Comprehension
- Wcag 1.0:
13.3
- Wcag 2.0:
2.4, 2.4.5
- Cause:
The website has a complex organization, with complex and rich
relationships between its content items.
- Failure mode:
The user will struggle in understanding the website content
and in navigating through it.
- Effect:
Reduction of effectiveness and of productivity.
- Fix:
Simplify as much as possible the information architecture of
the website. Remove everything that is not needed by the user
when using a certain page.
Include breadcrumbs everywhere, with clear and unambiguous
entries. Make sure that the breadcrumbs are easily
spotted. Include an accessible site map.
- Users:
Cognitive disabilities
- Group:
Comprehension, user control
- Wcag 1.0:
12.3
- Wcag 2.0:
2.4, 2.4.10
- Cause:
The page contains too many links, that are perhaps not well
organized in clearly labeled groups.
- Failure mode:
The large number of links requires that users perform a
lengthy and exerting activity when scanning them all before
deciding if there is one that is worth following. When scanning
links, users have to read them, understand them, memorize them
and be able to eventually
find them again once a decision is taken regarding which link to
follow.
If the links are badly organized, not grouped into meaningful
categories, with anchor text that is ambiguous or generic then
the problem is much worse.
And if links and link categories are not distinguished by
colors or by appropriate icons, and if they use complex words,
then the problem is even worse.
- Effect:
Reduction of productivity, satisfaction and effectiveness.
- Fix:
Reduce the number of links in the page. If this is not
possible then organize them properly into groups. Implement the
groups with proper tags; for example use a list (UL/OL) rather
than including the links in a table. Separate different groups
with page headings (H2, H3, etc.) so that users can jump
directly to a page section. Spread the links into more
intermediate pages.
- Users:
Cognitive disabilities
- Group:
Operability
- Cause:
The page contains text fields that provide no instructions on
how they should be filled in.
- Failure mode:
The user will hardly understand what is required in order to
correctly fill in the field.
- Effect:
Form filling errors will increase, reducing therefore
effectiveness and productivity.
- Fix:
Supply, as default values or as dummy values that disappear
when one clicks on the field, an example of correct data.
- Users:
Cognitive disabilities
- Group:
Operability
- Wcag 1.0:
10.1
- Wcag 2.0:
3.2, 3.2.1, 3.2.5
- Italian law:
1
- Cause:
The page contains HTML or JavaScript code that opens new browser
windows either when the user activates links/buttons or, even
worse, after the page has been loaded.
- Failure mode:
The user does not realize that a new window is opened and
that the interaction context has changed; and therefore that
both content and set of commands/controls have changed.
This is especially bad when it happens out of the blue, in the
middle of a user task (typically this happens with popup windows
that are not relevant with the user task).
Also the BACK button of the browser (if available) does not
work anymore, a missing safety net that is used very often.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid opening new windows, and provide some sort
of explanation of such a behavior so that it can be read to the
user before the window is opened.
If this is really needed or is a de-facto standard (for example
when selecting a date from a JavaScript popup calendar window) then
make sure that in a prominent location in the new window there is
a link/button called "Close window" so that users understand
that this is a new window and the button gives them the
opportunity to close it.
- Users:
Cognitive disabilities
- Group:
Operability
- Wcag 1.0:
7.4, 7.5
- Wcag 2.0:
2.2, 2.2.1, 2.2.4, 3.2, 3.2.5
- Italian law:
20
- Cause:
The web page is automatically refreshed after a certain time
has elapsed (that is, its content is changed and/or a new page
is reloaded by the browser without the user asking for it).
- Failure mode:
If the user needs more time to read and use the page (for
example to read a license and press the "Accept" button) then he
or she will not be able to complete the task and achieve the
desired goal because the system has changed state.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid time-based actions that change the status of the page
if the user does not consciously initiate them.
- Users:
Cognitive disabilities
- Group:
Comprehension, user control
- Wcag 1.0:
3.5
- Wcag 2.0:
2.4, 2.4.10, 1.3.1
- Cause:
The page does not contain tags H1, H2, ..., H6 for organizing
its content into sections.
- Failure mode:
If there informative titles then the user will be able to
easily distinguish different sections of the page content. These
titles will help the user to focus her/his attention and to
continue the interaction.
- Effect:
Reduction of productivity.
- Fix:
For each type of content in the page (e.g. navigation bar,
breadcrumbs, sequence of paragraphs, boxed contents) add a new
heading. It can even be hidden using appropriate CSS rules.
Remember to respect their nesting levels: do not skip levels.
- Users:
Cognitive disabilities
- Group:
User control
- Wcag 1.0:
6.2 11.4
- Italian law:
22
- Cause:
The page contains a link that leads to a text-only page or a
low-graphics page.
However the text-only page contains less links, less
information or is not as updated as the original page.
- Failure mode:
The usage of text-only does not help the user in reading and
understanding and using the page.
- Effect:
Reduction of effectiveness.
- Fix:
Avoid forcing the user to use such pages.
If you need to, then implement them as a low-graphics
alternative to the original pages; take advantage of the simpler
structure of such pages but add icons and colored boxes as
visual cues to simplify their interpretation.
- Users:
Cognitive disabilities
- Group:
Understandability
- Cause:
The page contains a data table with many columns and/or rows.
- Failure mode:
The user might face difficulties in identifying the required
row, and in understanding the content of a row. In addition,
there might be difficulties in understing information that
requires comparison of different rows and/or columns (like
understanding a trend).
- Effect:
Low effectiveness. Some tasks cannot be completed because of
partial understanding of data.
- Fix:
Not obvious: you might want to offer alternative views of the
data by reducing the amount of detail being shown. For example,
by pre-filtering out some of the rows, or by supplying some
statistical aggregation (like an average or median or
range).
In addition, use alternating (or different) colors to
differentiate among columns and among rows to improve ease of
orientation.
- Users:
Cognitive disabilities
- Group:
Understandability
- Wcag 1.0:
4.2
- Wcag 2.0:
3.1, 3.1.4
- Cause:
The page contains acronyms and/or abbreviations that are not
expanded (for example they contain "WAI" and there is no title
attribute of the ABBR tag nor explicit text - like in "WAI (Web
Accessibility Initiative)").
- Failure mode:
The user might not understand what the abbreviation
means. Even if it was explained in previously seen pages, the
user might not remember it.
- Effect:
Low effectiveness. Some tasks cannot be completed because of
partial understanding of data.
- Fix:
Always add the expansion to every abbreviation and
acronym. The least obtrusive way is through the ABBR tag and
TITLE attribute, that shows the expansion when the mouse hovers
over the abbreviation (requiring thus that the user "actively
looks for" the expansion).
Alternatively, by simply placing the expansion text between
parentheses close to
the abbreviation itself, it is available to everybody without
any searching activity.
List of barriers for users of browsers where javascript is disabled
User category: Users of browsers that cannot process JavaScript
instructions. For example, microbrowsers within cellular phones or
PDAs; users of proxy systems, transcoders, gateways that for some
reason (including security) prevent them from using JavaScript.Also artificial agents, like search engine spiders or automated
testing tools, cannot process JavaScript code.
- Dynamic menus in JavaScript
- Cascading menu
- Mouse events
- Automatically populated form controls
- Form with redirect
- Fields validation
- Hidden fields
- New windows
- Window without browser controls
- JavaScript is necessary
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 6.5, 8.1
- Wcag 2.0:
2.1, 2.1.1, 2.1.3, 4.1, 4.1.2
- Italian law:
17, 15
- Cause:
The page contains JavaScript code so that, as soon as the
user moves the focus of interaction onto an element, a menu
drops down in a given area of the page.
- Failure mode:
The user will not be able to utilize the functionalities
offered through the menu, since it does not appear at all.
- Effect:
Complete reduction of effectiveness.
- Fix:
All navigation options and commands (for example menu
entries) should be selectable also when JavaScript is not
enabled.
If needed, provide an alternative page with redundant links
and options; make sure that such a page can be reached from the
original one.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Cause:
The page contains hierarchical cascading menus, where entries
of one menu correspond to a second-level menu (implemented
through nested SELECT or through JavaScript code).
- Failure mode:
If the menu is implemented in JavaScript then it could be
used at all.
- Effect:
Complete reduction of effectiveness.
- Fix:
Avoid using cascading menus; if possible implement separate
menus, even better if flat option lists are used (selectable
by clicking on links or by setting radio buttons).
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
6.3, 6.4, 9.3
- Wcag 2.0:
2.1, 2.1.1, 2.1.3
- Italian law:
16
- Cause:
The page is based on JavaScript in order to obtain specific
effects. JavaScript functions are invoked through event handlers
("onclick", "onmouseover", "onmouseout", ...) that are
mouse-oriented.
- Failure mode:
The user will not be able to use the functionalities
achievable through event handlers.
- Effect:
Complete reduction of effectiveness.
- Fix:
Use also logical event handlers ("onfocus", "onkeypress",
...) in addition to mouse-oriented ones.
It would be even better if the functionalities achieved
through event handlers could be achieved also without JavaScript.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
6.3 8.1
- Cause:
The page contains forms where some of the field or controls
are set automatically, through JavaScript code. For example, once the
user selects (from a selection list) a state, then the selection
list of telephone area codes is updated correspondingly.
- Failure mode:
If the users uses a browser that is not JavaScript enabled, then
the form cannot be used at all.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid implementing these functionalities only in
JavaScript. Implement them also server-side.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
7.5
- Cause:
The page contains a form where some controls, as soon as they
are used, cause a submit to the server which returns a new,
updated, page. This is achieved by using specific JavaScript event
handlers. AJAX is not considered here: this is not the normal
way it is used.
- Failure mode:
The user would be unable to use the form, since the changes
produced by the server would not be activated.
- Effect:
Total reduction of effectiveness.
- Fix:
Avoid, whenever possible, the constant refresh caused by the
browser sending data back and forth to the server. If this is
not possible then implement a page-level navigation system that
supports users of keyboard and of screen readers. Namely, use
tags like H2-H6 and DIV to split the page contents into
manageable chunks, implement skip-links links to enable users to
jump directly to the page content, assign proper ACCESSKEY
attributes to form controls so that the focus can be moved
directly to them with a few keystrokes.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
6.3, 8.1
- Italian law:
16, 17
- Cause:
The page contains form fields and controls that are validated
only through JavaScript.
- Failure mode:
If the JavaScript code prevents sending the data to the server,
then the user would be prevented from completing the task and
achieving the goal.
On the other hand, if the JavaScript code does not block (perhaps
it only warns the user that some data is wrongly spelled), then
the user will be able to send the non-validated data to the
server. But if no server-side validation is performed then the
server could get and accept incorrect or inconsistent data,
perhaps leading to subsequent problems (like shipment of the
ordered items to a wrong address).
- Effect:
Reduction, even total lack, of effectiveness and of productivity.
- Fix:
Always implement data validation also on the server side, to
make sure that the data accepted by the server and stored in the
database are as correct and consistent as it is viable to
achieve through automatic validation. Even better if there is
also client-side validation, which is more interactive and can
provide better help to the user. But there should be a safety
net for client-side validation provided by server-side
validation.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Cause:
The page contains forms with hidden fields that are populated
by JavaScript code just before the form data is sent to the
server.
- Failure mode:
In many cases the user will be unable to get the expected
results from the
server since the latter will require also the value stored in
the hidden fields in order to properly process the request.
- Fix:
Avoid using JavaScript to populate hidden fields.
- Users:
Users of browsers where JavaScript is disabled
- Group:
Operability
- Wcag 1.0:
10.1
- Wcag 2.0:
3.2, 3.2.1, 3.2.5
- Italian law:
1
- Cause:
The page contains HTML or JavaScript code that opens new browser
windows either when the user activates links/buttons or, even
worse, after the page has been loaded.
- Failure mode:
If the window is opened through JavaScript code then the user will
have no opportunity to use its contents.
- Effect:
Reduction, even total lack, of effectiveness.
- Fix:
Avoid opening new windows using only JavaScript code. You might
want to use the (deprecated!) TARGET attribute.
- Users:
Users of browsers where JavaScript is disabled
- Group:
User control
- Wcag 1.0:
9.4, 9.5
- Cause:
The page has been opened within a new browser window but the
usual browser controls (address bar, back, next, refresh
buttons, ...) are missing.
- Failure mode:
The user would not be able to access the page at all, since
to open it the browser needs to execute JavaScript code.
- Effect:
Reduction of effectiveness.
- Fix:
Never disable browser controls.
The only viable exception is when opening temporary popup
windows (with a prominent "close" button).
- Users:
Users of browsers where JavaScript is disabled
- Group:
Perceivability
- Wcag 1.0:
6.3 8.1
- Italian law:
15
- Cause:
To use the page a JavaScript-enabled browser is necessary,
for example because it is part of an AJAX application, or
because a redirect is implemented in JavaScript, or because at
load-time a crucial JavaScript function is invoked.
- Failure mode:
The user might not be able to view/perceive any content of
the page because the browser is not JavaScript-enabled.
- Effect:
Reduction, possibly total, of effectiveness.
- Fix:
The content (information and/or functionalities) that is
provided via JavaScript should be made available (perhaps in a
different format, with a different interaction design) also
without recurring to JavaScript.
Consider building an HTML+CSS version of the page.
List of barriers for users with photosensitive epilepsy
User category: Users of browsers that have an epilepsy that is
photosensitive for whom seizures are triggered by
flickering or flashing light. Only 5 percent of the persons with
epilepsy may have photosensitive epilepsy. More details can be read on www.epilepsy.org.uk.
- Page with flickering or flashing content
- Users:
Users with Photosensitive Epilepsy
- Group:
Safety
- Wcag 1.0:
7.1 7.2
- Wcag 2.0:
2.3, 2.3.1, 2.3.2, 2.2, 2.2.2
- Italian law:
5
- Cause:
The page contains elements (images or text or background)
that is flashing or flickering at a rate between 3Hz to 60Hz. In
order to cause such an effect the intensity of the flash should
be high.
- Failure mode:
The page may trigger epileptic seizures for users that have
this kind of disability. A seizure is ...
... the result of a sudden burst of excess electrical
activity in the brain. This causes the brain's messages to
become temporarily halted or mixed up. The type of seizure a
person has depends on the area of the brain where this activity
occurs. (www.epilepsy.org.uk/info/types.html)
- Effect:
Safety threat. A seizure has effects like momentary lack of
consciousness, convulsions, falling to the floor.
- Fix:
Avoid using flashing or flickering content.
In this case the Barrier Walkthrough method can be
used to determine if there are barriers preventing
a search engine to scan, process and index
the content of the page. Severity rating of these
barriers is less meaningful as when dealing with human users.
List of barriers for search engines
User category: Obviously, these are very different users! In many cases though,
spiders of search engines face the same kinds of barriers that are faced
by humans.
- Rich images lacking equivalent text
- Rich images included in the page background
- No captions for audios
- Video with no captions
- Functional images lacking text
- Generic links
- Spaced titles
- Page without titles
- No page headings
- Images used as titles
- JavaScript is necessary
- Users:
Search engines
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.1 1.1.1
- Italian law:
3
- Cause:
The page contains some image that provides information (e.g. a
diagram, histogram, picture, drawing, graph) but only in a
graphical format; no equivalent textual description appears in
the page.
- Failure mode:
This is a missed opportunity. Search engines will have less text to
analyze and rank appropriately your page.
- Fix:
Add an equivalent textual description to the image: by using
the ALT attribute of IMG, and if not sufficient by using the
OBJECT tag and specifying the text in the content of the
tag. Should this still be insufficient, then place the
equivalent text close to the image so that it can be seen also
by those who can see the image (and used by the search engine as
well).
- Users:
Search engines
- Group:
Perception
- Wcag 1.0:
1.1, 6.1
- Italian law:
3,4,6
- Cause:
Images that convey information are included as
background (using CSS); hence there is no way to attach
any equivalent text to them.
- Failure mode:
Information included in these images
cannot be used at all by search engines. Another missed
opportunity to improve ranking and searchability of the page.
- Effect:
Reduction of effectiveness.
- Fix:
Include images in the HTML of the page, using
tags like IMG or OBJECT. And specify appropriate values for the
attribute ALT (or for the content of the OBJECT tag). If needed
add also a link that leads to a page specifically aimed at
providing a rich description of the image content.
- Users:
Search engines
- Group:
Perception
- Wcag 1.0:
1.1
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.9
- Cause:
The page contains a multimedia file that has an audio
channel that describes something, but there are no textual
descriptions nor captions for what is being said.
- Failure mode:
The search engine will be unable to
properly index the page and the audio; consider that textual
descriptions actually work also as textual tags for the search
engine and for users of the search engine.
- Users:
Search engines
- Group:
Perception
- Wcag 1.0:
1.1, 1.4
- Wcag 2.0:
1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.7, 1.2.8, 1.2.9
- Italian law:
3,18
- Cause:
A multimedia file with a video or an animation that has no
textual description of the scenes.
- Failure mode:
The search engine will be unable to properly index the page
and the video; consider that textual descriptions actually work
also as textual tags for the search engine and for users of the
search engine.
- Effect:
Reduction of effectiveness.
- Fix:
Enrich the multimedia file with textual descriptions that are
synchronized with video frames. Link each video scene with
captions that textually describe the relevant events that are
happening in the video (for example, a closeup on the naked and
silent feet of the killer that approaches the designated victim
from behind). Languages like SMIL have to be used in order
that assistive technology and browsers get to know about the
availability of such a text; in addition they can synchronize
the different channels (visual, textual, audio).
Alternatively, or in addition to, provide also
audio descriptions (i.e. clips) that are synchronized with the
video and are compatible with the existing audio tracks; these
clips should supply additional descriptions of the video (for
example, as a narrating voice in the background).
Consider also adding to the video a track with a sign
language interpreter for the benefit of people with hearing
disabilities.
- Users:
Search engines
- Group:
Operability
- Wcag 1.0:
1.1, 3.1
- Wcag 2.0:
1.1, 1.1.1, 1.4, 1.4.5
- Italian law:
3
- Cause:
The page contains functional images (clickable links, form
buttons, image maps) that don't have alternative equivalent
text. Similarly for Flash buttons and links.
- Failure mode:
Search engine place a lot of importance to strong visual elements
in pages; links and buttons are such elements. But if they lack a textual
description, then the search engine cannot properly process them.
- Fix:
Include the attribute ALT for the images and the image maps
AREAs; include a textual content for the OBJECTs. Write the text
so that it is informative and that it allows the user to
understand the effects of activating the link.
Consider
doing this also for advertising banners.
Avoid using the
empty ALT (i.e. ALT="") for clickable images (i.e. included
within an A) because they can be reached with the keyboard, and
in such a case the browser does not give any information to the
user who wonders why tabbing brought her/him there.
- Users:
Search engines
- Group:
Operability
- Wcag 1.0:
13.1
- Wcag 2.0:
2.4, 2.4.4, 2.4.9
- Italian law:
19
- Cause:
The page contains links with anchor text that is not
informative as it does not provide clues (for example, "click
here" or "More").
- Failure mode:
Generic links are very poor in terms of information scent,
preventing the search engine to give them the importance they deserve;
this reduces the rank position of the page.
- Fix:
Modify all the link labels so that they provide clues as to
which page will be opened. Do not use "click here", but rather
"details on product XYZ".
- Users:
Search engines
- Group:
Comprehension
- Wcag 1.0:
3.1
- Wcag 2.0:
1.4, 1.4.5, 1.4.9
- Cause:
The page contains words or terms that contain extra spaces,
like in "W E L C O M E", in order to achieve a certain visual effect.
- Failure mode:
Search engines will not index properly the page, since those
spaced letters will not be considered as normal words.
- Users:
Search engines
- Group:
Comprehension
- Wcag 1.0:
13.2
- Wcag 2.0:
2.4, 2.4.2
- Cause:
The page lacks a TITLE tag, or its content provides no
information (like "Untitled document") or it is the same for all
the pages of the website.
- Failure mode:
This barrier is one of the best ways to get a poor ranking of
pages! Search engines place a lot of importance to salient elements,
like page titles.
- Users:
Search engines
- Group:
Comprehension, user control
- Wcag 1.0:
3.5
- Wcag 2.0:
2.4, 2.4.10, 1.3.1
- Cause:
The page does not contain tags H1, H2, ..., H6 for organizing
its content into sections.
- Failure mode:
This barrier is one of the best ways to get a poor ranking of
pages! Search engines place a lot of importance to salient elements,
like page headings.
- Fix:
For each type of content in the page (e.g. navigation bar,
breadcrumbs, sequence of paragraphs, boxed contents) add a new
heading. It can even be hidden using appropriate CSS rules.
Remember to respect their nesting levels: do not skip levels.
- Users:
Search engines
- Group:
Comprehension, Perception
- Wcag 1.0:
3.1
- Wcag 2.0:
1.4, 1.4.5
- Cause:
The page contains titles of categories (e.g. a group of news,
a group of related links) that are implemented through images
that have no ALT text. This occurs for example when certain
items (for example, news) are grouped in a box, and the box is
given a title which is implemented through an image.
- Failure mode:
Yet another missed opportunity to get a good ranking for the
page. This is important text that search engines cannot use.
- Users:
Search engines
- Group:
Perceivability
- Wcag 1.0:
6.3 8.1
- Italian law:
15
- Cause:
To use the page a JavaScript-enabled browser is necessary,
for example because it is part of an AJAX application, or
because a redirect is implemented in JavaScript, or because at
load-time a crucial JavaScript function is invoked.
- Failure mode:
Search engines cannot process JavaScript and will be prevented
from processing and indexing all the content that is generated,
displayed, changed via JavaScript.
On the basis of the user categories taken into account, select the
set of barriers that are relevant to those users.
At this point proceed systematically, by crossing each barrier with
each page, and determine if the barrier is raised by the page in the
context of the considered scenario. If so, determine the severity of the
barrier on the achievement of the user goal by the user and also the
user performance factor that is mostly affected by the barrier
(effectiveness, productivity, satisfaction, or safety).
Notice that a single defect in the page may raise more than
one barrier.
If there are more than one evaluators, then proceed as in heuristic
evaluations:
- first, all evaluators should agree on the user categories to
consider and on the scenarios
- each evaluator should explore those pages and get familiar with
possible goals and interaction mechanisms of the site
- each evaluator independently from the other ones,
should cross all pages with all barriers, and rate severity of each
barrier
- eventually, the evaluators meet once more and merge their
problems into a single list, and assign to each problem a single
severity score.
Consequences of barriers should be described in terms of the following
performance variables:
- effectiveness (i.e. ability to achieve accurately -
execution errors, mistakes or slips - and completely - quality
of the solution - a given goal);
- productivity (i.e. the resources - time, effort, cognitive
load - that are needed in order to reach a certain level of
effectiveness)
- satisfaction (i.e. acceptability and pleasure of use -
frustration, perceived ease of use, perceived productivity,
perceived security)
- security (i.e. personal safety and financial security).
Consider that these variables are not independent; for example
a low level of productivity may require so many resources that the
user prefers to give up; a high level of effectiveness and/or
productivity affects satisfaction; a low level of effectiveness may
lead to low security. In addition the variables can depend on other
factors; for example, a high level of flexibility increases
satisfaction, effectiveness (as alternative course of actions are
available) and productivity (as more suitable courses of actions are
available). Errors (mistakes and slips) affect productivity, which in
turn may affect effectiveness.
I suggest to consider two parameters when estimating the severity
of a barrier: the impact of the barrier on effectiveness,
productivity, satisfaction or safety of a user that is carrying out a
task and the persistency with which the barrier shows up when
carrying out the task.
- Minor problem:
- the barrier is detected
by the user, but there are simple ways to overcome it or to avoid it;
it is easy to remember it, to learn how to avoid or get around it. This
barrier affects marginally productivity or satisfaction, but not
effectiveness nor safety.
- significant problem:
- the barrier is
detected and it heavily affects the task execution. To overcome the
barrier the user has to back-up, follow a trial-and-error strategy,
guess the proper action, repeat an action several times; the user may
incur in errors. In many cases it is not possible to avoid the
barrier, which reduces effectiveness and/or security; even if it can
be avoided, this requires a substantial knowledge and/or memory (to
recall that there is the barrier and on how to avoid it). The barrier
affects effectiveness, productivity, satisfaction and also safety.
- critical problem:
-
the barrier is so big that very often users give up, and they do not
reach their goals. This can happen after users have spent considerable
time and effort to try to overcome the barrier, perhaps with many
errors. There are no alternative ways (known to the users) that can be
followed to achieve the goals.
The barrier has a strong negative impact on effectiveness, and
consequently also on productivity, satisfaction and safety.
When considering persistency of the barrier, determine how often
the barrier shows up during a task execution by a user. Do not
consider however how many users can execute that task, nor how frequent
is that task (we want to characterize the severity of the barrier in
general, not to determine the proportion of the website audience that
is affected by the barrier).
Use a scale of 1 to 3 (3 is the worst case) for each of the two
parameters; then use the following table to assign the severity score,
and classify the problems as critical (score =3),
significant (score = 2) or minor (score = 1).
Figure 1: Table for computing the severity
score of problems| Impact | Persistence | Severity |
|---|
| 1 | 1 | minor |
| 1 | 2 | minor |
| 1 | 3 | significant |
| 2 | 1 | significant |
| 2 | 2 | significant |
| 2 | 3 | critical |
| 3 | 1 | critical |
| 3 | 2 | critical |
| 3 | 3 | critical |
The following tables can be used when carrying out a barrier
walkthrough evaluation. For each page you should fill-in the tables
for the user categories that are to be considered. Consider that there
might be several instances of a barrier type (hence, you'll need to
repeat some rows).
Of course, in addition to finding out barriers
and rating their severities, you'll want to add details about the
specific failures, causes and remedies (screenshots, code
details, arguments justifying your choice of severity, suggestions).
See also this spreadsheet.
Evaluation table for Blind persons
Evaluation table for Low-vision users
Evaluation table for Color-blind users
Evaluation table for Motor impaired users
Evaluation table for Deaf users
Evaluation table for Cognitive disabilities
Evaluation table for Users of browsers where JavaScript is disabled
Evaluation table for Search engines
@