(The content of the page was last updated by Giorgio Brajnik on 2011)
Introduction
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.
User categories
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.
User goals
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.
Possible barriers
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.
Possible barriers for blind persons
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
Rich images lacking equivalent text
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Video with no captions
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Color is necessary
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Inaccessible frames
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Italian law:
- 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.
Moving content
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Image maps with no text
- Users:
-
Blind persons
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Functional images embedded in the background
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Functional images lacking text
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Generic links
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Ambiguous links
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Dynamic menus in JavaScript
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Mouse events
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Opaque objects
- Users:
-
Blind persons
- Group:
-
Perception, Operability
- Wcag 1.0:
- Wcag 2.0:
- 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.
keyboard traps
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
ASCII art
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
-
1.1,
- Italian law:
- 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.
Spaced titles
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
Too many links
- Users:
-
Blind persons
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Form with redirect
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- 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.
Non separated links
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- 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.
New windows
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Forms with no LABEL tags
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Forms that are badly linearized
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Too short timings
- Users:
-
Blind persons
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Data tables with no structural relationships
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Data tables with no summary
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Italian law:
- 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).
Layout tables
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Page without titles
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
Frame without title
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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).
Language markup
- Users:
-
Blind persons
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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/>".
No page headings
- Users:
-
Blind persons
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Images used as titles
- Users:
-
Blind persons
- Group:
-
Comprehension, Perception
- Wcag 1.0:
- Wcag 2.0:
- 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.
No keyboard shortcuts
- Users:
-
Blind persons
- Group:
-
User control
- Wcag 1.0:
- 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.
Skip links not implemented
- Users:
-
Blind persons
- Group:
-
User control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Text-only page
- Users:
-
Blind persons
- Group:
-
User control
- Wcag 1.0:
- Italian law:
- 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.
Window without browser controls
- Users:
-
Blind persons
- Group:
-
User control
- Wcag 1.0:
- 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).
Dynamic changes
- Users:
-
Blind persons
- Group:
-
Perceivability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Possible barriers for persons with low vision
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
Rich images that are badly positioned
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Rich images included in the page background
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Italian law:
- 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.
Color is necessary
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Insufficient visual contrast
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Inaccessible frames
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Italian law:
- 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.
Moving content
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Image maps
- Users:
-
Low-vision users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Functional images embedded in the background
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Functional images lacking text
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Too long tooltips
- 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.
Dynamic menus in JavaScript
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Internal links are missing
- 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.
Too long lines of text
- 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.
Too many links
- Users:
-
Low-vision users
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Form with redirect
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- 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.
Widely formatted forms
- 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.
Overlapping windows
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Too short timings
- Users:
-
Low-vision users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Images used as titles
- Users:
-
Low-vision users
- Group:
-
Comprehension, Perception
- Wcag 1.0:
- Wcag 2.0:
- 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.
No keyboard shortcuts
- Users:
-
Low-vision users
- Group:
-
User control
- Wcag 1.0:
- 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.
Text cannot be resized
- Users:
-
Low-vision users
- Group:
-
User control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Inflexible page layout
- Users:
-
Low-vision users
- Group:
-
User control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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).
Missing layout cues
- 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.
Skip links not implemented
- Users:
-
Low-vision users
- Group:
-
User control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Window without browser controls
- Users:
-
Low-vision users
- Group:
-
User control
- Wcag 1.0:
- 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).
Sortable data table
- 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.
Dynamic changes
- Users:
-
Low-vision users
- Group:
-
Perceivability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Possible barriers for persons with color deficiencies
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
- Users:
-
Color-blind users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Insufficient visual contrast
- Users:
-
Color-blind users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Possible barriers for persons with motor disabilities
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
Cascading menu
- 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).
Mouse events
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Opaque objects
- Users:
-
Motor impaired users
- Group:
-
Perception, Operability
- Wcag 1.0:
- Wcag 2.0:
- 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.
keyboard traps
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Internal links are missing
- 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.
Too many links
- Users:
-
Motor impaired users
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Links/buttons that are too close to each other
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Italian law:
- 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.
Links/buttons that are too small
- Users:
-
Motor impaired users
- Group:
-
Operability
- Italian law:
- 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.
New windows
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Forms with no LABEL tags
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Too short timings
- Users:
-
Motor impaired users
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
No keyboard shortcuts
- Users:
-
Motor impaired users
- Group:
-
User control
- Wcag 1.0:
- 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.
Skip links not implemented
- Users:
-
Motor impaired users
- Group:
-
User control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Window without browser controls
- Users:
-
Motor impaired users
- Group:
-
User control
- Wcag 1.0:
- 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).
Possible barriers for hard of hearing persons
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
- Users:
-
Deaf users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- 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.
Video with no captions
- Users:
-
Deaf users
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Missing synchronization
- Users:
-
Deaf users
- Group:
-
Perception and user control
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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).
Possible barriers for cognitively disabled persons
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
Rich images lacking equivalent text
- Users:
-
Cognitive disabilities
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Video with no captions
- Users:
-
Cognitive disabilities
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Moving content
- Users:
-
Cognitive disabilities
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Generic links
- Users:
-
Cognitive disabilities
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Ambiguous links
- Users:
-
Cognitive disabilities
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Internal links are missing
- 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.
Missing icons
- Users:
-
Cognitive disabilities
- Group:
-
Comprehension
- Wcag 1.0:
- 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.
Complex text
- Users:
-
Cognitive disabilities
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
Complex site
- Users:
-
Cognitive disabilities
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
Too many links
- Users:
-
Cognitive disabilities
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Text fields with no example
- 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.
New windows
- Users:
-
Cognitive disabilities
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Too short timings
- Users:
-
Cognitive disabilities
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
No page headings
- Users:
-
Cognitive disabilities
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Text-only page
- Users:
-
Cognitive disabilities
- Group:
-
User control
- Wcag 1.0:
- Italian law:
- 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.
Complex data table
- 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.
Acronyms and abbreviations without expansions
- Users:
-
Cognitive disabilities
- Group:
-
Understandability
- Wcag 1.0:
- Wcag 2.0:
- 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.
Possible barriers for users of JavaScript uncapable devices
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
Dynamic menus in JavaScript
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Cascading menu
- 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).
Mouse events
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Automatically populated form controls
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- 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.
Form with redirect
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- 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.
Fields validation
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- Italian law:
- 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.
Hidden fields
- 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.
New windows
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Window without browser controls
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
User control
- Wcag 1.0:
- 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).
JavaScript is necessary
- Users:
-
Users of browsers where JavaScript is disabled
- Group:
-
Perceivability
- Wcag 1.0:
- Italian law:
- 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.
Possible barriers for users with photosensitive epilepsy
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:
- Wcag 2.0:
- Italian law:
- 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.
Possible barriers for search engines
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
Rich images lacking equivalent text
- Users:
-
Search engines
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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).
Rich images included in the page background
- Users:
-
Search engines
- Group:
-
Perception
- Wcag 1.0:
- Italian law:
- 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.
No captions for audios
- Users:
-
Search engines
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- 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.
Video with no captions
- Users:
-
Search engines
- Group:
-
Perception
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Functional images lacking text
- Users:
-
Search engines
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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.
Generic links
- Users:
-
Search engines
- Group:
-
Operability
- Wcag 1.0:
- Wcag 2.0:
- Italian law:
- 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".
Spaced titles
- Users:
-
Search engines
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
Page without titles
- Users:
-
Search engines
- Group:
-
Comprehension
- Wcag 1.0:
- Wcag 2.0:
- 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.
No page headings
- Users:
-
Search engines
- Group:
-
Comprehension, user control
- Wcag 1.0:
- Wcag 2.0:
- 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.
Images used as titles
- Users:
-
Search engines
- Group:
-
Comprehension, Perception
- Wcag 1.0:
- Wcag 2.0:
- 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.
JavaScript is necessary
- Users:
-
Search engines
- Group:
-
Perceivability
- Wcag 1.0:
- Italian law:
- 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.
Procedure
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.
How to assign severity scores
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).
- Give minor if impact is 1 and persistence 1 or 2
- Give critical if impact is 3 or if persistence is 3
- Give significant otherwise.