The page contains images, objects or applets. There might be cases where the contrast between foreground and background colors is not sufficient to differentiate them.
There are many situations where a poor choice of color hinders perception and comprehension of some information item or image in a page.
This may depend on many factors including:
From the W3C guidelines:
Guideline 2. Don't rely on color alone.
Ensure that text and graphics are understandable when viewed without color.
If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits.
Check that colors and colored items in the page can be clearly
differentiated in all the possible contexts in which website visitors may be
using the page.
Make sure that the contrast between foreground and background items is
conveyed by other means in addition to colors, such as levels of
luminosity (i.e. black and white contrast), different font styles,
font sizes, or font faces.
If color is used, consider exaggerating the differences between foreground and background colors by making colors differ in all the following three parameters:
Easy ways to test the page are:
The page contains images that might contain information
that is not appropriately marked up in HTML.
For example, MathML may be used to mark up mathematical equations, and
style sheets to format text and control
layout.
It is best to avoid using images to represent text. A better choice would be to use text and style sheets.
The W3C states (http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure):
When designing a document or series of documents, content developers should strive first to identify the desired structure for their documents before evaluating how the documents will be presented to the user. Distinguishing the structure of a document from how the content is presented offers a number of advantages, including improved accessibility, manageability, and portability.
Identifying what is structure and what is presentation may be challenging at times. For instance, many content developers consider that a horizontal line communicates a structural division. This may be true for sighted users, but to unsighted users or users without graphical browsers, a horizontal line may have next to no meaning. For example, in HTML content developers should use the HTML 4.01 heading elements (H1-H6) to identify new sections. These may be complemented by visual cues or other means such as horizontal rules, but should not be replaced by them.
The opposite holds true as well. Content developers should not use structural elements to achieve presentation effects. For instance in HTML, even though the BLOCKQUOTE element may cause indented text in some browsers, it is designed to identify a quotation, not to create a presentation side-effect. BLOCKQUOTE elements used for indentation confuse users and search robots alike, who expect the element to be used to mark up block quotations.
To determine if content is structural or presentational, create an outline of the document. Each point in the hierarchy denotes a structural change. Use structural markup to mark these changes and presentational markup to make them more apparent visually and aurally. Notice that horizontal rules will not appear in this outline and therefore are not structural, but presentational. Note: This quick test addresses chapter, section, and paragraph structure. To determine structure within phrases, look for abbreviations, changes in natural language, definitions, and list items.
In another document (&wcag;) it says:
Guideline 3. Use markup and style sheets and do so properly.
Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.Using markup improperly (not according to specification) hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup to convey structure (e.g., constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly to other devices [...] .
Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. These practices cause accessibility problems. It is best to consider whether the formatting effect is critical enough to warrant making the document inaccessible to some users.
At the other extreme, content developers must not sacrifice appropriate markup because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information even though some older screen readers may not handle side-by-side text correctly (refer to checkpoint 10.3). Using TABLE correctly and creating tables that transform easily (refer to guideline 5) makes it possible for software to render tables in a way other than as two-dimensional grids.
If the image contains
The guideline requires that the page is valid.
By using appropriate coding standards, it is possible to develop documents that are guaranteed to be potentially (and eventually) compatible with all types of Internet browsers and agents.
In contrast, coding for a specific browser type and version, May lead to documents that are unreadable as new versions of that browser are developed, and as new browsers are used. Consider that in addition to mainstream browsers, website visitors may also use speaking browsers (e.g. Home Page Reader), text only browsers (e.g. lynx), or mini browsers on PDAs and cell phones. In addition to human visitors, the site may be visited by crawlers of search engines and of more specialized information gathering agents. These will also benefit from a document that is compliant with known standards.
Using syntax validators will help to determine if there are mistakes in the documents; mistakes that were inserted inadvertently into the document that could lead to unexpected, and sometimes undetected, accessibility issues.
Make sure that the page contains valid code. Use the Markup Validator, the XML Validator or a CSS validator to check if there are problems and to find viable solutions.
Make sure the page contains absolutely valid code.
The DOCTYPE element is missing or is not valid.
According to HTML standards, each HTML document requires a Document Type Declaration. The "DOCTYPE" begins the HTML document and tells which version of HTML to expect when processing the document.
The DOCTYPE declaration identifies the computer language and version
in which the document has been coded. With this information
browsers can interpret accessibility features in the document
correctly.
This requirement is important for accessibility
because assistive technologies may rely on this declaration to
determine how to process the document.
When using non-HTML documents (for example when using SMIL or SVG) use the appropriate DOCTYPE declaration for that markup language to ensure that browsers do not attempt to interpret it incorrectly as HTML.
If the DOCTYPE element is missing, then add one. If it is not valid,
then edit and correct it.
Check the validity of the DOCTYPE by using the Validator.
The DOCTYPE should contain the HTML language version that is used. For example, HTML 4.01 can be based on three different
variants (i.e. three DTDs). It is important to include one of the
following document type declarations in the documents.
The DTDs vary in the elements they support.
To define the DOCTYPE of the page include one of the following
just before the HTML tag, at the beginning
of the document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
The following DOCTYPE is for XHMTL strict (and similar ones exist for
the Transitional and Frameset flavors: see the XHTML 1.0 page by W3C):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
The page contains tags or attributes that are deprecated (i.e. that have disappeared from HTML 4.01, and whose usage is discouraged by the W3C). These tags/attributes can be safely replaced with appropriate CSS rules.
See the list of HTML 4.01 deprecated tags.
By using CSS presentation rules rather than (deprecated) HTML tags and attributes the following advantages are achieved:
Replace the deprecated tags and attributes by appropriate CSS
properties and rules. For example, use the CSS 'font' properties (e.g.
font-size, font-family, font-weight) instead of the
HTML FONT element to control font styles; use style="{float:
left}" instead of align="left"; use
style="border:none" instead of border="0"
(within IMG tags).
See the list of HTML 4.01 deprecated tags.
The page contains frameset(s) that specify frame size using absolute, rather than relative, units.
Whenever possible it is best to use relative units.
Use percentage units rather than absolute units for frame height and width.
In this way the visual layout of the page will be "liquid", in the sense that it can adapt to the specific browser being used and the specific screen that supports it.
In the specific case of frames, using percentage values has the advantage that the browser user (the website visitor) can resize the entire window, or single frames at will without affecting the ability to experience the content of the page.
Use percentage values rather than absolute values. Replace the values in the attributes ROWS and/or COLS of the frameset with percentage values.
The page contains tables that specify width and/or height for rows and/or columns in absolute units rather than relative ones, like percentages.
Whenever possible it is best to use relative units.
Use percentage units rather than absolute ones for tables' height and width.
In this way the visual layout of the page will be "liquid", in the sense that it can adapt to the specific browser being used and the specific screen that supports it.
In the specific case of tables, using percentage values has the advantage that the browser user (the website visitor) can resize the entire window at will without affecting the ability to experience the content of the page.
For table and table cells sizes use percentage values rather than absolute values. Replace the values in the attributes WIDTH and/or HEIGHT of TABLE, TH or TD elements with percentage values.
The page refers to CSS properties that are specified using absolute units (such as 'in', 'px', 'mm') rather than relative units (such as '%', 'em'). These units are used in STYLE attributes or in external CSS files linked to via the LINK element.
Whenever possible it is best to use relative units.
In this way the visual layout of the page will be "liquid", in the sense that it can adapt to the specific browser being used, the specific screen that supports it, and the font size that a user might want to select as a default.
Use relative rather than absolute units in style sheet property values. Replace all occurrences of units like 'px', 'pt', 'pc', 'cm', 'mm' with percentages or 'em'.
Use absolute units only when the type of device that will be used by the website visitor is certain (like a webTV), or in cases where the object to be displayed has a geometry that cannot be changed without becoming distorted (like a gif image).
It is best to avoid using absolute units for font size.
The page refers to CSS properties that are specified using absolute units (like 'in', 'px', 'mm') rather than relative ones (like '%', 'em'). These units are used in STYLE attributes or in external CSS files linked to via the LINK element.
Whenever possible it is best to use relative units.
In this way the visual layout of the page will be "liquid", in the sense that it can adapt to the specific browser being used, the specific screen that supports it, and the font size that a user might want to select as a default.
Use relative rather than absolute units in style sheet property values. Replace all occurrences of units like 'px', 'pt', 'pc', 'cm', 'mm' with percentages or 'em'.
The page does not contain header element (H1, H2, ... or H7).
Use HTML headers (H1, H2, ..., H7) to create a hierarchy of different sections of content shown in the page.
In this way, visitors of the website can glance through an outline of the document and identify the part that is most useful without having to read through all of the text.
In addition, with several reading browsers or screen readers it is possible to obtain a list of all the headers included in the document and jump directly to a specific header. This is very beneficial to people who cannot see the document if, for example, they are visually impaired, blind or they access the web through a telephone service. This way the visitor does not have to listen to every word of the text before reaching the content that is of most interest.
Include one or more header elements in the document. Respect the hierarchical levels: for example, jump from H1 to H2, but avoid 'gaps' like jumping from H1 to H3.
A quick test to determine which headers are needed is to create an outline of the content of the page. Start with a level (for example, H3) and mark subsequent sections of the outline with that header ( H3). When a more detailed section in the Outline is reached, use a higher level of header (like H4).
If the default formatting of the headers is not acceptable, define a CSS class with the desired properties, and use that class every time a header is used.
The page contains header elements (H1, H2, ... or H7).
Use HTML headers (H1, H2, ..., H7) according to specification.
Respect the hierarchical levels: jump from H1 to H2, but avoid 'gaps' like jumping from H1 to H3.
The page contains at least one pair of identical images that are not spacers and that might be used as bullets in a table-formatted list of items.
Whenever visual clues are used (e.g. indenting) to suggest appropriate nesting of content items, it must be noted that those clues will not be available to people who cannot use or take advantage of two-dimensional graphic rendering. This includes visually impaired and blind persons, as well as those using a non-graphical browser, like a reading browser for telephone or a small PDA screen.
It is therefore important to use the appropriate structural markup that HTML offers to encode such important clues. A user of a screen reader or of a speaking browser can navigate through the levels of nested lists if they are properly encoded. They can jump directly to a certain item.
If multiple levels of ordered (numbered) lists are used, ensure that the numbered headings that are shown contain contextual information. For example the items of the second level list should be numbered like 1.1, 1.2 ... or 1.a, 1.b, etc. Since users can navigate freely, the goal of using contextual information is that when an item is read, potentially out of context, it will contain enough information for the listener to understand which item of which list is being read.
If the same items were numbered, for example: 1, 2, 3, etc.,then the listener would not be able to differentiate when the items are part of a secondary list.
Check if the images used in this page are used as bullets in itemized lists of objects. If this is the case, replace the table and images with the appropriate markup. Use a list as a wrapper and a list item (LI or DD and DT) to mark each item within these lists.
Use unordered lists (UL), ordered (i.e. numbered) lists (OL), or definition lists (DL). Lists can be nested in various ways, for example, by using a UL within a LI of an OL. It is also possible to change the symbol that is used as a bullet by using the appropriate CSS property (list-style).
More details can be found on &w3c_html_tech;.
The page may contain quotations (references to comments made by an outside source) that are not properly coded in HTML.
Appropriate markup of quotations is useful for website visitors using screen readers or reading browsers because the browser may use a different voice or a different pitch when reading the quotations.
In this way the listener is able to perceive the difference in the discourse.
Check if the page contains quotations (i.e. references comments made by an outside source). If so, ensure that they are correctly marked up in HTML with BLOCKQUOTE or with Q elements. A better option would be if the formatting properties are specified with CSS rules.
Use the BLOCKQUOTE element to mark up a long quotation (one or more paragraphs long). Use the Q element to quote a shorter sentence. (BLOCKQUOTE is a block-level tag; Q is an inline-level tag.)
The page contains text that is marked up with BLOCKQUOTE or with Q. If this text is not a quotation, then the HTML code should be changed.
Misusing these tags (for achieving certain formatting effects) hinders accessibility. When a screen reader or reading browser reads the improperly marked up text, it will use a special voice or pitch to make it clear to the listener that it is a quotation (i.e. a reference to comments made by an outside source).
A listener would be confused if the "quotation" is indeed a part of the content of the page that was simply embedded in BLOCKQUOTE or Q for formatting purposes.
Please check if the text included in the BLOCKQUOTE (or Q) element in the page is indeed a quotation.
If not, consider removing the BLOCKQUOTE (or Q) tag and replace it with a DIV (or SPAN) tag associated to a CSS class that specifies the formatting properties would be achieved with BLOCKQUOTE (or Q).
The page contains at least one table that is supposed to be for layout purposes (i.e. it does not contain CAPTION, THEAD, TH and TFOOT).
When linearized, its contents should be read in the expected order and should make sense.
Often when accessibility is considered only after page templates have been defined and implemented, the table organization used to lay out the content on a page does not function properly with non-graphical browsers.
The most common mistake is to forget that HTML tables lay out the information row by row.
Non-graphical browsers follow the row by row order when presenting the content of the table. Even if visual clues would suggest a column by column reading order.
Consider the following example (from &w3c_html_tech;):
... if a table is rendered like this on the screen:
There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before the weekend.This might be read by a screen reader as:
There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before the weekend.
Linearization is the process of transforming a two-dimensional structure, like a table, into a mono-dimensional structure. It is the process that any speaking browser or screen reader has to follow in order to render the content of the page via audio.
Make sure that, when linearized, the content of the layout tables used in the page can be read in the appropriate order. This is conceptually easy: just imagine stripping out all of the tags.
In certain cases, it is also possible to check by running a piece of paper down the page and reading the page line by line to provide some clues of possible problems.
Consider that tables used to present tabular data should not be linearized as suggested here. They have to be appropriately marked up (with TH, SCOPE, AXIS, ID and HEADERS tags and attributes) to be accessible. Other tests within this program implement the appropriate WCAG or Section 508 guidelines.
The page contains a table that appears to be used to present tabular information, rather than to layout the page. ("Tabular information" means that the two-dimensional grid offered by the table is used to represent logical relationships among the data included in table cells).
Make sure that the table is indeed used to present tabular information.
If the table does not represent relationships between information items, but is solely used for implementing a grid on the screen, then the page fails this test.
Using markup like TH for its visual effect hinders accessibility. In fact, some assistive technology, like reading browsers, uses the content of the TH element when the user navigates through a table. Each time a user visits a cell of the table, the browser will try to locate the corresponding header cell (that is marked with a TH) and read its content. In this way the user is able to understand what the context is for the cell being visited.
However, if THs are used for visual purposes only, then to the reading browser user the context will appear very chaotic and confusing.
Inspect the table and its content to determine if the table is used to present tabular information.
If it is used for layout purposes only, it should not use tags like CAPTION, TH, THEAD, TFOOT to obtain special formatting effects.
Remove CAPTION, THEAD and TFOOT, and replace all the TH with corresponding TDs. Then define a CSS class with the formatting properties that are necessary (like "font-weight: bold; text-align: center;") and add that class to each newly created TD.
The page contains handlers for some mouse event for which there is no corresponding keyboard event handler.
In particular:
An event handler is a script that is invoked when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.). Event handlers are attached to HTML elements via event handler attributes (like "ONMOUSEDOWN", "ONCLICK", "ONKEYUP", etc.).
Often the effect of an event handler is purely decorative:
highlighting some text, or an image, or changing the color of some
portion of the page. In other cases, however, the event handler performs
more important activities: it validates the inputs to a form; shows
a rollover menu; opens up a new window; etc.
In all of these cases, where the content being provided changes or the
navigation options offered to the visitor change, the event handler
must be made fully accessible to offer the same changes to
users of assistive or limited technology.
If an event handler refers only to a specific device (like the mouse, as is the case with "ONMOUSEOVER" for example) then for a browser user with no mouse (for example a user with motor disabilities or a driver having to view the website on a PC installed in a car) would not be able to experience the effect of the handler.
According to the W3C, device independence means (&wcag;):
Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.
Inspect all of the event handlers defined in the page. Consider only those handlers that either change the page content (by adding or removing text, images, layers, or other objects) or the navigation options (menus, new windows, navbars, links).
If any of these are specified using device dependent events (i.e. ONDBLCLICK, ONCLICK, ONKEYPRESS, ONKEYDOWN, ONMOUSEDOWN, ONKEYUP, ONMOUSEUP, ONMOUSEOVER, ONMOUSEOUT, ONFOCUS, ONBLUR) then they should be paired with event handlers for the other device as well.
In particular:
The page contains a link that can be followed only by browsers that support JavaScript.
Links that activate scripts can only be followed by browsers capable of executing JavaScript. Not all browsers are able to execute JavaScript. Consider for example textual browsers like lynx, or browsers coupled with screen readers, or browsers for PDAs or cellular phones.
A user with such browsers would not be able to navigate the page. Even if other ways to reach that destination are available (i.e. links or buttons), the user would face such a link, and assume that it would work as any other does. However, the browser's failure to follow it the link could possibly increase user frustration and confusion.
Replace the link that directly starts the script with other ways to start it, like defining a button, separately defining the script (remember also the NOSCRIPT element) and binding an event (like ONKEYPRESS and ONCLICK) on the button to the script.
The <NOFRAMES> element is not present or it does not contain a link to an alternative version of the page.
Without specifying a <NOFRAMES> element, the site may appear as a blank page to users with browsers unable to handle frames, such as early versions of popular browsers and current special-purpose browsers like voice-enabled computers and browsers for PDAs.
The <NOFRAMES> element should be used to provide users of
browsers unable to handle frames an alternative way to access the site,
possibly with degraded graphic and interaction quality.
For example, a <NOFRAMES> element containing text stating that the page
cannot be displayed by the browser being used
does not help users access the page.
A valid NOFRAMES section should exist within the outer FRAMESET section.
Remember that a NOFRAMES section is valid if it:
A NOFRAMES element that does not contain links prevents the reader from accessing the same navigation options offered to those with frames-enabled browsers.
Consider adding the following HTML code before the last </FRAMESET> tag in the document:
<NOFRAMES>
<P>Here is the <A href="main-noframes.html">
non-frame based version of the document.</A></P>
</NOFRAMES>
The page uses scripts that may change the content or the navigation options of the document. All of these scripts should change the page in such a way that assistive technologies can recognize these changes and appropriately notify can be given to the website visitor.
It is best to avoid using scripts to create new content or navigation options. Visitors with browsers that do not support the scripts will not get that content or those options.
The W3C says (&w3c_html_tech;):
Content developers must ensure that pages are accessible with scripts turned off or in browsers that don't support scripts.
- Avoid creating content on the fly on the client. If a user's browser does not handle scripts, no content will be generated or displayed. However, this is different than displaying or hiding already existing content by using a combination of style sheets and scripting; if there is no script, then the content is always shown. This also does not rule out generating pages on the fly on the server-side and delivering them to the client.
- Avoid creating links that use "JavaScript" as the URI. If a user is not using scripts, then they won't be able to link since the browser can't create the link content.
Check if the scripts used by this page do create new content or navigation options. An easy way for testing this is to disable script execution on the browser and use the page.
If some scripts add new content or navigation options, then it is best to find an alternative way to achieve the desired effects.
For example, would a server-side script (and a form) achieve the same effect? Is it possible to make the page show its entire content if the browser does not support scripts (for example by defining several layers)?
If all the content is defined within layers, and the script is used to make a layer appear only when certain conditions occur, then browsers that do not support scripts will render all the layers in the order in which they are defined in the HTML file. In this case, it is best to ensure that this way of presenting the content is effective enough (for example by providing appropriate context for each of the layers).
The page contains the BLINK tag, which is a non standard tag.
The BLINK tag will turn on and off its content. The user of the browser will in no way be able to stop this on/off behavior.
This blinking behavior is very distracting to the eye, and will make it very difficult to concentrate on the task of reading the information in the page or in filling in the form contained in the page.
The consequences will be even more significant on users that suffer from cognitive disorders, as they will have a very hard time concentrating on the page content. Consider also users of screen magnifiers who may read a small portion of the page that overlaps with the blinking text. In these cases, a large part of the magnified screen will blink; again making it very hard for these users to concentrate on the task.
Consider that, in a sense, everyone is cognitively disabled when under stress. For example, when buying an e-ticket for a flight from a kiosk in a very noisy and crowded airport, with a long line of people waiting for the same kiosk, most people will be unable to fully concentrate on the task. A blinking element in the page will not help the user to complete the purchase.
Replace the BLINK tag with another formatting property that does not require the text to appear and disappear with no control given to the website visitor.
Remember that the W3C (&w3c_html_tech;) suggests not to use BLINK and neither MARQUEE.
If blinking effect is required, implement it using the css property 'text-decoration: blink'. In this way the end result will be the same, however:
The page contains objects (scripts, applets, HTML objects) that might cause blinking on the screen. If this is the case, it is best to modify or remove them.
The object (script, applet, HTML objects) causes blinking and the user of the browser will in no way be able to stop this on/off behavior.
This blinking behavior is very distracting to the eye, and will make it very difficult to concentrate on the task of reading the information in the page or in filling in the form contained in the page.
The consequences will be even more significant on users that suffer from cognitive disorders, as they will have a very hard time concentrating on the page content. Consider also users of screen magnifiers, who may read a small portion of the page that overlaps with the blinking text. In these cases, a large part of the magnified screen will blink; again making it very hard for these users to concentrate on the task.
Consider that, in a sense, everyone is cognitively disabled when under stress. For example, when buying an e-ticket for a flight from a kiosk in a very noisy and crowded airport, with a long line of people waiting for the same kiosk, most people will be unable to fully concentrate on the task. A blinking element in the page will not help the user to complete the purchase.
Check if the object causes blinking (i.e. a constant on/off behavior of part of the screen) that does not stop and that cannot be stopped by the website visitor.
If so, modify the object behavior so that no blinking occurs, or so that the visitor has the means to stop it from blinking. Alternatively ,set the object to blink a couple of times and then come to rest.
The page contains images that might cause blinking on the screen. If this is the case, it is best to modify or remove them.
The image causes blinking and the user of the browser will in no way be able to stop this on/off behavior.
This blinking behavior is very distracting to the eye, and will make it very difficult to concentrate on the task of reading the information on the page, or filling in the form contained on the page.
The consequences will be even more significant for users that suffer from cognitive disorders, as they will have a very hard time concentrating on the page content. Consider also users of screen magnifiers who may read a small portion of the page that overlaps with the blinking content. In these cases, a large part of the magnified screen will blink; again making it very hard for these users to concentrate on the task at hand.
Consider that, in a sense, everyone is cognitively disabled when under stress. For example, when buying an e-ticket for a flight from a kiosk in a very noisy and crowded airport, with a long line of people waiting for the same kiosk, most people will be unable to fully concentrate on the task. A blinking element in the page will not help the user to complete the purchase.
Check if the image causes blinking (i.e. a constant on/off behavior of part of the screen) that does not stop and that cannot be stopped by the website visitor.
If so, modify the image so that no blinking occurs, or so that it blinks a couple of times and then comes to rest.
The page contains images that might have moving content. If this is the case, it is best to modify or remove them.
The image has moving content, and the user of the browser will in no way be able to stop this behavior.
This behavior is very distracting to the eye, and will make it very difficult to concentrate on the task of reading the information in the page or filling in the form contained in the page.
The consequences will be even more significant on users that suffer from cognitive disorders, as they will have a very hard time concentrating on the page content. Consider also users of screen magnifiers who may read a small portion of the page that overlaps with the moving part. In these cases, a large part of the magnified screen will display a portion of the content that will move out of sight or change. The user will need to continuously reposition the screen magnifier by tracking the moving content, making it extremely hard for these users to concentrate on the task at hand.
Consider that, in a sense, everyone is cognitively disabled when under stress. For example, when buying an e-ticket for a flight from a kiosk in a very noisy and crowded airport, with a long line of people waiting for the same kiosk, most people will be unable to fully concentrate on the task. A moving element in the page will not help the user to complete the purchase.
Check if the image has moving content that does not stop and that cannot be stopped by the website visitor.
If so, modify the image so that no movement occurs, or so that the movement occurs only a couple of times and then comes to rest.
The page contains scripts, applets or objects that might have moving content. If this is the case, it is best to modify or remove them.
The object has moving content, and the user of the browser is in no way able to stop this behavior.
This behavior is very distracting to the eye, and will make it very difficult to concentrate on the task of reading the information on the page or filling in the form contained in the page.
The consequences will be even more significant on users that suffer from cognitive disorders, as they will have a very hard time concentrating on the page content. Consider also users of screen magnifiers who may read a small portion of the page that overlaps with the moving part. In these cases, a large part of the magnified screen will display a portion of the content that will move out of sight or change. The user will need to continuously and accurately reposition the screen magnifier by tracking the moving content, making it extremely hard for these users to concentrate on the task at hand.
Consider that, in a sense, everyone is cognitively disabled when under stress. For example, when buying an e-ticket for a flight from a kiosk in a very noisy and crowded airport, with a long line of people waiting for the same kiosk, most people will be unable to fully concentrate on the task. A moving element in the page will not help the user to complete the purchase.
Finally, consider that screen readers are unable to read moving text.
Check if the object causes moving content that does not stop and that cannot be stopped by the website visitor.
If so, modify the object so that no movement occurs, or so that the movement occurs only a couple of times and then comes to rest. As a better choice, modify the object so that the website visitor can decide to stop the movement.
The page contains the MARQUEE element which creates a scrolling text area.
Animated features within a page negatively affect the way in which a user looks and reads the page content. Users will be continuously distracted away from the most important page content.
In addition, users browsing this page with a browser that cannot understand the MARQUEE element will be presented with a page that does not work as intended.
Many browsers don't support MARQUEE, like Netscape Navigator and Opera. In addition, MARQUEE is not a standard HTML 3.2 or HTML 4.0 tag.
Try to avoid using that animation effect. Try substituting it with a table layout or, as a better choice, with a clever usage of CSS properties.
Remember that the W3C (HTML Techniques for Web Content Accessibility Guidelines 1.0) suggests not to use BLINK and neither MARQUEE.
The page is automatically updated after a given time. It is best to remove this behavior.
Pages that are automatically updated may pose significant problems to users who are disabled or who use technology that hinders normal interaction patterns.
For example, screen readers might not be working properly when the page updates, or people with physical disabilities might not be able to move quickly or accurately through the page content and navigation items. Users without disabilities may also face problems if, for various reasons, they are slow in reading the page; for example if they use a very slow Internet connection, or if they use a small screen that forces them to slow down the reading pace.
Until browsers will allow users to turn off these automatically updating features, do not use auto-refresh.
Until browsers will allow users to turn off these automatically updating features, do not use auto-refresh or auto-redirect.
Try to achieve a similar effect by specifying cache expiration dates and by appropriately configuring the web server. This would not affect the accessibility of the pages because they would change only as an effect of the user explicitly reloading the page on the browser.
When this page is loaded by the browser, after a given amount of time a new page is automatically loaded and displayed. It is best to remove this behavior.
Pages that are automatically updated may pose significant problems to users who are disabled or use technology that hinders normal interaction patterns.
People with disabilities might not be able to move quickly or accurately through the page content and navigation items before it changes. Users without disabilities may also face problems if, for various reasons, they are slow in reading the page; for example, if they use a very slow Internet connection, or if they use a small screen that forces them to slow down the reading pace.
Until browsers will allow users to turn off these automatically updating features, do not use auto-refresh.
Until browsers will allow users to turn off these automatically updating features, do not use auto-refresh or auto-redirect.
If auto redirect is needed, then implement it using the redirection capabilities offered by the server and by allowing the user to specify when to load the next page. This would not affect accessibility of the pages because the page would change only as an effect of the user explicitly (re)loading the page.
If this is not possible, and the redirect META tag is still required, then it is best to enrich the two pages with links that connect them, in both directions. In this way, if the redirect is too fast, the visitor at least has the ability to go back to the previous page. If the redirect is too slow, the visitor has the ability to move forward at will.
Please notice that this solution, although more usable than the META redirect alone, does not satisfy the current guideline/checkpoint.
The page contains a jump menu (i.e. a menu with a list of options each leading to a different page) based on a SELECT element with an ONCHANGE event handler that loads another page. This behavior prevents visitors using keyboards to scroll through the list to select an option.
The JavaScript code associated with the SELECT element does not allow the user to scroll through the available options when using a keyboard. It is not device independent.
JavaScript code is device independent if:
users can interact with a website using input and output devices of
their choice. Input devices may include pointing devices, keyboards,
Braille devices, microphones, and others. Output devices
may include monitors, speech synthesizers, and Braille devices.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command line interface.
Remember also that a jump menu works only if
JavaScript is enabled and available on users' browsers. There are
browsers that do not support JavaScript (e.g. for cell phones and
PDAs) and there are organizations that turn off JavaScript from
normal browsers for security reasons.
Include a NOSCRIPT tag
with alternative and equivalent content and interaction (i.e. links
and forms).
Consider also writing a server-side script to process the URLs passed by the menu and to deliver the appropriate page.
There are two steps to make the jump menu device independent:
When adding a Dreamweaver jump menu object to the document, it is possible to automatically insert a button after the menu. Simply enable the checkbox 'Insert Go Button After Menu'. Remember to remove the ONCHANGE attribute of SELECT and to add ONKEYPRESS to the button.
For example, the following code is wrong:
<form name="select_country">
Select a country:
<select name="country" onChange="MM_jumpMenu('parent',this,0)">
<option value="http://www.this_site.com/be" selected>Belgium</option>
<option value="http://www.this_site.com/us">United States</option>
</select>
</form>
An accessible version is:
<form name="select_country" action="http://www.this_site.com/jump.cgi"> Select a country: <select name="country"> <option value="http://www.this_site.com/be" selected>Belgium</option> <option value="http://www.this_site.com/us">United States</option> </select> <input type="submit" value="Go"> </form>
The page contains event handlers and/or objects (using OBJECT, EMBED, APPLET tags) that should provide a user interface that is device independent.
Make sure if the event handlers and/or objects offer a user interface, that the interface can be operated with any possible input device.
Programmatic objects can have their own user interface that is not directly implemented in HTML. If this user interface cannot be operated (and perceived) with all the input and output devices that can be used by disabled users, then the page is not accessible.
As defined by W3C/WAI (see &wcag;), "device independence" means that visitors must be able to interact with a website using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.
Note that "device-independent support" does not mean that the browser must support every input or output device. It should offer redundant input and output mechanisms for those devices that are supported. For example, if a browser supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.
Device-independent access means that the visitor may interact with the browser or document with a preferred input (or output) device. For example, if a form control can only be activated with a mouse or other pointing device, someone using the page without sight, with voice input, or with a keyboard will not be able to use the form. The form is an example of device dependence, because its use would be possible only through a mouse.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command-line interface.
Potentially critical objects are Java applets, VB scripts, objects used via plug-ins like Flash, Shockwave, RealAudio, and RealVideo.
Examine these objects and determine whether the user interface they offer (buttons, images, text, etc.) can be operated by devices other than the mouse.
As a quick test, try to use all the features of the page with the keyboard only (don't touch the mouse). Is it possible to get to all the controls (links, buttons, etc.) and operate all of them?
If this quick test fails, then the page is not accessible. If it succeeds, do a more thorough test with assistive technology.
The page contains BUTTON, INPUT, SELECT or TEXTAREA elements that specify event handlers that are device dependent (i.e. they handle events that can be generated by a specific input device.)
The user interface offered by a web page should be perceivable and operable by everyone, regardless of physical, cognitive or technical disabilities. In particular it must be device-independent. This is crucial for pages that include forms.
As defined by W3C/WAI (see &wcag;), "device independence" means that visitors must be able to interact with a website using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.
Note that "device-independent support" does not mean that the browser must support every input or output device. It should offer redundant input and output mechanisms for those devices that are supported. For example, if a browser supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.
Device-independent access means that the visitor may interact with the browser or document with a preferred input (or output) device. For example, if a form control can only be activated with a mouse or other pointing device, someone using the page without sight, with voice input, or with a keyboard will not be able to use the form. The form is an example of device dependence, because its use would be possible only through a mouse.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command-line interface.
In general, it is best to substitute event handlers within forms as follows:
The page contains links that may cause the browser to open a new window (either via a TARGET attribute or via a javascript:window.open() instruction). If this is the case, ensure that the visitor is told that this is the behavior. If the user is not notified, then the page fails to satisfy this checkpoint.
When the browser opens a new window, as an effect of clicking on a link or button, the environment in which the user is working changes. It changes because:
These two factors, possibly combined together, amplify the possible difficulties experienced by visitors, especially those who are disabled or use disabling technologies. For example, if the new window is opened with the same size and position as the old one, on top of the old one, it might appear to a visitor as the same window. The visitor might interpret the fact that the Back button does not work as a bug of the browser (and might restart the browser) or a bug in the site (and might switch to another one).
For visually impaired visitors it is even worse: screen readers might not be able to tell them that there is a new window. Screen magnifiers users might have a very hard time in guessing that there is a new window somewhere and where the new window is placed.
Therefore it is crucial that the visitor is told that a new window is being opened. Obviously the visitor should be told that before opening the window.
In all cases, the new window should contain a button that leads the visitor back to the page that has opened the window (or alternatively that closes it). These buttons will work also if the new window has disabled the standard browser buttons.
Try to avoid opening new browser windows.
If this is not possible, notify the user that a new window will be opened when the user clicks on a certain link or button. For example, write "(new window)" just before the link text, within the link text, or write it in the link TITLE attribute. Another option is to systematically adopt in the site a small icon whose meaning is "new window being opened" and put that icon in the link label (set its ALT to something like "new window"). More details on Qbullets (animated GIFs must be avoided).
In all cases, add a "Close" or a "Back" button to the new window that would close the new window or lead to the previous page, respectively.
The page contains a script, associated to the BODY tag that could open a new window when the page is loaded by the browser (i.e. a pop-up window). If this is the case, the page fails to satisfy the checkpoint.
When the browser opens a pop-up window the environment in which the user is working changes. It changes because:
These factors, possibly combined together, amplify the possible difficulties experienced by visitors, especially those who are disabled or use disabling technologies. For example, if the new window is opened with the same size and position as the old one, on top of the old one, it might appear to a visitor as the same window. The visitor might interpret the fact that the Back button does not work as a bug of the browser (and might restart the browser) or a bug in the site (and might switch to another one).
For visually impaired visitors it is even worse: screen readers might not be able to notify the user that there is a new window. Screen magnifiers users might have a very hard time in guessing that there is a new window somewhere and where the new window is placed.
Therefore it is crucial that in general the visitor is told that a new window is being opened. Obviously the visitor should be told that before opening the window, which for pop-up windows is not a viable solution.
In all cases, the new window should contain a button that leads the visitor back to the page that has opened the window (or alternatively that closes it). These buttons will work also if the new window has disabled the standard browser buttons.
Try to avoid opening new pop-up windows.
If opening new pop-up windows is a required behavior, add a "Close" button to the new window that would close the new window.
The page contains forms with controls. If the labels of these controls are not properly positioned, (to the left or on the top of the control), then the page fails to satisfy this checkpoint.
Consider that not all visitors can get a bi-dimensional view of the form, and they might not be able to take advantage of visual clues that have been added to the graphical design of the form (like vertical alignment of controls, or little boxes that act as a frame for a number of controls, or different background colors).
This may happen because the visitor uses a different media to experience the form (like via audio rendering of the form), because the visitor uses a screen magnifier that shows only a very limited portion of the form, or because the visitor uses a very small, black and white PDA screen.
In all of these cases the visitors are likely to miss the intended meaning of a field or control, and might be unable to figure out what they should type or do.
Ensure that the labels for the fields and controls do exist, and are positioned to the left or on the top of the control to which they refer. Be aware of the potential problems that might arise when using tables to layout the content of the form.
This is a generic warning. It is best to always use the latest technologies released by the W3C that are appropriate for the task.
It is best to always code up to the latest standards, and let the browsers (and other technologies) catch up. In this way the developed pages do not need to follow the evolution of the browsers.
This means for example to use XHTML, CSS, SMIL (for multimedia captioning), MathML (for marking up mathematical formulas), XML and XSL (for completely separating content from presentation), P3P (for representing privacy information).
Review the latest W3C recommendations on the World Wide Web Consortium.
The page contains tags that are deprecated in HTML 4.01. Avoid using them.
Deprecated tags and attributes are not part of an HTML standard. They have been removed from the standard, by the W3C, because they are redundant with other tags or technology and because they are against the latest development trends of the standards.
For example, the FONT tag is deprecated because it is possible to specify all the font properties using CSS rules (redundancy). In addition a higher level of modularity and a better separation between structure and presentation (trends) is achieved.
To see the deprecated tags and attributes refer to the official HTML document &w3c_html401;.
Some of the following tags have been found in the page:
The page contains FRAMESET and FRAME elements with a TITLE attribute. Check that the attribute describes the purpose of the frame and how the frame relates to the other frames of the page.
If necessary add a LONGDESC attribute as well.
Frames are mainly used for grouping information and navigation items, and displaying them with a certain page layout. However, some assistive technologies (reading browsers, screen readers, textual browsers) are not able to employ the visual layout. These tools therefore render each single frame out of context, without any reference to the other frames. The user of these tools cannot perceive the other frames and their content. That is why it is important that each frame carries within it a description that allows the user to build the context.
Names like "top", "bottom-left" that are usually adopted for frame names are not sufficiently descriptive and don't help the user in building the missing context.
Consider the following example (taken from HTML Techniques for Web Content Accessibility Guidelines 1.0 and slightly modified):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
<HEAD>
<TITLE>Today's news</TITLE>
</HEAD>
<FRAMESET cols="10%,*,10%">
<FRAMESET rows="20%,*">
<FRAME src="promo.html" name="promo" title="promotions">
<FRAME src="sitenavbar.html" name="navbar"
title="Sitewide navigation bar" longdesc="frameset-desc.html#navbar">
</FRAMESET>
<FRAME src="story.html" name="story" title="Selected story - main content"
longdesc="frameset-desc.html#story">
<FRAMESET rows="*,20%">
<FRAME src="headlines.html" name="index" title="Index of other
national headlines" longdesc="frameset-desc.html#headlines">
<FRAME src="ad.html" name="adspace" title="Advertising">
</FRAMESET>
<NOFRAMES>
<p><a href="noframes.html">No frames version</a></p>
<p><a href="frameset-desc.html">Descriptions of frames.</a></p>
</NOFRAMES>
</FRAMESET>
</HTML>
frameset-desc.html might say something like:
#Navbar - this frame provides links to the <a href="sitenavbar.html">major
sections of the site</a>: World News, National News,
Local News, Technological News,
and Entertainment News.
#Story - this frame displays the <a href="story.html">currently selected story</a>.
#Index - this frame provides links to the day's
<a href="headlines.html">headline stories</a> within this section.
Notice the NOFRAMES element is useful when special purpose browsers are used that do not support frames (for example on PDAs and cell phones).
Ensure that the TITLE attribute of FRAME
clearly describes the purpose of the frame and its relationship with
the companion frames. If TITLE is not enough (for example because images, links, or other markup is required) also use the LONGDESC
attribute to provide a link to an HTML file containing a longer description.
See the Explanation section for a detailed example.
The NAME attribute is usually used for programming purposes and it should not contain white spaces. The TITLE attribute, which may contain spaces, can be used to set a more descriptive text. In general, it is safe to use both.
The page contains FRAMESET and FRAME elements with a LONGDESC attribute that is not valid.
Frames are mainly used for grouping information and navigation items, and displaying them with a certain page layout. However some assistive technologies (reading browsers, screen readers, textual browsers) are not able to employ the visual layout. These tools therefore render each single frame out of context, without any reference to the other frames. The user of these tools cannot perceive the other frames and their content. That is why it is important that each frame carries within it a description that allows the user to build the context.
Names like "top", "bottom-left" that are usually adopted for frame names are not sufficiently descriptive and do not help the user in building the missing context.
Consider the following example (taken from HTML Techniques for Web Content Accessibility Guidelines 1.0 and slightly modified):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
<HEAD>
<TITLE>Today's news</TITLE>
</HEAD>
<FRAMESET cols="10%,*,10%">
<FRAMESET rows="20%,*">
<FRAME src="promo.html" name="promo" title="promotions">
<FRAME src="sitenavbar.html" name="navbar"
title="Sitewide navigation bar" longdesc="frameset-desc.html#navbar">
</FRAMESET>
<FRAME src="story.html" name="story" title="Selected story - main content"
longdesc="frameset-desc.html#story">
<FRAMESET rows="*,20%">
<FRAME src="headlines.html" name="index" title="Index of other
national headlines" longdesc="frameset-desc.html#headlines">
<FRAME src="ad.html" name="adspace" title="Advertising">
</FRAMESET>
<NOFRAMES>
<p><a href="noframes.html">No frames version</a></p>
<p><a href="frameset-desc.html">Descriptions of frames.</a></p>
</NOFRAMES>
</FRAMESET>
</HTML>
frameset-desc.html might say something like:
#Navbar - this frame provides links to the <a href="sitenavbar.html">major
sections of the site</a>: World News, National News,
Local News, Technological News,
and Entertainment News.
#Story - this frame displays the <a href="story.html">currently selected story</a>.
#Index - this frame provides links to the day's
<a href="headlines.html">headline stories</a> within this section.
Notice the NOFRAMES element is useful when special purpose browsers are used that do not support frames (for example on PDAs and cell phones).
It appears that a long description for a frame is needed,as there is
a LONGDESC attribute that is already defined. However, the value of the
LONGDESC attribute is not valid.
A valid LONGDESC satisfies all the following conditions:
See the Explanation section for a detailed example.
Ensure that text contained in the page is appropriately divided into manageable groups (headings, list items, etc.).
The reading pattern on the computer screen is very different than on paper due to the difference in the physical properties of those two supports, and the difference in the two tasks for the user.
When a person reads a web page from a computer screen, the page is actually scanned to determine its overall structure and sections of content. Titles, headings, bold faced text, underlined links, or indented items quickly catch the user's attention.
Large blocks of text are read only after this scanning process ends, and only if something in it has caught the user's interest.
In addition, assistive technologies often provide the means to automatically group information and render this information separately. For example, they render one frame at the time; they allow the user to jump to a certain section (marked up with a header H1, H2, ...); they render a hotspot (i.e. image map) as a group, etc. In this way, a user of assistive technologies can take advantage of this division into groups of content or navigation items.
Use all the possible means to split large blocks of text, form controls, and links into smaller groups.
For example, use OPTGROUP to group OPTION elements inside a SELECT; group form controls with FIELDSET and LEGEND; use nested lists where appropriate; use headings to structure documents, etc.
The page contains a form whose controls are not explicitly linked to LABEL elements.
When navigating through a form using the tab key, a visually enabled user can easily associate the controls with the labels that are placed near them. For a screen reader user, however, this information is not enough. It is necessary to explicitly specify which label is linked to which form control.
The best way to achieve this is provided by the LABEL element. LABEL must contain the actual text labeling, the form control, and its attribute FOR must contain the ID of the control.
One LABEL can point only to one control, or more than one LABEL can point to the same control. This feature is not yet implemented by all screen readers, so it is recommended to assign only one LABEL to each control.
It is possible to implicitly associate a label to a control: insert both the label and the control as contents of the LABEL element. While this technique is suggested by HTML 4.01 Recommendation, it is not supported by all screen readers yet.
There are three steps for associating a label to a control:
Example:
<form action="submit" method="post"> <label for="firstname">First name: </label> <input type="text" id="firstname"> <label for="lastname">Last name: </label> <input type="text" id="lastname"> </form>
The page contains links with text labels (i.e. A elements with textual content). Ensure that labels are meaningful, informative and brief.
Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse. For example, in HTML, write "Information about version 4.3" instead of "click here" or "click" or "here" or "go". In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the "title" attribute).
Most assistive technologies are able to extract all the links from the page and render them as a separate list. In these cases, from the information that is contained in the link label (i.e. content), and in the link title attribute, users have to be able to understand where the link leads.
For this reason, links like "more info", especially if repeated several times in the page, are not clear enough when taken out from the context.
Consider also that link labels should provide as much information as needed for the user to discern what the destination of the link is. The user should have a clear understanding of where a link goes before clicking it. Otherwise, the user will have to spend time waiting for the new page to be downloaded and displayed, and spend effort in reading it, possibly to no avail.
This is especially important for links leading to very heavy pages (to warn the user of a longer than usual response time), or to pages requiring specific plug-ins (like PDF, Flash, MS Word, etc.).
Edit the label of the link so that it clearly describes where the link is directed. The description should be brief and clearly understood if read out of the context (i.e. in a list of all the links of the page).
If the link label is not enough, also use the link title (which in many browsers will be displayed as a tool-tip, in a small temporary window, when the mouse is moved over the link). If link titles are used, however, use them consistently on all the links of the site.
The page contains links whose label (i.e. the content of the A element) or title (the TITLE attribute of A) appears not to be informative enough. Ensure that labels are meaningful, informative and brief.
Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse. For example, in HTML, write "Information about version 4.3" instead of "click here" or "click" or "here" or "go". In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the "title" attribute).
Most assistive technologies are able to extract all the links from the page and render them as a separate list. In these cases, from the information that is contained in the link label (i.e. content), and in the link title attribute, users have to be able to understand where the link leads.
For this reason, links like "more info", especially if repeated several times in the page, are not clear enough when taken out from the context.
Consider also that link labels should provide as much information as needed for the user to discern what the destination of the link is. The user should have a clear understanding of where a link goes before clicking it. Otherwise the user will have to spend time in waiting for the new page to be downloaded and displayed, and spend effort in reading it, possibly to no avail.
This is especially important for links leading to very heavy pages (to warn the user of a longer than usual response time), or to pages requiring specific plug-ins (like PDF, Flash, MS Word, etc.).
Edit the label of the link so that it clearly describes where the link goes. The description should be brief and as much as possible understood if read out of the context (i.e. in a list of all the links of the page).
If the link label is not enough, also use the link title (which in many browsers will be displayed as a tool-tip, in a small temporary window, when the mouse is moved over the link). If you use link titles, however, use them consistently on all the links of the site.
The page contains two or more links that have the same link label but that point to different URLs.
A link label is considered as the text equivalent of the link content and link title. In other words, all the text contained within A and /A, the ALT of images contained within A and /A and the value of the TITLE attribute if specified.
Do not use the same link phrase more than once when the links point to different URLs. If more than one link on a page shares the same link text, all of those links should point to the same resource. Such consistency will help page design as well as accessibility.
When the same link label re-occurs, there is an implication that the link points to the same place. If it does not, users may be surprised and disoriented. It is best to assume that many users are not very familiar with the way in which the website functions, and therefore there is a high risk that they get confused and perhaps leave the site.
In addition, screen readers and reading browsers often allow the user to render the list of links of the page in a different pop-up window. Each link is shown out of its context. If two links have the same label then the user would assume they lead to the same place. The user might then be unable to reach a certain page or Online service.
Try to use different link labels for links leading to different
documents. Also whenever possible, it is best to use informative labels.
If this is not possible, (for example when it is necessary repeat the
same link "Buy Online" for several products listed in the page), then
try distinguish the links by specifying a different value for the "title"
attribute of each A element.
The page does not contain, in its HEAD section, any LINK element that specifies relations between this page and other documents or information items.
For example, use RDF to indicate the document's author, the type of content, etc. Some HTML user agents can build navigation tools from document relations described by the HTML LINK element and "rel" or "rev" attributes (e.g., rel="next", rel="previous", rel="index", etc.).
The LINK element defines a link that is not shown to the user, but it is used by the browser for special purposes. It conveys information that the browser can process in several ways (for example Mozilla can display a special navigation bar; lynx presents these links in a special section of its display).
In general LINK represents a relationship between the current document and something else. An example is the relationship between the current HTML document and an external CSS file. Another example is to represent the next and previous document in a sequence of documents (like for different chapters in a tutorial).
Consider the following example by the W3C (&w3c_html401;):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML> <HEAD> <TITLE>Chapter 2</TITLE> <LINK rel="Index" href="../index.html"> <LINK rel="Next" href="Chapter3.html"> <LINK rel="Prev" href="Chapter1.html"> </HEAD> ...the rest of the document...
In the following example, also taken from the same source, the HREFLANG attribute to tell search engines where to find Dutch, Portuguese, and Arabic versions of a document. Note the use of the CHARSET attribute for the Arabic manual. Note also the use of the LANG attribute to indicate that the value of the title attribute for the LINK element designating the French manual is in French.
<HEAD>
<TITLE>The manual in English</TITLE>
<LINK title="The manual in Dutch"
type="text/html"
rel="alternate"
hreflang="nl"
href="http://someplace.com/manual/dutch.html">
<LINK title="The manual in Portuguese"
type="text/html"
rel="alternate"
hreflang="pt"
href="http://someplace.com/manual/portuguese.html">
<LINK title="The manual in Arabic"
type="text/html"
rel="alternate"
charset="ISO-8859-6"
hreflang="ar"
href="http://someplace.com/manual/arabic.html">
<LINK lang="fr" title="La documentation en Français"
type="text/html"
rel="alternate"
hreflang="fr"
href="http://someplace.com/manual/french.html">
</HEAD>
In the following example, search engines are told where to find the printed version of a manual.
<HEAD>
<TITLE>Reference manual</TITLE>
<LINK media="print" title="The manual in postscript"
type="application/postscript"
rel="alternate"
href="http://someplace.com/manual/postscript.ps">
</HEAD>
And here where to find the front page of a collection of documents.
<HEAD>
<TITLE>Reference manual -- Page 5</TITLE>
<LINK rel="Start" title="The first page of the manual"
type="text/html"
href="http://someplace.com/manual/start.html">
</HEAD>
Consider adding LINK elements to the HEAD section to represent relationships between this page and other documents.
The list of possible relationships between documents that can be represented by the LINK element from &w3c_html401;.
The page has no valid TITLE.
The TITLE tag defines the document's title for:
A poor, or missing, TITLE would make the page much more difficult to
locate and understand in any situation where the user is required to
identify a window, figure out the context, selecting an item from a
bookmark list or search results.
This often occurs when using assistive technology, since the page
title is the first thing that is presented to the user and
should clarify the new context brought by the page.
To be effective titles should be brief and
informative (i.e. adequately describe the page).
Citing Nielsen, a page title needs to be a pearl of
clarity.
Titles should not contain HTML tags, as they would not be interpreted by browsers (and would clutter the meaningful part of the title).
Finally, a page should contain exactly one title: if more than one is present only one of them will be considered by browsers.
Consider also that often screen readers, when presenting the available frames to the user, read the page TITLE of the framed pages (not only the TITLE attribute of the FRAME element). Therefore, it is important for page TITLEs of framed pages to be well defined and meaningful.
To define the title of the page include the following HTML code just below the HTML tag at the beginning of the document:
<HEAD> <TITLE> Buy the best strawberries fields in the world </TITLE> </HEAD>
With Dreamweaver this can be achieved in a more simple way: simply fill-in the title box on top of the Editor window.
Consider that titles, to be effective, have to satisfy the following conditions:
If not present, add a site map to the site and describe how content is organized throughout the site. Highlight also the accessibility features that are available on the site.
Consider a site map as the table of contents of the site. It is a powerful means for visitors to understand the layout of the site.
Consider also that for non-sighted users, experiencing a site takes much longer, since they have to listen to the content of the pages they visit. This takes much longer than just glancing it.
Implement a site map either graphically, or as a set of nested lists (like in a table of content of a book), or use any other effective means for describing categories of information items.
If accessibility features implemented on the page are described, then users may configure the specific assistive technology that they are using to fit these solutions.
The page seems to contain a navigation bar. Ensure that navigation bars across the site are consistent.
Consistency is a key factor for achieving an accessible and usable site. In fact, if a feature (like a navigation bar) is used consistently through the pages of the site, the visitor will quickly grasp the meaning of the navigation bar, and of its buttons/links, and will be able to use it without hesitation.
If, on the other side, a group of links keeps changing from page to page, then a visitor has to re-learn it each time it appears. This is time consuming, requires effort on the user and is more error prone (the user might click involuntarily on a link).
Look at all the navigation bars in the site and ensure that they are as consistent as possible in the ordering, positioning, formatting and labeling of their links.