Accessibility and the WCAG 2.0
- Damodar Chetty
- October 20, 2007
I have been working on a project for a government entity that insisted that any Web applications we developed had to meet W3C accessibility guidelines.
My instinctual reaction was 'its going to double our development and QA estimates, isn't it'. Next, it was 'so no Javascript?'. And, finally it was, 'So what does accessibility really mean?'.
That final question led me (via Google) to the World Wide Web Consortium (W3C) Web site, which seemed like a very promising resource for all questions related to accessibility. After all, they did write the book on this, didn't they?
After spending an entire morning jumping from link to link on that site, it became really clear to me that I was going to need to gird my loins for serious battle. The W3C documentation bears clear traces of its 'committee' heritage, and is as complex and voluminous as it is dry and tasteless. It felt like trying to down a plateful of fiber ... you know deep down that fiber's good for you, but that doesn't mean its going to make an attractive meal.
To get a sense of scale, see To Hell with WCAG2 by Joe Clark. The core of the latest guidelines by the W3C's Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines Working Group (WCAG) runs into a cool total of over 450 US letter-sized pages. This is further complicated by the fact that the documentation is split into multiple redundant parts - no one part of which can be read by itself, but require that a reader continually jump from one to the next and back.
To the sheer size of these "guidelines", you have to add what can only be euphemestically termed 'challenging language' in the documents. With over 20 years in the field of software engineering, and multiple degrees in computing, I don't consider myself a lightweight when it comes to reading technical literature. However, I must admit to feeling overwhelmed with the content in these tomes. The language feels stilted, and the definitions and terms used are confusing. In fact, the best parts in the document occur when they produce code snippets. When Javascript code actually feels easier than the text, you know that the document is more work than most.
So where should I start? Instead of focusing on all that's wrong with this specification (check out Joe's aforementioned opinions for yourself - there's enough ranting there to rival the WCAG 2 guidelines), I'm going to focus on my personal journey through this, erm, mess.
According to the Web Accessibility Initiative WGAG 1.0 was approved in May 1999. While it informed accessibility-centric development for the past few years, it is quickly being superseded by fresh guidelines that are currently in the works - the WCAG 2.0 - which is anticipated to be completed in 2008.
Even though WCAG 1.0 is still the reigning king, for all practical purposes, I chose to focus on WCAG 2 - its not only more comprehensive, but also has more testing guidelines and examples. As with any "in progress" document, you have to read with the understanding that things could change before you complete reading the document. Note my self control at avoiding taking a dig at the size of the document yet again.
The core of the WCAG 2 is found in these documents:
With the admirable goal of doubling the text that any developer has to go through, the WAI kindly provides us with two additional redundant documents:
Disabilities are defined as limitations of sensory (visual, auditory, speech), physical, cognitive, or neurological functioning which can affect access to the Web. These not only include permanent disabilities (e.g., blindness), but also those acquired limitations associated with injuries, aging, or to side effects of medication (e.g., hand tremors).
In addition, disabilities can occur in combinations, as in the deaf-blind, and these limitations may occur at different levels of severity.
The problem at the heart of Web accessbility lies in (a) providing an alternative to the traditional monitor, keyboard, and pointing mechanisms of using a computing device, and (b) ensuring that the content itself is clear (readable) and does not cause harm (cause seizures, etc.) to users with all levels of abilities.
Depending on one's disabilities and their severities, a user may choose to use one or more technologies to assist them in accessing the computing device, and by extension your Web site. These technologies provide alternatives to either input or output peripherals connected to a computer.
In addition, users who are unable to use a pointing device, may use the keyboard to Tab through the widgets on a page.
Limitations can be broadly organized into the following categories, with users potentially experiencing combinations of these limitations at varying severity levels.
The WCAG 2.0 categorizes its accessibility rules in terms of general principles, guidelines and success criteria.
For the most part, the principles describe the "mom and apple pie" values and as a consequence seem to be more useful to the politician than the typical grunt developing a site. Guidelines serve as a functional "section-based" grouping of the actual rules, and I suspect will be more useful (say as a memory aid) once I have gained a level of expertise with the individual rules themselves.
The meat and potatoes of the WCAG 2 are the actual success criteria. Each criterion indicates in very specific detail the "Web page offenders" it is targeting, and what needs to be done in order to achieve its goals, along with HTML snippets, Javascript code, and CSS rules that might be helpful to a developer.
Each criterion has an associated conformance level, either "A", "AA", or "AAA". These levels map relatively loosely to must-have, nice-to-have, and pie-in-the-sky. A worthwhile goal therefore would be to implement all of the level "A" and "AA" criteria, and to optionally implement as many of the "AAA" criteria as your time and budget permit. At least, that's the strategy we're advocating for our project.
In the next few sections, I'm going to spell out the individual success criteria and their suggested fulfillment techniques. My aim is to distill the rules down to their essence - sort of a Cliff notes version of the WCAG 2. A danger with this is that I might misrepresent some of the facts related to these criteria - esp. as I'm operating without a technical reviewer here. As a result, I cannot overstress the importance of reading through the WCAG by yourself - so caveat emptor.
Please email me if I've got anything wrong, after all, I'm learning as I go. And, yes, please insert any legalese here to protect me from any reliance on the information contained herein.
Plain text has the advantage that it can be rendered in different modalities (visually, audibly, or tactilely) depending on what best meets the needs of the user. It can also be enlarged, or spoken in a more understandable voice (i.e. with the right accents, etc.) This has the beneficial effect that plain text is the most accessible form of content on the Web.
As a result, any non-text content (images, audio, video, even images of text) should be translatable into its equivalent representation in plain text. I.e., replacing the image by this plain text should lose no information.
alt attribute. This applies to <img> tags, <input> tags of type <image>, and <area> elements of <map> tags.
<input type="image" name="submit" src="button.gif" alt="Submit" />
<img src="news.gif" alt="Free newsletter. Get free recipes, news, and more." />
longdesc attribute or an anchor link that takes the user to plain text content.The criterion exempts certain forms of non-text content - viz.,
<label for="firstname">First Name: </label>
<input type="text" name="firstname" id="fname" />
or:
<input type="checkbox" name="flavor" id="chocolate" value="c" />
<label for="chocolate">Chocolate</label>
When visual design precludes the use of a label, use the input tag's title attribute instead.
value attribute.alt attribute.alt to "" and omit the title attribute. This effectively asks the assistive technology to ignore such content.
When non text content changes, ensure that the description does as well. A script is used to update the image on a page, but the alt text is not updated.
Visual cues are often used to perceive structure and semantic information in a document. For e.g., structure in a document is usually perceived using cues, such as headings being in a bolder font separated by blank lines, and list items being preceded by bullets and being indented. Similarly semantic information, such as words that need to emphasized, are communicated by italicizing them.
createElement(), createTextNode(),append/remove/replaceChild(), and insertBefore(). When adding focusable elements in the middle of a document, do not add tabindex attributes to explicitly set the tab order. Let the default tab order be used instead.
summary attribute to provide a brief text overview.id for each header, and then include the appropriate ids in the headers list for each table cellscope attribute for each header that indicates whether the cell is a header for a row, column, or group of rows/columnsth, caption, summary, scope and headers attributes (provide semantic structural information) in a purely layout table. A screen reader speaks out this information as the user navigates the table - which could be distracting for usersIf content has items that appear in some meaningful sequence, then that sequence must be maintained even when the content is presented in a different modality. A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning - e.g., ordered lists are meaningful sequences, but unordered lists are not.
The sequence of content may also be affected when tables are linearized by screen readers. Tables present data in 2 visual dimensions, but readers present this in linear order of the content in the source, beginning with the first cell in the first row, and ending with the last cell in the last row; reading the contents of each row, before moving on to the next row; and speaking out the complete content of each cell in each row, including that of any table nested within that cell. Because of this linearization any meaningful sequence conveyed through visual presentation may not be perceivable when the content is spoken.
UI components should not be referenced by color, shape ("round button"), size, or location ("button to the right"), i.e., do not rely on information not readily available from the structure of the content. Users may not be able to perceive these properties due to the nature of the assistive technology used. I.e., they may perceive only a small portion of the screen at one time, and location can vary due to variations in the size of the font, window, or screen.
Any items referenced by color, shape, size, or location must also be referenced in ways that do not depend on visual perception (e.g., by their function or label):
Information conveyed by color must also be explicity conveyed in plain text:
All required fields are displayed in red and marked with an asterisk * followed by an example; or each colored icon has alt-text with a short description
If color is used within an image, such as a pie chart, to convey information , then use patterns to convey the same information. E.g., solid and patterns are used to represent different color bars in a graph; or in addition to different colored icons, use different icons to represent different routes.
Also, ensure that the text alternative for the image conveys that same information.
When using a screen reader, it is difficult to hear the words if there is other audio playing at the same time. This is especially a problem when the speech output is controlled via the same volume control as this sound. So, provide a way to turn off background sound, or stop it automatically after 3 seconds or less.
There should be enough contrast between the text and its background. Contrast is calculated without considering color, so that people with a color vision deficit will also have adequate contrast. See the WCAG 2.0 guidelines for links to utilities that help measure contrast.
The simplest is not to specify the colors of the text as well as the background. But if you must, ensure that you specify both with sufficient contrast.
<body color="white" bgcolor="black">
<style type="text/css"> body {color:white; background-color:black;}</style>
You should provide direct support for resizing text or changing layout - e.g., via server side script that can be used to assign different style sheets; or at least not prevent the browser from scaling text.
As scaling increases beyond 200% (twice width and height), adaptive layouts may introduce usability problems - words may be too wide to fit into the space available to them, causing them to be truncated; text may overlap with other content; or only one word may fit on each line, making it harder to read the sentence when it is displayed as a vertical column.
To ensure browser support for scaling text, do not specify font sizes in absolute units. Instead, specify text font sizes using (a) proportions, strong {font-size: 120%} ; (b) named font sizes that express the relative size desired, strong {font-size: larger}; or (c) em units, strong {font-size: 1.6em}
Use liquid layouts which adapt to the available horizontal space by reflowing as necessary. Position the layout regions as a row of adjacent floating boxes. Define the size of layout regions using units that will cause it to scale relative to the text. E.g., using the float, clear, etc. CSS attributes.
Same as for 1.4.3.
[Omitted for now ... to be filled in later. Please see the Understanding WCAG 2.0 document for details.]
Provide options to use a variety of layouts with different font sizes. Use single column layouts. Use relative units and liquid layouts.
This translates from elven-speak to: All functionality is available using a keyboard without requiring finger gymnastics, except in the cases where the path taken is just as significant as the destination (as in free hand drawing; but not for drag-and-drop, where only the destination is material).
Keyboard access is required for the blind (devices like mice need hand-eye coordination), those with low vision (trouble with tracking a pointer on screen), and those with hand tremors.
Removes the exception for path-dependent inputs.
Many users need more time to complete tasks like filling out forms than the majority of users. They take longer to physically respond, to read things, to find things, or they may be using assistive technologies that require more time. This guideline eliminates or relaxes time constraints.
If there is no hard time limit required to be imposed:
Provide a checkbox to allow users to request a longer session time limit (up to 10x the limit), or no limit (as long as there is no privacy or security issue). I.e., with the text: Allow as much time as I need to complete this form. I understand that I must close the Web browser if I choose to stop before completing the last part of the form. OR Allow additional 15 minutes to complete each part of this form.
or:
A script notifies users of an imminent (20 seconds or more) time limit, and allows the user to extend this time limit some number of times with a simple action. If the user requests additional time, the timer is reset.
<head>
<script type="text/javascript">
<!--
function timeControl() { setTimeout('userCheck()', 280000); } // timer set to 4m 40s
function userCheck() {
var id=setTimeout('pageReload()', 20000); // set page refresh for 20 seconds
if (confirm("This page refreshes in 20s. Would you like more time?")) {
clearTimeout(id);
timeControl();
}
}
function pageReload() { window.location.reload(true); }
timeControl();
-->
</script></head>
This script may optionally prompt the user to enter a larger default time limit between refreshes.
Using a client side redirect to refresh a page after a time delay often makes the page inaccessible to screen readers since blind users will not have enough time to make their readers read the page before it refreshes unexpectedly and causes the reader to begin reading at the top. It is acceptable to use this with time-out set to 0, since the redirect is instant and will not be perceived as a change in context.
<head><meta http-equiv="refresh" content="5;url=http://www.example.com/newpage" /></head>
<body><p>If your browser supports the refresh meta tag you will be transported to <a href="...">here</a> in 5 seconds. Else, select the link manually.</p></body>
OR:
response.setContentType("text/html"); response.setHeader("Refresh", "10;url=targetPage.html");
However, it is still preferable to let users choose when they want the latest information, or to use server-side 302 redirect HTTP response and a Location header with the new URL to do this.
Avoid the <blink> element, or the CSS text-decoration property setting of blink, or blinking in an applet or plugin, since users can't control the blink.
Use a script to start and stop the blinking effect:
<div id="blink1">New item!</div>
<script type="text/javascript">
<!--
function show() {
if (document.getElementById) document.getElementById("blink1").style.visibility="visible";
}
function hide() {
if (document.getElementById) document.getElementById("blink1").style.visibility="hidden";
}
for (var i=900; i < 2700; i=i+900) { //toggle on and off every 450 ms to blink. Stop after 2.7s.
setTimeout("hide()", i);
setTimeout("show()", i+450);
}
-->
</script>
Provide keyboard shortcuts or input controls to allow users to stop content from advancing or updating at a rate beyond the user's ability to read or understand the content. E.g., animations, stock tickers, etc.
This differs from criterion 2.2.1 in limiting exceptions to real-time events. So, provide all the time needed to complete an activity. i.e. don't require any timed interaction.
For pages that automatically update content, provide users with a preference or user field to turn off or postpone updates except in emergencies (civil alerts, or other dangers to health or property, loss of data, loss of connection etc.) This allows users to keep their focus on the content they are currently reading without distraction.
E.g., if the updates are delivered by Javascript alerts, then provide buttons to turn off the alerts:
<body><p>Press button to enable display of famous quotes.</p>
<button id="enableBtn" type="button" onclick="modifyAlerts(true);">Turn Alerts on</button>
<button id="disableBtn" type="button" onclick="modifyAlerts(false);">Turn Alerts off</button>
<script ...>
var bDoAlerts = false;
function modifyAlerts(isEnabled) { bDoAlerts = isEnabled; }
function doAlert(aMsg) { if (bDoAlerts) alert(aMsg); }
var counter = -1;
var quotes = new Array {"quote 1", "quote 2", "quote 3"};
function showQuotes() {
if (++counter >= quotes.length) counter = 0;
doAlert(quotes[counter]);
setTimeout("showQuotes();", 10000);
}
showQuotes();
</script>
For security reasons, sites implement an authentication time limit after a certain period of inactivity. E.g., if a shopping session times out while entering payment information, users must have the ability to reauthenticate and continue with the transaction without the loss of any data already entered. I.e., the server should restore the state prior to the timeout, as if there had never been a timeout.
If the session state were not restored, the user would have to start all over again. For these users, it is likely that they will timeout again. I.e., the user may never be able to complete the form.
The server needs to cache this state only long enough to ensure success after reauthentication in a single user session - such as one day.
Users with seizure disorders can have seizures triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing. Unfortunately, warnings do not work well because they are often missed - esp. by children who may not be able to read them.
Most content does not flash at all, and even content that blinks does not blink this fast except on rare occasions. To avoid having to carry out the more complex testing required by this criterion, simply ensure that content only flashes 1, 2, or 3 times in any 1-second period. In particular, avoid content that contains a video clip or animated image of a series of strobe flashes, or closeups of rapid fire explosions.
Stricter since it eliminates all flashing components that flash more than 3 times per second. Magnification at any level would not yield content that would fail the general flash or red flash thresholds. This is actually easier to test, and so should be used to meet the level A criterion.
Sighted users automatically ignore repeated material, either by focusing on the center of the screen (where main content usually appears) or by quickly selecting a link that thakes them to the desired content without having to encountering every link or form control that comes before the item they want. This criterion allows users who navigate linearly to get more direct access to the primary content of the page. E.g., to avoid having to hear all heading graphics and dozens of navigation links read (the repeated content) before the main content is spoken, or to make dozens of keystrokes before reaching a link in the main content area.
ol or ul:
<a name="categories" id="categories"></a><h2>Product Categories</h2>
<ul class = "navigation">
<li><p><a href="kitchen.html">Kitchen</a></p></li>
<li><p>< a href="storage.html">Storage</a></p></li>
</ul>
Using CSS to remove list bullets and to flow the list items horizontally:
ul.navigation { list-style:none; padding:0;}
ul.navigation li {display: inline;}
To remove list bullets and display items in a floating block:
ul.navigation { list-style:none; padding:0;}
ul.navigation li {display: block; float:left;}
A title should identify the subject of the page, make sense when read out of context (e.g., by a reader), be short, and unique within the site. When titles appear in site maps, users can more quickly identify the content they need without having to read and interpret page content.
<head><title>xxxx</title></head>
A user using a screen magnifier sees only a small portion of the page. So, if the tab order skips between different form sections, then the user may believe that a section has been completed, and try to submit the form, and be surprised at the error that results. Often placing the interactive elements (forms and controls) in an order that follows relationships is sufficient. It is easy to introduce usability bugs when setting the tab order explicitly. Use the tabindex attribute of each interactive element to explicitly set the order. Elements are given focus in increasing order of the value of their tabindex. After all elements with a tabindex higher than 0 have received focus, the rest of the interactive elements are given focus in the order that they appear on the page.
To properly define the purpose of a link ensure that the link text is meaningful; use title to provide additional information; and provide hidden supplemental text. This supplemental text is not hidden by the traditional means of visibility:hidden or display:none, since these often hide text even from assistive technologies.
a span {height: 1px; width: 1px; position: absolute; overflow: hidden; top:-10px; }
...
<a href="#"><span>Washington stimulates economic growth</span>Full Story</a></p>
...
<a href="war.html"><span>War and Peace</span>HTML</a>
<a href="war.pdf"><span>War and Peace</span>PDF</a>
The context for understanding the purpose of a link should be located in the same sentence, paragraph, list item, or table cell as the link itself. If the user must leave the link to search for the context, the context is not programmatically determinable.
Users with visual impairments may find it easier to navigate using a search, rather than scrolling through a large nav bar using a reader. Cognitive-disabled may find it easier to explore the site via a site map rather than traversing individual pages or using a hierarchical scheme. So provide alternative options to navigate your site.
A document could have a table of contents that has links to sections and subsections of the same document, or it could be used across pages when a "logical" document is divided into multiple pages.
Some browsers can provide an optional nav bar using information supplied in the link element - whose rel attribute can provide information on a page's position within a set of Web pages, which can be set to Contents, Start, Next, Prev, Index, or Contents.
Putting the most important information at the beginning of each heading lets users skim the headings to locate the specific content they need. Esp. useful when the assistive tech allows navigation from heading to heading. Similarly, associating labels with interactive controls allows assistive technologies to recognize the label and present it to the user.
A bread crumb trail could show the locations in the path that the user took to reach this page as links, or the location of the current Web page within the site's organization or a site map could show the site's layout.
You could also use <link rel...> or include relevant information in the title of the page to identify the relationship between the current Web page and the other pages in the same collection.
When the purpose of a link can be identified from its link text, links can be understood even when they are out of context, as in a screen reader that lists all the links on a page. This helps people ignore links that they are not interested in.
When a page is organized into sections, provide headings for each section to indicate the organization of the content, and to provide mental handles that aid in comprehending the content. Visual presentation elements (e.g., horizontal rules and boxes) may complement headings, but are not sufficient to identify sections. Helps visually impaired to navigate the document.
The default language of the document must be identified using the html attribute's xml:lang (for XHTML 1.1) and lang (HTML 4.01) attributes. XHTML 1.0 understands both.
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr">
If the language of the page is identified, readers can load the correct pronunciation rules (else the French word voiture would be pronounced voyture by a reader that uses English as its default language), visual browsers can display the correct characters, braille translation software can work correctly, and media players can show the right captions. As a result, users will be better able to understand the content.
HTML 4.01 supports the lang attribute on elements; XHTML served as text/html uses the lang and xml:lang attributes; XHMTL served as application/xhtml+xml uses the xml:lang attribute on elements.
<span lang="fr">je ne sais quoi</span>
Certain disabilities also make it difficult to understand figurative idiomatic language. Also, words may be used in an unusual way, i.e., where a particular meaning of the word must be used in order to understand the context.
This criterion requires that definitions be provided for idioms, phrases, abbreviations, as well as for any word used in with a special meaning in mind.
The definition may be provided either inline in the text, just before or just after the word is used. E.g.,
It may be necessary to update the driver for your printer (the driver is software that contains specific instructions for your printer.)
Or, a link may be provided to the definition in an alphabetized glossary placed either at the end of a Web page, or in a separate page.
Some browsers support linking to a glossary via a link tag in the head element of the document.
<link rel="glossary" href="#glossary">
Definitions should be specified using the dl, dt, and dd structural elements to ensure that relationships between terms and their definitions are preserved irrespective of presentation mode (modality) used.
Abbreviations can confuse screen readers in multiple ways:
Include the abbreviation immediately following the expanded form the first time it occurs on the page. The United Nations High Commissioner for Human Rights (UNHCR) was established in 1950.
Alternatively, use either the abbr or acronym elements to provide an expansion:
Provide expansions using the following rules:
There are people with disabilities (incl. reading disabilities like dyslexia) even among highly educated users with specialized knowledge of the subject matter. So when the original content is complex, provide a short summary subsection that identifies the most important ideas in the content and uses shorter and more common words, and shorter sentences. Alternatively, provide visual illustrations to supplement the text (e.g., charts, graphs, animations, diagrams); or provide a spoken version of the text.
When the screen reader reads a word using the wrong pronunciation, it can be even more difficult to understand than when read visually. E.g., in English, heteronyms are words that are spelled the same but have different pronunciations and meanings, e.g., the words desert (abandon) and desert (arid region); or Kanji characters that have multiple pronunciations. When read incorrectly the content will not make sense to users. Provide pronunciation hints either as a link to a sound file, or using phonetic symbols to help the user.
An example of a change of context is the display of a new page or a new window, a change of field focus, or a form submission. Any change of context should occur only by the user taking some specific action that may be tied to a change in context. E.g., a change of context is expected when a user clicks a link or presses a submit button. However, a change of context would be unexpected if simply tabbing to a field (an action that is not normally associated with a change of context) causes a form to be automatically submitted, or a new window is opened. Users who experience an unexpected change of context may become disoriented. Ensure that adequate instructions are provided near any controls that result in a context change.
Changing the value of a form control is not typically associated with a change of context. If a change of context must be associated with changing a control's value, it is important to provide information about what will happen when the control is changed. For e.g.,
Alternatively, provide a mechanism that allows users to explicitly request changes of context - e.g., via a submit button that submits data entered in a form.
To make the placement of repeated content more predictable, present them in the same relative order each time they appear. Other components can be inserted between them, but their relative order is not changed. Also applies to navigational components (menu, breadcrumbs). E.g.,
Users of screen readers rely on their familiarity with functionality that appears on different Web pages. If identical functions are called different names on different pages, the site will be more difficult to use. (e.g., don't mix "Search" and "Find" and "Locate"; or "Save Page" and "Save" to refer to the same functionality.) At least the label prefix must be identical (e.g. "Go to page 4", "Go to page 5"; and "Download Manual", "Download Driver").
If icons have the same functionality, then their text alternatives should be consistent as well (exception is where a check mark icon may have different semantics - approved, completed, included, etc.)
When a page is refreshed, the screen readers virtual cursor, which marks the user's current location on the page, is moved to the top of the page. An auto-refreshing page can therefore be very confusing. In particular, avoid automatically refreshing for full page content - unless there is an option to disable this behavior. E.g., avoid a slideshow that automatically advances to the next slide with no pause/stop button. Instead, provide a mechanism, e.g., a link, that allows the user to explicitly request a content update. <a href="news.jsp">Update this page </a>
In a client side redirect, a temporary page is displayed, which is then refreshed with the contents of the redirect URL. This involves a context change that is not initiated by the user. <head><meta http-equiv "refresh" content="0;URL='http://myserver.com/'" /> A server side redirect is preferred because it does not cause new content to be displayed before the server sends the content located at the new URL.
Avoid opening up windows that are not requested or expected by the user. Suddenly opening new windows can disorient or be missed completely by some users. If the target attribute is not permitted (HTML 4.01 or XHTML 1.0 Strict), new windows can be opened by script.
<a href="help.html" id="newwin">Show Help</a>
Script:
window.onload=addHandlers;
function addHandlers() {
var objAnchor = document.getElementById('newwin');
if (objAnchor) {
objAnchor.firstChild.data = objAnchor.firstChild.data + ' (opens in a new window)';
objAnchor.onclick =function(event) { return launchWindow(this, event);}
objAnchor.onkeypress = function (event){return launchWindow(this, event);}
}
}
function launchWindow(objAnchor, objEvent) {
var iKeyCode, bSuccess = false;
if (objEvent && objEvent.type=='keypress') {
if (objEvent.keyCode) iKeyCode = objEvent.keyCode;
if (objEvent.which) iKeyCode = objEvent.which;
if (iKeyCode != 13 && iKeyCode != 32) return true;
}
bSuccess = window.open(objAnchor.href);
if (!bSuccess) return true; //if popup didn't open, do default of opening in same window
return false; //stop processing any further - the popup was opened
}
When there are more than one select elements on a page, an onchange on one could update the options in another on the page without a change of context. The modified (dependent) select item occurs after the triggering select element in the reading order for the page. This ensures that assistive technology will pick up the change and that users will encounter the new data when the modified element receives focus.
HTML:
<body>
<noscript> This page needs Javascript to be enabled </noscript>
<select id="continent" onchange="countryChange(this); ">
<option value="empty">Select a Continent</option> ... "NA"North America, etc
</select>
<select id="country">
<option value="0">Select a country</option>
</select>
</body>
In the Head Script:
<script type="text/javascript">
//<![CDATA[
var countryLists = new Array(4);
countryList["empty"] = ["Select a Country"];
countryList["North America"] = ["Canada", "United States", "Mexico"];
function countryChange(selObj) {
var idx = selObj.selectedIndex;
var which = selObj.options[idx].value;
cList = countryLists[which];
var cSelect = document.getElementById("country");
var len = cSelect.options.length;
while (cSelect.options.length > 0) { cSelect.remove(0); }
var newOption;
for (var i=0; i < cList.length; i++) {
newOption = document.createElement("option");
newOption.value=cList[i];
newOption.text = cList[i];
try { cSelect.add(newOption);} catch(e) {cSelect.appendChild(newOption);}
}
}
//]]>
</script>
People with some difficulties may find it more difficult to enter error free input, and to detect when they have made an error. Typical error indication methods may not be obvious to them because of a limited field of view, limited color perception, or use of assistive technology.
Error message should be specific. On an unsuccessful form submission, redisplaying the form and indicating the fields in error is insufficient for some users. E.g., screen readers will not know there was an error until they encounter one of the indicators. It is not sufficient to simply indicate that a field has an error by putting an asterisk on its label, or by turning the label red. A text description of the problem should be provided.
When a mandatory field has not been completed, notify the user using
When a user entered value fails validation,
The description of the validation error must describe the correct data entry for the field, provide examples of the correct data entry for the field, and show values of the correct data entry that are similar to the user's data entry, with instructions to the user as to how to enter one of these correct values should the user choose to do so.
<input type="text" name="date" id="date"
onchange="if (isNaN(Date.parse(this.value))) alert("This control is not a valid date. Please reenter the value"); />
If information provided by the user is required to be one of a limited set of values, then text description should indicate this fact. i.e., include the list of values possible, or suggest the allowed value that is most similar to the entered value. E.g., "Choose one of: January, February, March, April, May, June, July, August, September, October, November, December." And, "Do you mean 'December'?"
Provide simple instructions and cues that are visually connected to form controls without cluttering the page with unnecessary information. Too much information can be just as much hindrance as too little.
E.g., inform users about any restrictions on the format of data that users must enter.
Context sensitive help is only required to be provided when the label is not sufficient to describe all functionality. It should not be placed in the form itself, but be available to users when they request it - by linking to a separate help file.
This builds on 3.3.3 in that it applies to all submitted forms.
The key takeaway was that every Web page should be validated against a formal specification. Issues to look out for were remembering to close all tags, to nest elements correctly, and to assign unique values for the id attribute within a document.
I set out with the goal of providing a synopsis of the WCAG 2 - and by now you know whether or not I've succeeded. Be that as it may, it is important to note that accessibility is here to stay, and that it is not incompatible with rich user interfaces. All that is required is what is termed 'graceful degradation', where your rich UI remains rich for those able to experience it as such, but still functions, albeit at a reduced level of richness, for those who cannot.