Using the aria-describedby property to provide a descriptive label for user interface
+ controls
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a
+ user interface element. The aria-describedby property may be used to attach descriptive information to one or more elements through
+ the use of an id reference list. The id reference list contains one or more unique
+ element ids.
+
+
Refer to Supporting ARIA in XHTML and HTML 4.01 for information on how to provide WAI-ARIA States and Properties with XHTML and HTML.
+ WAI-ARIA States and Properties is compatible with other languages as well; refer to
+ documentation in those languages.
+
+
+
Note
+
+
+
The aria-describedby property is not designed to reference descriptions on an external resource — since
+ it is an ID, it must reference an element in the same DOM document.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Using aria-describedby property to describe a Close button's action
+
A button that functions as a 'close' button on a dialog is described elsewhere in
+ the document. The aria-describedby property is used to associate the description with the button.
+
<button aria-label="Close" aria-describedby="descriptionClose"
+ onclick="myDialog.close()">X</button>
+
+...
+
+<div id="descriptionClose">Closing this window will discard any information entered and
+return you back to the main page</div>
+
Example 2: Using aria-describedby to associate instructions with form fields
+
Sample form field using aria-describedby to associate instructions with form fields while there is a form label.
+
<form>
+<label for="fname">First name</label>
+<input name="" type="text" id="fname" aria-describedby="int2">
+<p id="int2">A bit of instructions for this field linked with aria-describedby. </p>
+</form>
+
+
+
Example 3: Using aria-describedby property to provide more detailed information about
+ the button
+
<p><span id="fontDesc">Select the font faces and sizes to be used on this page</span>
+ <button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">Fonts</button>
+</p>
+<p><span id="colorDesc">Select the colors to be used on this page</span>
+ <button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">Colors</button>
+</p>
+<p><span id="customDesc">Customize the layout and styles used on this page</span>
+ <button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">Customize</button>
+</p>
+
+
+
Example 4: Using aria-describedby to associate tooltips with form fields
+
The following code snippet shows how to use aria-describedby and the onfocus="tooltipShow() function to display the tooltip when focus is placed
+ on an element.
+
This example is coded in XHTML with a MIME type of application/xhtml+xml. This MIME
+ type is not supported in all user agents. The aria-describedby property is added directly
+ into the XHTML markup, and no additional scripting is needed.
+
<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
+"https://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
+<title>Demonstration of aria-describedby property</title>
+<style type="text/css">
+div.form p { clear:left; margin: 0.3em 0;}
+.left {
+ float:left;
+ width:400px;
+}
+.right {
+ width:100px;
+ text-align:right;
+}
+</style>
+</head>
+<body>
+<p>The buttons on this page use the Accessible Rich Internet Applications aria-describedby property
+to provide more detailed information about the button action</p>
+<div class="form">
+<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
+<span class="right"><button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">
+Fonts </button></span></p>
+<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
+<span class="right"><button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">
+Colors </button></span></p>
+<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
+<span class="right"><button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">
+Customize </button></span></p>
+</div>
+</body>
+</html>
+
+
+
Example 6: HTML
+
This example uses scripting to add an aria-describedby property to buttons on a page.
+ The example creates a buttonIds array variable to hold the ids of the elements that
+ contain description text. The setDescribedBy() function is called from the onload
+ event of the window object.
+
+
The setDescribedBy() function loops through all of the button elements and calls setAttribute()
+ on each button element to set the aria-describedby property. Each button's aria-describedby
+ property is set to the id of the element containing its descriptive text.
+
+
Using a user agent and/or assistive technology which supports WAI-ARIA, the description
+ will be provided when the user interface controls receive focus.
+
<html lang="en-us">
+<head>
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<title>Demonstration of aria-describedby property</title>
+<style type="text/css">
+div.form p { clear:left; margin: 0.3em 0;}
+.left {
+ float:left;
+ width:400px;
+}
+.right {
+ width:100px;
+ text-align:right;
+}
+</style>
+<script type="text/javascript">
+//<![CDATA[
+
+// array entries for each button on the page that associates the button id
+// with the id of the element containing the text which describes the button
+var buttonIds = new Array();
+buttonIds["fontB"]= "fontDesc";
+buttonIds["colorB"] = "colorDesc";
+buttonIds["customB"] = "customDesc";
+
+// function that is run after the page has loaded to set the aria-describedBy
+// property on each of the elements referenced by the array of id values
+function setDescribedBy(){
+ if (buttonIds){
+ var buttons = document.getElementsByTagName("button");
+ if (buttons){
+ var buttonId;
+ for(var i=0; i<buttons.length; i++){
+ buttonId = buttons[i].id;
+ if (buttonId && buttonIds[buttonId]){
+ buttons[i].setAttribute("aria-describedby", buttonIds[buttonId]);
+ }
+ }
+ }
+ }
+}
+
+// simulated action function - currently just displays an alert
+function doAction(theAction){
+ alert("Perform the " + theAction + " action");
+}
+
+window.onload=setDescribedBy;
+
+//]]>
+</script>
+</head>
+<body>
+<p>The buttons on this page use the Accessible Rich Internet Applications
+aria-describedby property to provide more detailed information
+about the button action.
+</p>
+<div class="form">
+<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
+ <span class="right"><button id="fontB" onclick="doAction('Fonts');"> Fonts </button></span>
+</p>
+<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
+ <span class="right"><button id="colorB" onclick="doAction('Colors');"> Colors </button></span>
+</p>
+<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
+ <span class="right"><button id="customB" onclick="doAction('Customize');"> Customize </button></span>
+</p>
+</div>
+</body>
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that there is a user interface control having an aria-describedby attribute that references one or more elements via unique id.
+
+
+
Check that the referenced element or elements provide additional information about
+ the user interface control.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA10.html b/wcag21/techniques/aria/ARIA10.html
new file mode 100644
index 0000000..7b53a5e
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA10.html
@@ -0,0 +1,145 @@
+
+
+
+
+ ARIA10: Using aria-labelledby to provide a text alternative for non-text content
+
+
+
+
+
+
+
+
Using aria-labelledby to provide a text alternative for non-text content
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide a short description for an element that
+ can be read by assistive technologies (AT) by using the aria-labelledby attribute. The aria-labelledby attribute associates an element with text that is visible elsewhere on the page by
+ using an ID reference value that matches the ID attribute of the labeling element.
+ Assistive technology such as screen readers use the text of the element identified
+ by the value of the aria-labelledby attribute as the text alternative for the element with the attribute.
+
+
+
+
Examples
+
+
Example 1: Providing a short description for a complex graphic
+
This example shows how to use the aria-labelledby attribute to provide a short text description for a read-only complex graphic of
+ an star rating pattern; the graphic is composed of several image elements. The text
+ alternative for the graphic is the label, visible on the page beneath the star pattern.
+
Examine each element where the aria-labelledby attribute is present and the element does not support the alt attribute.
+
+
+
Check whether the value of the aria-labelledby attribute is the id of an element on the web page.
+
+
+
Determine that the text of the element identified by the aria-labelledby attribute accurately labels the element, provides a description of its purpose, or
+ provides equivalent information.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA11.html b/wcag21/techniques/aria/ARIA11.html
new file mode 100644
index 0000000..d094462
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA11.html
@@ -0,0 +1,278 @@
+
+
+
+
+ ARIA11: Using ARIA landmarks to identify regions of a page
+
+
+
+
+
+
+
+
Using ARIA landmarks to identify regions of a page
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide programmatic access to sections of a web
+ page. Landmark roles (or "landmarks") programmatically identify sections of a page.
+ Landmarks help assistive technology (AT) users orient themselves to a page and help
+ them navigate easily to various sections of a page.
+
+
+
They also provide an easy way for users of assistive technology to skip over blocks
+ of content that are repeated on multiple pages and notify them of programmatic structure
+ of a page. For instance, if there is a common navigation menu found on every page,
+ landmark roles (or "landmarks") can be used to skip over it and navigate from section
+ to section. This will save assistive technology users and keyboard users the trouble
+ and time of tabbing through a large amount of content to find what they are really
+ after, much like a traditional "skip links" mechanism. (Refer to User Agent Notes
+ above for specifics of AT support). A blind user who may be familiar with a news site's
+ menu, and is only interested in getting to the top story could easily navigate to
+ the "main" landmark, and bypass dozens of menu links. In another circumstance, a user
+ who is blind may want to quickly find a navigation menu, and can do so by jumping
+ to the navigation landmark.
+
+
+
Landmarks also can help sighted keyboard-only users navigate to sections of a page
+ using a browser plugin.
+
+
+
Landmarks are inserted into the page using the role attribute on an element that marks
+ the section. The value of the attribute is the name of the landmark. These role values
+ are listed below:
+
+
+
+
+
banner: A region that contains the prime heading or internal title of a page.
+
+
+
+
complementary: Any section of the document that supports the main content, yet is
+ separate and meaningful on its own.
+
+
+
+
contentinfo: A region that contains information about the parent document such as
+ copyrights and links to privacy statements.
+
+
+
+
form: A region of the document that represents a collection of form-associated elements,
+ some of which can represent editable values that can be submitted to a server for
+ processing.
+
+
+
+
main: Main content in a document. In almost all cases a page will have only one role="main".
+
+
+
+
navigation: A collection of links suitable for use when navigating the document or
+ related documents.
+
+
+
+
search: The search tool of a Web document.
+
+
+
+
application: A region declared as a web application, as opposed to a web document.
+ (note: The role of application should only be used with caution because it gives a
+ signal to screen reading software to turn off normal web navigation controls. Simple
+ widgets should generally not be given the application role, nor should an entire web
+ page be given the application role, unless it is not to be used at all like a web
+ page, and not without much user testing with assistive technology.)
+
+
+
+
+
There are cases when a particular landmark role could be used more than once on a
+ page, such as on primary and secondary navigation menus. In these cases, identical
+ roles should be disambiguated from each other using a valid technique for labelling
+ regions (see examples below).
+
+
+
Landmarks should supplement native semantic markup such as HTML headings, lists and
+ other structural markup. Landmarks are interpretable by WAI-ARIA-aware assistive technologies
+ and are not exposed by browsers directly to users.
+
+
+
It is a best practice to include ALL content on the page in landmarks, so that screen
+ reader users who rely on them to navigate from section to section do not lose track
+ of content.
+
+
+
+
+
Examples
+
+
Example 1: Simple landmarks
+
The following example shows how landmarks might be added to an HTML4 or XHTML 1.0
+ document:
+
<div id="header" role="banner">A banner image and introductory title</div>
+<div id="sitelookup" role="search">....</div>
+<div id="nav" role="navigation">...a list of links here ... </div>
+<div id="content" role="main"> ... Ottawa is the capital of Canada ...</div>
+<div id="rightsideadvert" role="complementary">....an advertisement here...</div>
+<div id="footer" role="contentinfo">(c)The Freedom Company, 123 Freedom Way, Helpville, USA</div>
+
+
Example 2: Multiple landmarks of the same type and aria-labelledby
+
The following example shows a best practice of how landmarks might be added to an
+ HTML4 or XHTML 1.0 document in situations where there are more than two of the same
+ type of landmark on the same page. For instance, if a navigation role is used multiple
+ times on a Web page, each instance may have a unique label specified using aria-labelledby:
+
+
+
<div id="leftnav" role="navigaton" aria-labelledby="leftnavheading">
+<h2 id="leftnavheading">Institutional Links</h2>
+<ul><li>...a list of links here ...</li> </ul></div>
+<div id="rightnav" role="navigation" aria-labelledby="rightnavheading">
+<h2 id="rightnavheading">Related topics</h2>
+<ul><li>...a list of links here ...</li></ul></div>
+
+
Example 3: Multiple landmarks of the same type and aria-label
+
The following example shows a best practice of how landmarks might be added to an
+ HTML4 or XHTML 1.0 document in situations where there are more than two of the same
+ type of landmark on the same page, and there is no existing text on the page that
+ can be referenced as the label.
+
<div id="leftnav" role="navigaton" aria-label="Primary">
+<ul><li>...a list of links here ...</li></ul> </div>
+<div id="rightnav" role="navigation" aria-label="Secondary">
+<ul><li>...a list of links here ...</li> </ul></div>
+
+
Example 4: Search form
+
The following example shows a search form with a "search" landmark. The search role
+ typically goes on the form field or a div surrounding the search form.
+
Examine whether the landmark role attribute is applied to the section of the page
+ that corresponds with that role. (i.e., the "navigation" role is applied to a navigation
+ section, the "main" role is applied to where the main content begins.)
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA12.html b/wcag21/techniques/aria/ARIA12.html
new file mode 100644
index 0000000..5050d98
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA12.html
@@ -0,0 +1,170 @@
+
+
+
+
+ ARIA12: Using role=heading to identify headings
+
+
+
+
+
+
+
+
Using role=heading to identify headings
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide a way for Assistive Technologies (AT)
+ to identify
+ a piece of content as a heading. Applying role="heading" to an element causes an AT
+ (like a
+ screen reader) to treat it as though it were a heading.
+
+
+
If there is more than one heading on the page and the heading hierarchy is defined
+ through the
+ visual presentation, the aria-level attribute should be used to indicate the hierarchical level of
+ the heading.
+
+
+
When possible, use native heading mark-up directly. For example, it is preferable
+
+ to use h1 rather than using <div role="heading" aria-level="1">. However, the use of the
+ heading role, instead of heading mark-up, may be necessary. For example, when retrofitting
+ a legacy site where scripts depend on the existing element hierarchy.
+
+
This example demonstrates how to implement simple headings using role="heading" when
+ retrofitting a legacy site where scripts depend on the existing element hierarchy
+ or the level is unknown. For example, web content which is syndicated from various
+ sources may be constructed without knowledge of what the final presentation will be.
+
+
<div role="heading">Global News items</div>
+... a list of global news with editorial comment....
+
+<div role="heading">Local News items</div>
+... a list of local news, with editorial comment ...
+
+
Example 2: Additional heading levels
+
This example demonstrates how to implement a level 7 heading using role="heading"
+ and the aria-level attribute. Since HTML only supports headings through level 6, there is no native
+ element to provide these semantics.
+
...
+<h5>Fruit Trees</h5>
+...
+<h6>Apples</h6>
+<p>Apples grow on trees in areas known as orchards...</p>
+...
+<div role="heading" aria-level="7">Jonagold/div>
+<p>Jonagold is a cross between the Golden Delicious and Jonathan varieties...</p>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine each element with the attribute role="heading".
+
+
+
+
Determine whether the content of the element is appropriate as a heading.
+
+
+
+
If the element has an aria-level attribute, determine whether the value is the appropriate hierarchical level.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA13.html b/wcag21/techniques/aria/ARIA13.html
new file mode 100644
index 0000000..a483467
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA13.html
@@ -0,0 +1,169 @@
+
+
+
+
+ ARIA13: Using aria-labelledby to name regions and landmarks
+
+
+
+
+
+
+
+
Using aria-labelledby to name regions and landmarks
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide names for regions of a page that can be
+ read by assistive technology. The aria-labelledby attribute provides a way to associate an section of the page marked up as a region
+ or landmarks with text that is on the page that labels it.
+
+
+
Landmark roles (or "landmarks") programmatically identify sections of a page. Landmarks
+ help assistive technology (AT) users orient themselves to a page and help them navigate
+ easily to various sections of a page.
+
+
+
Like aria-describedby, aria-labelledby can accept multiple ids to point to other regions of the page using a space separated
+ list. It is also limited to ids for defining these sets.
+
+
+
+
+
Examples
+
+
Example 1: Identify a landmark with on-page text
+
Below is an example of aria-labelledby used on a complementary Landmark. The region of the document to which the heading
+ pertains could be marked with the aria-labelledby property containing the value of the id for the header.
+
Example 2: Identification for Application landmarks
+
The following code snippet for application landmarks with static prose. If you have
+ a regional landmark of type application and static descriptive text is available,
+ then on the application landmark, include an aria-describedby reference to associate
+ the application and the static text as shown here:
+
<div role="application" aria-labelledby="p123" aria-describedby="info">
+ <h1 id="p123">Calendar<h1>
+ <p id="info">
+ This calendar shows the game schedule for the Boston Red Sox.
+ </p>
+<div role="grid">
+ ...
+</div>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine each element with attribute role=region or with a landmark role, where an aria-labelledby attribute is also present.
+
+
+
+
Check that the value of the aria-labelledby attribute is the id of an element on the
+ page.
+
+
+
+
Check that the text of the element with that id accurately labels the section of the
+ page.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA14.html b/wcag21/techniques/aria/ARIA14.html
new file mode 100644
index 0000000..7a6a95b
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA14.html
@@ -0,0 +1,148 @@
+
+
+
+
+ ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
+
+
+
+
+
+
+
+
Using aria-label to provide an invisible label where a visible label cannot be used
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
For sighted users, the context and visual appearance of an element can provide sufficient
+ cues to determine the purpose. An example is the 'X' often used in the top right corner
+ of pop-up divs (light boxes) to indicate the control for closing the div.
+
+
+
In some situations, elements can be given the attribute aria-label to provide an accessible name for situations when there is no visible label due to
+ a chosen design approach or layout but the context and visual appearance of the control
+ make its purpose clear.
+
+
+
In other situations, elements can be given the attribute aria-label to provide an accessible name when the native HTML labeling element is not supported
+ by the control - for example, when a div set to contentEditable is used instead of native form elements such as input type="text" or textarea in order to provide a richer text editing experience.
+
+
+
+
+
Examples
+
+
Example 1: A close button (X) in a pop-up box
+
On a page, a link displays a pop-up box (a div) with additional information. The 'close'
+ element is implemented as a button containing merely the letter 'x'. The property
+ aria-label="close" is used to provide an accessible name to the button.
+
+
<div id="box">
+ This is a pop-up box.
+ <button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>
+</div>
Check that the value of the aria-label attribute properly describes the purpose of an element where user input is required
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA15.html b/wcag21/techniques/aria/ARIA15.html
new file mode 100644
index 0000000..c6a28fc
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA15.html
@@ -0,0 +1,152 @@
+
+
+
+
+ ARIA15: Using aria-describedby to provide descriptions of images
+
+
+
+
+
+
+
+
Using aria-describedby to provide descriptions of images
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to provide descriptions of images when a short
+ text alternative does not adequately convey the function or information provided in
+ the object.
+
+
+
A feature of WAI-ARIA is the ability to associate descriptive text with a section,
+ drawing, form element, picture, and so on using the aria-describedby property. This is similar to the longdesc attribute in that both are useful for providing additional information to help users
+ understand complex images. Like longdesc, descriptive text provided using aria-describedby is separate from the short name provided using the alt attribute in HTML. Unlike longdesc, aria-describedby cannot reference descriptions outside of the page containing the image. An advantage
+ of providing long descriptions using content from the same page as the image is that
+ the alternative is available to all, including sighted people who do not have assistive
+ technology. It is worth noting that as of the time of writing (October 2013) some
+ assistive technologies read aria-describedby content immediately after an image's alt attribute information without user activation
+ - whereas most implementations of longdesc require the user to take explicit action to read the additional description.
+
+
+
Like aria-labelledby, aria-describedby can accept multiple ids to point to other regions of the page using a space separated
+ list. It is also limited to ids for defining these sets.
+
+
+
+
+
Examples
+
+
Example 1: Describing an image
+
The following example shows how aria-describedby can be applied to an image to provide a long description, where that text description
+ is on the same page as the image.
+
+
<img src="ladymacbeth.jpg" alt="Lady MacBeth" aria-describedby="p1">
+<p id="p1">This painting dates back to 1730 and is oil on canvas. It was created by
+Jean-Guy Millome, and represents ...</p>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine each image element where a aria-describedby attribute is present.
+
+
+
+
Examine whether the aria-describedby attribute programatically associates an element with its text description, via the
+ id attribute on the element where the text to be used as the description is found.
+
+
+
+
Examine whether the combined text equivalent and associated text description accurately
+ describe or provide the equivalent purpose to the object.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1, #2, and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA16.html b/wcag21/techniques/aria/ARIA16.html
new file mode 100644
index 0000000..a1b44fe
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA16.html
@@ -0,0 +1,207 @@
+
+
+
+
+ ARIA16: Using aria-labelledby to provide a name for user interface controls
+
+
+
+
+
+
+
+
Using aria-labelledby to provide a name for user interface controls
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide names for user interface controls that
+ can be read by assistive technology. WAI-ARIA provides a way to associate text with
+ a section, drawing, form element, picture, and so on, using the aria-labelledby property. This techniques uses the aria-labelledby attribute to associate a user interface control, such as a form field, with text
+ on the page that labels it.
+
+
+
Like aria-describedby, aria-labelledby can accept multiple ids to point to other elements of the page using a space separated
+ list. This capability makes aria-labelledby especially useful in situations where sighted users use information from the surrounding
+ context to identify a control. ARIA9: Using aria-labelledby to concatenate a label from several text nodes contains more examples of situations where names are created from several other text
+ elements on the page.
+
+
+
While the function of aria-labelledby appears similar to the native HTML label element,
+ there are some differences:
+
+
+
+
+
+ aria-labelledby can reference more than one text element; label can only reference one.
+
+
+
+ aria-labelledby can be used for a variety of elements while the label element can only be used on form elements.
+
+
+
Clicking on a label focuses the associated form field. This does not occur with aria-labelledby. If this behaviour is required then use label or implement this functionality using scripting.
+
+
+
+
+
Note that as of December 2013, label has better support than aria-labelledby, especially in older browsers and assistive technologies.
+
+
+
+
+
Examples
+
+
Example 1: Labelling a simple text field
+
The following is an example of aria-labelledby used on a simple text field to provide a label in a situation where there is no text
+ available for a dedicated label but there is other text on the page that can be used
+ to accurately label the control.
+
Below is an example of aria-labelledby used to provide a label for a slider control. In this case the label text is selected
+ from within a longer adjacent text string. Please note that this example is simplified
+ to show only the labeling relationship; authors implementing custom controls also
+ need to ensure that controls meet other success criteria.
+
<p>Please select the <span id="mysldr-lbl">number of days for your trip</span></p>
+<div id="mysldr" role="slider" aria-labelledby="mysldr-lbl"></div>
+
+
Example 3: A label from multiple sources
+
The following example of aria-labelledby with multiple references uses the label element. For additional detail on concatenating multiple sources of information into
+ a label with aria-labelledby, please view the technique ARIA9: Using aria-labelledby to concatenate a label from several text nodes.
+
+
Note: The use of the label element is included for a number of reasons. If the user clicks on the text of the
+ label element, the corresponding form field will receive focus, which makes the clicking
+ target larger for people with dexterity problems. Also the label element will always be exposed via the accessibility API. A span could have been used (but if so, it should receive a tabindex="-1" so that it will
+ be exposed via the accessibility API in all versions of Internet Explorer). However,
+ a span would lose the advantage of the larger clickable region.
+
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
For each user interface control element where an aria-labelledby attribute is present:
+
+
+
+
+
+
Check that the value of the aria-labelledby attribute is the id of an element or a space separated list of ids on the web page.
+
+
+
+
Check that the text of the referenced element or elements accurately labels the user
+ interface control.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA17.html b/wcag21/techniques/aria/ARIA17.html
new file mode 100644
index 0000000..e8215b8
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA17.html
@@ -0,0 +1,181 @@
+
+
+
+
+ ARIA17: Using grouping roles to identify related form controls
+
+
+
+
+
+
+
+
Using grouping roles to identify related form controls
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to mark up a set of related controls within a form
+ as a group. Any label associated with the group also serves as a common label or qualifier
+ for individual controls in the group. Assistive technologies can indicate the start
+ and end of the group and the group’s label as one navigates into and out of the group.
+ This is a viable alternative for grouping form controls programmatically when the
+ user interface’s design makes it difficult to employ the fieldset-legend technique
+ (H71: Providing a description for groups of form controls using fieldset and legend elements
+ ).
+
+
For a group of radio buttons, one could also use role="radiogroup" instead of role="group".
+
The group can be labeled using aria-labelledby.
+
+
This technique is not meant for wrapping all controls on a form within a single container
+ with role="group".
+
+
+
+
Examples
+
+
Example 1: Social Security Number
+
Social security number fields which are 9 digits long and broken up into 3 segments
+ can be grouped using role="group".
+
This example demonstrates use role=radiogroup. Note also that the radio buttons are
+ custom controls with role=radio. (But the script to make the span actually work like
+ radio buttons is not included in this example. ) One may optionally employ CSS to
+ place a border around groups of such fields to visually reinforce the group relationship.
+ The CSS properties are available below the form.
+
For groups of related controls where the individual labels for each control do not
+ provide a sufficient description, and an additional group level description is needed:
+
+
+
+
+
+
Check that the group of logically related input or select elements are contained
+ within an element with role=group.
+
+
+
+
Check that this group has an accessible name defined using aria-label or aria-labelledby.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA18.html b/wcag21/techniques/aria/ARIA18.html
new file mode 100644
index 0000000..9a5a51d
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA18.html
@@ -0,0 +1,177 @@
+
+
+
+
+ ARIA18: Using aria-alertdialog to Identify Errors
+
+
+
+
+
+
+
+
Using aria-alertdialog to Identify Errors
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to alert people that an input error has occured.
+ Using role="alertdialog" creates a notification. This notification should be modal
+ with the following characteristics:
+
+
+
+
+
+ aria-label or aria-labelledby attribute gives the alertdialog an accessible name.
+
+
+
+
+ aria-describedby provides a reference to the text of the alert.
+
+
+
+
The alertdialog contains at least one focusable control, and the focus should move
+ to that control when the alertdialog opens.
+
+
+
+
The tab order is constrained within the alertdialog whilst it is open.
+
+
+
+
When the dialog is dismissed, the focus moves back to the position it had before the
+ dialog opened, if possible.
+
+
+
+
+
Note that the alertdialog should not be present in a way that it will be accessed
+ by AT until it is needed. One way to do this is not to include it in the static HTML
+ and instead to insert it into the DOM via script when the error condition is triggered.
+ The insertion would correspond to the following HTML sample.
+
+
+
+
+
Examples
+
+
Example 1: Alert dialog
+
This example shows how a notification using role="alertdialog" can be used to notify
+ someone they have entered invalid information.
+
<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
+<h1 id="alertHeading">Error</h1>
+<div id="alertText">Employee's Birth Date is after their hire date. Please verify the birth date and hire date.</div>
+<button>Save and Continue</button>
+<button>Return to page and correct error</button>
+</div>
Trigger the error that causes the alertdialog to appear.
+
+
+
+
Determine that the alertdialog contains at least one focusable control, and the focus
+ moves to that control when the alertdialog opens.
+
+
+
+
Determine that the tab order is constrained within the alertdialog while it is open,
+ and when the dialog is dismissed, the focus moves back to the position it had before
+ the dialog opene, if possible.
+
+
+
+
Examine the element with role="alertdialog" applied.
+
+
+
+
Determine that either the aria-label or aria-labelledby attribute has been correctly used to give the alertdialog an accessible name.
+
+
+
+
Determine that the contents of the alertdialog identifies the input error.
+
+
+
+
Determine whether contents of the alertdialog suggests how to fix the error.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks 2, 3, 5 and 6 are true. For SC 3.3.3, Check 7 is also true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA19.html b/wcag21/techniques/aria/ARIA19.html
new file mode 100644
index 0000000..b60ba35
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA19.html
@@ -0,0 +1,201 @@
+
+
+
+
+ ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
+
+
+
+
+
+
+
+
Using ARIA role=alert or Live Regions to Identify Errors
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to notify Assistive Technologies (AT) when an input
+ error occurs. The aria-live attribute makes it possible for an AT (such as a screen reader) to be notified when
+ error messages are injected into a Live Region container. The content within the aria-live region is automatically read by the AT, without the AT having to focus on the place
+ where the text is displayed.
+
+
+
There are also a number of special case live region roles which can be used instead of applying live region properties directly.
+
+
+
+
Examples
+
+
Example 1: Injecting error messages into a container with role=alert already present
+ in the DOM
+
+
The following example uses role=alert which is equivalent to using aria-live=assertive.
+
+
+
In the example there is an empty error message container element with aria-atomic=true
+ and an aria-live property or alert role present in the DOM on page load. The error
+ container must be present in the DOM on page load for the error message to be spoken
+ by most screen readers. aria-atomic=true is necessary to make Voiceover on iOS read
+ the error messages after more than one invalid submission.
+
+
+
jQuery is used to test if the inputs are empty on submit and inject error messages
+ into the live region containers if so. Each time a new submit is attempted the previous
+ error messages are removed from the container and new error messages injected.
+
+
<script src="http://code.jquery.com/jquery.js"></script>
+<script>
+$(document).ready(function(e) {
+ $('#signup').submit(function() {
+ $('#errors').html('');
+ if ($('#first').val() === '') {
+ $('#errors').append('<p>Please enter your first name.</p>');
+ }
+ if ($('#last').val() === '') {
+ $('#errors').append('<p>Please enter your last name.</p>');
+ }
+ if ($('#email').val() === '') {
+ $('#errors').append('<p>Please enter your email address.</p>');
+ }
+ return false;
+ });
+});
+</script>
+
+<form name="signup" id="signup" method="post" action="">
+ <p id="errors" role="alert" aria-atomic="true"></p>
+ <p>
+ <label for="first">First Name (required)</label><br>
+ <input type="text" name="first" id="first">
+ </p>
+ <p>
+ <label for="last">Last Name (required)</label><br>
+ <input type="text" name="last" id="last">
+ </p>
+ <p>
+ <label for="email">Email (required)</label><br>
+ <input type="text" name="email" id="email">
+ </p>
+ <p>
+ <input type="submit" name="button" id="button" value="Submit">
+ </p>
+</form>
Determine that an empty error container role=alert or aria-live=assertive attribute
+ is present in the DOM at page load.
+
+
+
Trigger the error that causes the content in the live region to appear or update.
+
+
+
+
Determine that the error message was injected into the already present error container.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA2.html b/wcag21/techniques/aria/ARIA2.html
new file mode 100644
index 0000000..6576dd6
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA2.html
@@ -0,0 +1,302 @@
+
+
+
+
+ ARIA2: Identifying a required field with the aria-required property
+
+
+
+
+
+
+
+
Identifying a required field with the aria-required property
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to provide programmatic indication that a form
+ field (which shown through presentation to be required) is mandatory for successful
+ submission of a form.
+
+
The fact that the element is required is often visually presented (via a text or non-text
+ symbol, or text indicating input is required or color / styling) but this is not programmatically
+ determinable as part of the field's name.
+
+
The WAI-ARIA aria-required property indicates that user input is required before submission. The aria-required property can have values of true or false. For example, if a user must fill in an address field, then aria-required is set to true.
+
+
+
Note
+
+
+
Note: Use of aria-required="true" might be beneficial even when an asterisk or other
+ text symbol is programmatically associated with the field as it may reinforce its
+ required property for some assistive technology users.
+
+
+
The fact that the element is required is often visually presented (such as a sign
+ or symbol after the control). Using the aria-required property in addition to the visual presentation makes it much easier for user agents
+ to pass on this important information to the user in a user agent-specific manner.
+ Refer to Supporting ARIA in XHTML and HTML 4.01 for information on how to provide WAI-ARIA States and Properties with XHTML and
+ HTML. WAI-ARIA States and Properties is compatible with other languages as well;
+ refer to documentation in those languages.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
The required property is indicated by an asterisk placed next to the label element:
+
Required fields are indicated by a red border around the fields and a star icon rendered
+ via CSS using content:before. This example also uses custom radio buttons with role=radio
+ but the script to make the span actually work like radio buttons is not included in
+ this example. The CSS properties are available below the form.
+
+
The following example shows an XHTML document using the aria-required property to indicate that a form field must be submitted. The mandatory nature
+ of the field is also indicated in the label as a fallback for user agents that do
+ not support WAI-ARIA.
+
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1
+ For Accessible Adaptable Applications//EN"
+ "https://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+ xml:lang="en">
+ <head>
+ <title>Required Input</title>
+ </head>
+ <body>
+ <h1>Required Input</h1>
+ <p>The following form input field must be completed by the user
+ before the form can be submitted.</p>
+ <form action="http://example.com/submit">
+ <p>
+ <label for="test">Test (required)</label>
+ <input name="ariaexample" id="example" aria-required="true" aria-label="Test"/>
+ </p>
+ <p>
+ <input type="submit" value="Submit" />
+ </p>
+ </form>
+ </body>
+</html>
+
+
+
Example 5: Adding aria-required property via script
+
+
This example uses scripting to add the aria-required property to a form element. The required property is assigned using the setAttribute()
+ API.
+
+
The array variable, requiredIds, is created with the ids of the elements which need to be marked as required. The
+ setRequired() function is called from the onload event of the window object.
+
+
The setRequired() function loops through all of the ids provided, retrieves the
+ element and assigns the aria-required property of true using the setAttribute() function.
+
+
When this page is accessed using Firefox 3.0 or later and a screen reader that supports
+ WAI-ARIA, the screen reader will speak "required" when reading the label for the
+ input fields.
+
<head>
+ <script type="text/javascript">
+ //<![CDATA[
+
+ // array or ids on the required fields on this page
+ var requiredIds = new Array( "firstName", "lastName");
+
+ // function that is run after the page has loaded to set the aria-required property on each of the
+ //elements in requiredIds array of id values
+ function setRequired(){
+ if (requiredIds){
+ var field;
+ for (var i = 0; i< requiredIds.length; i++){
+ field = document.getElementById(requiredIds[i]);
+ field.setAttribute("aria-required", "true");
+ }
+ }
+ }
+ window.onload=setRequired;
+//]]>
+ </script>
+ </head>
+ <body>
+ <p>Please enter the following data. Required fields have been programmatically identified
+ as required and marked with an asterisk (*) following the field label.</p>
+ <form action="submit.php">
+ <p>
+ <label for="firstName">First Name *: </label><input type="text" name="firstName"
+ id="firstName" value="" />
+ <label for="lastName">Last Name *: </label><input type="text" name="lastName"
+ id="lastName" value="" />
+ </p>
+ </form>
+ </body>
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
For each control which is shown via presentation to be required.
+
+
+
+
Check whether the aria-required attribute is present:
+
+
+
Check whether the value of the aria-required attribute is the correct required state of the user interface component.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA20.html b/wcag21/techniques/aria/ARIA20.html
new file mode 100644
index 0000000..36f7112
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA20.html
@@ -0,0 +1,174 @@
+
+
+
+
+ ARIA20: Using the region role to identify a region of the page
+
+
+
+
+
+
+
+
Using the region role to identify a region of the page
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique demonstrates how to assign a generic region role to a section of a page so that user agents and assistive technologies may be
+ able to programmatically identify it. The region role demarcates a segment of the page that contains content of significance so that
+ it is more readily discoverable and navigable. The generic region should be used when
+ the section cannot be marked up using a standard document landmark role (see ARIA11: Using ARIA landmarks to identify regions of a page).
+
+
It is important to name regions, because they are generic grouping elements and users
+ will need some way to tell which region they are in. Regions can be named using aria-labelledby, aria-label, or another technique. Doing so helps to better expose content and information relationships
+ on the page. The role of region should be used prudently, because if overused they can make the page overly verbose
+ for screen reader users.
+
+
+
+
Examples
+
+
Example 1: Region on a news website
+
A section on the home page of a news website that contains a poll that changes every
+ week is marked up with role="region". The h3 text above the form is referenced as
+ the region's name using aria-labelledby.
+
+<div role="region" aria-labelledby="pollhead">
+<h3 id="pollhead">This week's Poll</h3>
+<form method="post" action="#">
+ <fieldset>
+ <legend>Do you believe the tax code needs to be overhauled?</legend>
+ <input type="radio" id="r1" name="poll" />
+ <label for="r1">No, it's fine the way it is</label>
+ <input type="radio" id="r2" name="poll" />
+ <label for="r2">Yes, the wealthy need to pay more</label>
+ <input type="radio" id="r3" name="poll" />
+ <label for="r3">Yes, we need to close corporate loopholes</label>
+ <input type="radio" id="r4" name="poll" />
+ <label for="r4">Changes should be made across the board</label>
+ </fieldset>
+</form>
+<a href="results.php">See Poll Results</a>
+</div>
+
+
+
Example 2: Identifying a region on a banking site
+
A user can expand links on a bank website after logging in to see details of term
+ deposit accounts. The details are within a span marked up with region role. The heading for the region has role=heading and is included in the aria-labelledby that names the region.
+
Example 3: Identifying a portlet with a generic region
+
This example shows how a generic region landmark might be added to a weather portlet. There is no existing text on the page
+ that can be referenced as the label, so it is labelled with aria-label.
+
+
Examine the content and ensure that it is important enough to have an independent
+ landmark
+
+
+
Ensure that a standard landmark role is not appropriate for this content
+
+
Check that the region has a programmatically determined name
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1-3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA21.html b/wcag21/techniques/aria/ARIA21.html
new file mode 100644
index 0000000..9dc188b
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA21.html
@@ -0,0 +1,255 @@
+
+
+
+
+ ARIA21: Using Aria-Invalid to Indicate An Error Field
+
+
+
+
+
+
+
+
Using Aria-Invalid to Indicate An Error Field
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique demonstrates how aria-invalid may be employed to specifically identify fields that have failed validation. Its
+ use is most suitable when:
+
+
+
+
The error description does not programmatically identify the failed fields
+
+
The failed fields are identified in a manner that is not available to some users -
+ for example by using an error-icon rendered visually by some technique that does not
+ rely on color such as a visual cue like a border.
+
+
+
+
+
Note
+
+
One of the above two situations may be true for a field which has programmatically
+ associated label and / or instructions that conveys data format, a data range, or
+ the required property.
+
+
+
+
While it is always preferable to programmatically associate specific error description
+ with the failed field, the page's design or the framework employed may sometimes constrain
+ the author's ability to do so. In these cases, authors may programmatically set aria-invalid to "true" on the fields that have failed validation. This is interpretable mainly
+ by assistive technologies (like screen readers / screen magnifiers) employed by users
+ who are vision impaired. When a field has aria-invalid set to “true”, VoiceOver in Safari announces “invalid data” when the field gets focus;
+ JAWS and NVDA notify the error as an “invalid entry”.
+
+
This ARIA attribute has to be set / turned on programmatically. It should not be set
+ to “true” before input validation is performed or the form is submitted. Setting aria-invalid to “false” is the same as not placing the attribute for the form control at all.
+ Quite understandably, nothing is conveyed by assistive technology to users in this
+ case.
+
+
When visible text is used to programmatically identify a failed field and / or convey
+ how the error can be corrected, setting aria-invalid to "true" is not required from a strict compliance standpoint but may still provide
+ helpful information for users.
+
+
+
+
Examples
+
+
Example 1: Using aria-invalid on required fields
+
The aria-invalid attribute is used on required fields that have no input. A message above the form
+ conveys that form submission has failed due to this.
+
+
A portion of the jQuery code and the HTML form markup follow:
Aria-invalid and aria-describedby are used together to indicate an error when the personal identification number (PIN),
+ email address, or start date are not in the expected format. The error message is
+ associated with the field using aria-describedby, and aria-invalid makes it easier to programmatically find fields with errors.
+
+
Below is the rendered HTML code for the email address field in Example 1: When an
+ invalid email address is entered by the user such as "samexample.com" (instead of
+ sam@example.com), the HTML code is:
+
jQuery code: jQuery is used to add aria-invalid or aria-describedby attributes as
+ well as the class attribute and append the error text. This is the code that inserts
+ aria-invalid and class="error" but does not associate the error text "incorrect data"
+ with the control programmatically:
+
For each form control that relies on aria-invalid to convey a validation failure:
+
+
+
+
+
Check that aria-invalid is not set to true when a validation failure does not exist.
+
+
+
Check that aria-invalid is set to true when a validation failure does exist.
+
+
+
Check that the programmatically associated labels / programmatically associated instructional
+ text for the field provide enough information to understand the error.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1-3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA22.html b/wcag21/techniques/aria/ARIA22.html
new file mode 100644
index 0000000..1de06b0
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA22.html
@@ -0,0 +1,130 @@
+
+
+
+
+ ARIA22: Using role=status to present status messages
+
+
+
+
+
+
+
+
Using role=status to present status messages
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+ This technique uses the status role from the ARIA specification to notify Assistive Technologies (AT) when content
+ has been updated with information about the user's or application's status. This is
+ done by adding role="status" to the element that contains the status message. The aria live region role of status has an implicit aria-live value of polite, which allows a user to be notified via AT (such as a screen reader) when status
+ messages are added. The role of status also has a default aria-atomic value of true, so that updates to the container marked with a role of status will result in the AT presenting the entire contents of the container to the user,
+ including any author-defined labels (or additional nested elements). Such additional
+ context can be critical where the status message text alone will not provide an equivalent
+ to the visual experience. The content of the aria-live container is automatically
+ read by the AT, without the AT having to focus on the place where the text is displayed.
+ See WAI-ARIA 1.1 status (role) for more details.
+
+
+
+
+
+
Examples
+
+
Example 1: Including a search results message
+
After a user presses a Search button, the page content is updated to include the results
+ of the search, which are displayed in a section below the Search button. The change
+ to content also includes the message "5 results returned" near the top of this new
+ content. This text is given an appropriate role for a status message. A screen reader
+ will announce "Five results returned".
+
After a user presses an Add to Shopping Cart button, content near the Shopping Cart
+ icon updates to read "1 items". The container for this text (in this case a <p>) is marked with the role of status. Because it adds visual context, the shopping cart image -- with succinct and accurate
+ ALT text -- is also placed in the container. Due to the default aria-atomic value, a screen reader will announce "Shopping cart, six items".
+
Check that the container destined to hold the status message has a role attribute with a value of statusbefore the status message occurs.
+
+
+
Check that when the status message is triggered, it is inside the container.
+
+
Check that elements or attributes that provide information equivalent to the visual
+ experience for the status message (such as a shopping cart image with proper ALT text)
+ also reside in the container.
+
+
+
+
+
+
Expected Results
+
+
+
#1, #2 and #3 are true.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA23.html b/wcag21/techniques/aria/ARIA23.html
new file mode 100644
index 0000000..cba040b
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA23.html
@@ -0,0 +1,123 @@
+
+
+
+
+ ARIA23: Using role=log to identify sequential information updates
+
+
+
+
+
+
+
+
Using role=log to identify sequential information updates
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+ The purpose of this technique is to notify Assistive Technologies (AT) when content
+ has been appended to sequential information concerning the application's history or
+ logs. The aria live region role of log has an implicit aria-live value of polite and aria-atomic value of false, which allows a user to be notified via AT (such as a screen reader) when log messages
+ are added. The new content within the aria-live region is automatically read by the
+ AT, without the AT having to focus on the place where the text is displayed. See WAI-ARIA 1.1 log (role) for more details.
+
+
+
+
+
+
Examples
+
+
Example 1: Updating the contents of a chat conversation
+
+
+
Comments that users type into a chat input field are appended to the end of the chat
+ history region. The region is marked with role of log so that new additions are announced by ATs. When each new chat message appears, a
+ screen reader should announce its content (depending on AT/browser compatibility).
+
An application log records time-stamped activities. The log is exposed in the app
+ as a view, with the region marked with the role of log so that the new additions are announced by the ATs. (The default value for the aria-relevant attribute is "additions", so the removal of the old top entries due to log size limitations
+ will not be announced.) When each new log entry is added, a screen reader announces
+ it.
+
On a page that contains sequentially updating information:
+
+
+
Check that the container for the information is given a role of log.
+
+
+
+
+
+
Expected Results
+
+
+
#1 is true.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA24.html b/wcag21/techniques/aria/ARIA24.html
new file mode 100644
index 0000000..d77acf5
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA24.html
@@ -0,0 +1,409 @@
+
+
+
+
+ ARIA24: Semantically identifying a font icon with role="img"
+
+
+
+
+
+
+
+
Semantically identifying a font icon with role="img"
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to show how to semantically identify an element
+ that uses a font file for icons. When a user overrides font-family these icons typically
+ disappear unless there is a means to identify them. The point is to provide a technique
+ to differentiate icon fonts from general font (text) usage.
+
+
Some low vision users need user stylesheets, scripts, or extensions to override the
+ fonts on a page to perceive text content. However, they need to be able to perceive
+ icon fonts that are meaningful, such as a star signifying a favorite, or an email
+ icon in a link.
+
+
The key is for the author to semantically markup icon fonts with role="img". Then the user's font replacement selector can hook into that semantic and exclude
+ role="img". This results in those icon fonts being shown.
+
+
The first step is used for adding a font face with icons via the CSS file.
+
+/* specify font-family name for icons */
+@font-face { font-family: 'IconFontRoleImg';/ }
+
+/* default class for fonts-face with icons */
+.icon,
+[class^="icon-"],
+[class*=" icon-"] { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-star-bg:before { content: "\e982"; }
+
+
The second step adds classes, the role="img" attribute for semantics and an accessible
+ name.
+
+
+<!-- Icon via class names, role="img" and a text alternative -->
+<p>
+ <span class="icon icon-star-bg" role="img" aria-label="Favorite"></span>
+</p>
+
+
The third step uses the ":not selector" in combination with the "[attribute] selector"
+ to only replace font faces for regular text.
+
+
+/* Replaces font faces but excludes all elements with attribute role=""img" */
+*:not([role="img"]) { font-family: Verdana, sans-serif !important; }
+
+
+
+
Examples
+
+
Example 1: Star Icon Font used as an indicator (not interactive)
+
In this example a star icon is used to indicate a favorite. It is not interactive
+ and does not disappear if the user overrides the font family via CSS.
+
+
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-star-bg:before { content: "\e982"; }
+
+
Example 2: Two colored / stacked star Icon Font used as an indicator
+
In this example a two colored star icon is created by stacking two fonts with different
+ colors on top of each other. This way it's possible to mimic only half the star is
+ filled. It is not interactive and does not disappear if the user overrides the font
+ family via CSS.
+
+
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific classes for icons */
+.icon-star-bg:before {content: "\e982"; }
+.icon-star-half:before {content: "\e983"; }
+
+
Example 3: Email Icon Font in a link WITHOUT visible text
+
In this example an email icon is in a link with no visible text. It does not disappear
+ if a user overrides font family. The icon font is identified by assistive technology
+ as a "link image" and the name "Email" (keyboard or mouse).
+
+
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+.icon-email:before { content: "\e93e"; }
+
+
Example 4: Multiple Icon Fonts as part of another sematic element WITH visible text
+
This example already has a visible text label in the link to be used as an accessible
+ name, the mail and chevron font icons must stay visible when the font family is changed.
+ This can be done by ensuring the icons are contained in their own element and the
+ attribute aria-hidden="true" is used so the font icons will be ignored by assistive technologies.
+
+
+
+
Author CSS
+
+
+/* default class for fonts-face with icons */
+.icon { font-family: 'IconFontRoleImg' !important; }
+
+/* specific class for icon */
+- See style declarations in HTML examples -
+
+
+
The element providing the font icon has role="img".
+
+
+
+
+
+
Expected Results
+
+
+
#1 is true.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA4.html b/wcag21/techniques/aria/ARIA4.html
new file mode 100644
index 0000000..e3a134a
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA4.html
@@ -0,0 +1,203 @@
+
+
+
+
+ ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
+
+
+
+
+
+
+
+
Using a WAI-ARIA role to expose the role of a user interface component
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to define the role of an element using the role attribute with one of the non-abstract values defined in the WAI-ARIA Definition of Roles. The WAI-ARIA specification provides an informative description of each role, how
+ it relates to other roles, and the states and properties for each role. When rich
+ internet applications define new user interface widgets, exposing the roles enables
+ users to understand the widget and how to interact with it.
+
The WAI-ARIA Authoring Practices demonstrates a tree widget. Note the use of the roles "tree", "treeitem", and "group" to identify the tree and
+ its structure. Here is a simplified excerpt from the code:
+
For a user interface component using the role attribute:
+
+
+
+
+
Check that the value of the role attribute is one of the non-abstract roles from the
+ values defined in the WAI-ARIA specification.
+
+
+
Check that the characteristics of the user interface component are described by the
+ role.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA5.html b/wcag21/techniques/aria/ARIA5.html
new file mode 100644
index 0000000..6d1b2c2
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA5.html
@@ -0,0 +1,221 @@
+
+
+
+
+ ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface
+ component
+
+
+
+
+
+
+
+
+
Using WAI-ARIA state and property attributes to expose the state of a user interface
+ component
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to use WAI-ARIA state and property attributes to expose the state, properties and values of a user interface component so that
+ they can be read and set by assistive technology, and so that assistive technology
+ is notified of changes to these values. The WAI-ARIA specification provides a normative
+ description of each attribute, and the role of the user interface elements that they
+ support. When rich internet applications define new user interface widgets, exposing
+ the state and property attributes enables users to understand the widget and how to
+ interact with it.
+
+
+
+
Examples
+
+
Example 1: A toggle button
+
A widget with role button acts as a toggle button when it implements the attribute aria-pressed. When aria-pressed is true, the button is in a "pressed" state. When aria-pressed is false, it is not pressed. If the attribute is not present, the button is a simple
+ command button.
+
+
The following snippet from The Open Ajax Accessibility Examples, Example 38, shows
+ WAI-ARIA mark-up for a toggle button that selects bold text:
+
The li element has a role of "button" and an "aria-pressed" attribute. The following excerpt
+ from the Javascript for this example updates the value of the "aria-pressed" attribute:
+
+ /**
+ * togglePressed() toggles the aria-pressed atribute between true or false
+ *
+ * @param ( id object) button to be operated on
+ *
+ * @return N/A
+ */
+ function togglePressed(id) {
+
+ // reverse the aria-pressed state
+ if ($(id).attr('aria-pressed') == 'true') {
+ $(id).attr('aria-pressed', 'false');
+ }
+ else {
+ $(id).attr('aria-pressed', 'true');
+ }
+ }
+
A widget with role slider lets a user select a value from within a given range. The slider represents the current
+ value and the range of possible values via the size of the slider and the position
+ of the handle. These properties of the slider are represented by the attributes aria-valuemin, aria-valuemax, and aria-valuenow.
+
+
The following snippet from The Open Ajax Accessibility Examples, Example 32, shows
+ WAI-ARIA mark-up for a slider created in Javascript. Note that the javascript sets
+ the attributes aria-valuemin, aria-valuemax, and aria-valuenow:
+
The following excerpt from the Javascript for this example updates the value of the
+ "aria-valuenow" attribute when the value of the slider handle is changed:
+
slider.prototype.positionHandle = function($handle, val) {
+ ...
+ // Set the aria-valuenow position of the handle
+ $handle.attr('aria-valuenow', val);
+ ...
+ }
+
For a user interface component using the WAI-ARIA role attribute:
+
+
+
+
Check that the required states and properties for the role are present.
+
+
Check that no WAI-ARIA states or properties that are neither required, supported,
+ nor inherited are present.
+
+
+
Check that the state and property values are updated to reflect the current state
+ when the user interface component changes state.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1, #2, and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA6.html b/wcag21/techniques/aria/ARIA6.html
new file mode 100644
index 0000000..62d1bb2
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA6.html
@@ -0,0 +1,152 @@
+
+
+
+
+ ARIA6: Using aria-label to provide labels for objects
+
+
+
+
+
+
+
+
Using aria-label to provide labels for objects
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to provide a label for objects that can be read by
+ assistive technology. The aria-label attribute provides the text label for an object, such as a button. When a screen
+ reader encounters the object, the aria-label text is read so that the user will know what it is.
+
+
Authors should be aware that aria-label may be disregarded by assistive technologies in situations where aria-labelledby is used for the same object. For more information on the naming hierarchy please
+ consult the ARIA specification and the accessible name and description calculation in the HTML to Platform Accessibility APIs Implementation Guide. Authors should be
+ aware that use of aria-label will override any native naming such as alt on images or label associated with a form field using the for attribute.
+
+
+
+
Examples
+
+
Example 1: Distinguishing navigation landmarks
+
The following example shows how aria-label could be used to distinguish two navigation landmarks in a HTML4 and XHTML 1.0 document,
+ where there are more than two of the same type of landmark on the same page, and there
+ is no existing text on the page that can be referenced as the label.
+
<div role="navigation" aria-label="Primary">
+<ul><li>...a list of links here ...</li></ul> </div>
+<div role="navigation" aria-label="Secondary">
+<ul><li>...a list of links here ...</li> </ul></div>
+
+
Example 2: Identifying region landmarks
+
The following example shows how a generic "region" landmark might be added to a weather
+ portlet. There is no existing text on the page that can be referenced as the label,
+ so it is labelled with aria-label.
+
For each element where a aria-label attribute is present.
+
+
+
+
+
Examine whether the text description accurately labels the object or provides a description
+ of its purpose or provides equivalent information.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA7.html b/wcag21/techniques/aria/ARIA7.html
new file mode 100644
index 0000000..82b9741
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA7.html
@@ -0,0 +1,143 @@
+
+
+
+
+ ARIA7: Using aria-labelledby for link purpose
+
+
+
+
+
+
+
+
Using aria-labelledby for link purpose
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
With the aria-labelledby attribute, authors can use a visible text element on the page as a label for a focusable
+ element (a form control or a link). For example, a "read more..." link could be associated
+ with the text of the heading of the preceding section to make the purpose of the link
+ unambiguous (see example 1).
+
+
When associating text to a focusable element with the help of aria-labelledby, the target text element is given an ID which is referenced in the value of the aria-labelledby attribute of the focusable element.
+
+
It is also possible to use several text elements on the page as a label for a focusable
+ element. Each of the text elements used must be given a unique ID which is referenced
+ as a string of IDs (IDREF) in the value of the aria-labelledby attribute. The label text should then be concatenated following the order of IDs
+ in the value of the aria-labelledby attribute.
+
+
When applied on links, aria-labelledby can be used to identify the purpose of a link that may be readily apparent for sighted
+ users, but less obvious for screen reader users.
+
+
The specified behavior of aria-labelledby is that the associated label text is announced instead of the link text (not in addition
+ to the link text). When the link text itself should be included in the label text,
+ the ID of the link should be referenced as well in the string of IDs forming the value
+ of the aria-labelledby attribute.
+
Example 1: Providing additional information for links
+
This example will mean that the link text as shown on screen is then used as the start
+ of the accessible name for the link. Popular screen readers like JAWS and NVDA will
+ announce this as:
+ "Read more ...Storms hit east coast" and will display that same text in the links
+ list which is very useful for screen reader users who may browse by links.
+
<h2 id="headline">Storms hit east coast</h2>
+
+<p>Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns.
+<a id="p123" href="news.html" aria-labelledby="p123 headline">Read more...</a></p>
+
+
Example 2: Concatenating link text from multiple sources
+
There may be cases where an author will placed a tag around a section of code that
+ will be referenced.
+
+
Note: The use of tabindex="-1" on the span element is not meant to support focusing by scripts - here, it merely serves to ensure
+ that some browsers (IE9, IE10) will include the span element in the accessibility tree, thus making it available for reference by aria-labelledby. For more details see Accessible HTML Elements.
+
For each link that has an aria-labelledby attribute:
+
+
+
+
+
Check that each ID in the value of the aria-labelledby attribute matches an ID of a text element used as part of the link purpose.
+
+
+
Check that the combined value of the text referenced by the one or more ID's in the
+ aria-labelledby attribute properly describes the purpose of the link element.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA8.html b/wcag21/techniques/aria/ARIA8.html
new file mode 100644
index 0000000..c71d401
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA8.html
@@ -0,0 +1,152 @@
+
+
+
+
+ ARIA8: Using aria-label for link purpose
+
+
+
+
+
+
+
+
Using aria-label for link purpose
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe the purpose of a link using the aria-label attribute. The aria-label attribute provides a way to place a descriptive text label on an object, such as
+ a link, when there are no elements visible on the page that describe the object. If
+ descriptive elements are visible on the page, the aria-labelledby attribute should be used instead of aria-label. Providing a descriptive text label lets a user distinguish the link from links in
+ the Web page that lead to other destinations and helps the user determine whether
+ to follow the link. In some assistive technologies the aria-label value will show in the list of links instead of the actual link text.
+
+
Per the Accessible Name and Description Computation and the HTML to Platform Accessibility APIs Implementation Guide, the aria-label text will override the text supplied within the link. As such the text supplied will
+ be used instead of the link text by AT. Due to this it is recommended to start the
+ text used in aria-label with the text used within the link. This will allow consistent communication between
+ users.
+
+
+
+
Examples
+
+
Example 1: Describing the purpose of a link in HTML using aria-label.
+
In some situations, designers may choose to lessen the visual appearance of links
+ on a page by using shorter, repeated link text such as "read more". These situations
+ provide a good use case for aria-label in that the simpler, non-descriptive "read
+ more" text on the page can be replaced with a more descriptive label of the link.
+ The words 'read more' are repeated in the aria-label (which replaces the original
+ anchor text of "[Read more...]") to allow consistent communication between users.
+
<h4>Neighborhood News</h4>
+ <p>Seminole tax hike: Seminole city managers are proposing a 75% increase in
+ property taxes for the coming fiscal year.
+ <a href="taxhike.html" aria-label="Read more about Seminole tax hike">[Read more...]</a>
+ </p>
+
+ <p>Baby Mayor: Seminole voters elect the city's youngest mayor ever by voting in 3 year
+ old Willy "Dusty" Williams in yesterday's mayoral election.
+ <a href="babymayor.html" aria-label="Read more about Seminole's new baby mayor">[Read more...]</a>
+ </p>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that the value of the aria-label attribute properly describes the purpose of the link element.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/ARIA9.html b/wcag21/techniques/aria/ARIA9.html
new file mode 100644
index 0000000..bde6b89
--- /dev/null
+++ b/wcag21/techniques/aria/ARIA9.html
@@ -0,0 +1,315 @@
+
+
+
+
+ ARIA9: Using aria-labelledby to concatenate a label from several text nodes
+
+
+
+
+
+
+
+
Using aria-labelledby to concatenate a label from several text nodes
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The aria-labelledby property can be used to label all visual objects. Applied to inputs, the aria-labelledby property can be used to label native inputs as well as non-native elements, such
+ as custom text inputs constructed with div contenteditable="true".
+
+
One particular use of aria-labelledby is for text inputs in situations where a meaningful label should consist of more
+ than one label string.
+
+
Authors assign unique ids to the label strings to be concatenated as the label for the input element. The value of the aria-labelledby attribute is then a space-separated list of all ids in the order in which the label strings referenced should be read by screen readers.
+ Supporting user agents will concatenate the label strings referenced and read them
+ as one continuous label of the input.
+
+
The concatenation of label strings can be useful for different reasons. In example
+ 1, an input is nested within the context of a full sentence. The desired screen reader
+ output is "Extend time-out to [ 20 ] minutes - edit with autocomplete, selected 20".
+ Since the id of the text input is included in the string of ids referenced by aria-labelledby, the value of the input is included in the concatenated
+ label at the right position.
+
+
Another application of aria-labelledby is when there is no space to provide a visible label next to the input, or when using
+ native labels would create unnecessary redundancy. Here, the use aria-labelledby makes it possible to associate visible elements on the page as label for such inputs.
+ This is demonstrated in example 2 where table column and row headings are concatenated
+ into labels for the text input elements inside the table.
+
+
+
Note
+
+
+
The ARIA accessible name and description calculation specifies that the string specified in aria-labelledby should replace rather than add to the content of the element that carries the property.
+ So adding the aria-labelledby property to a native label should replace the text content inside that label unless
+ the label itself is referenced as part of the sequence of ids in aria-labelledby.
+
+
+
+
+
+
+
Examples
+
+
Example 1: A time-out input field with concatenated label
+
A text input allows users to extend the default time before a time-out occurs.
+
The string "Extend time-out to" is contained in a native label element and is associated with the input with the input by id="timeout-duration"
+ . This label is associated with this input using the for/id association only on user
+ agents that don't support ARIA. On user agents that support ARIA, the for/id association
+ is ignored and the label for the input is provided only by aria-labelledby, per the accessible name and description calculation in the HTML to Platform Accessibility APIs Implementation Guide.
+
+
The aria-labelledby attribute on the text input references three elements: (1) the span containing the native label, (2) the text input containing the default text '20'
+ (recall that this input is not labelled with the for/id associated label text), and
+ (3) the string 'minutes' contained in a span. These elements should be concatenated to provide the full label for the text input
+
+
+
Note
+
+
+
The use of tabindex="-1" on the span element is not meant to support focusing by scripts - here, it merely serves to ensure
+ that some browsers (IE9, IE10) will include the span element in the accessibility tree, thus making it available for reference by aria-labelledby. For more details see Accessible HTML Elements
+
+
A simple data table containing text inputs. The input labels are concatenated through
+ aria-labelledby referencing the respective column and row headers.
+
A conference workshop booking table with two parallel tracks allows users to select
+ the workshop they want to attend. When tabbing through the checkbox inputs in the
+ table, the track (1 or 2), the title, and the speaker of the workshop followed by
+ the adjacent checkbox label "Attend" are provided as concatenated label for the checkboxes
+ via aria-labelledby.
+
+
Some browser / screen reader combinations (e.g. Mozilla Firefox and NVDA) will in
+ addition speak the relevant table cell headers.
+
Check that ids referenced in aria-labelledby are unique and match the ids of the text nodes that together provide the label
+
+
+
Check that the concatenated content of elements referenced by aria-labelledby is descriptive for the purpose or function of the element labeled
+
+
+
+
+
+
+
Expected Results
+
+
+
+
+
+
#1 and #2 are true.
+
+
If this is a sufficient technique for a success criterion, failing this test procedure
+ does not necessarily mean that the success criterion has not been satisfied in some
+ other way, only that this technique has not been successfully implemented and can
+ not be used to claim conformance.
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/aria-log-role.html b/wcag21/techniques/aria/aria-log-role.html
new file mode 100644
index 0000000..07f2c97
--- /dev/null
+++ b/wcag21/techniques/aria/aria-log-role.html
@@ -0,0 +1,89 @@
+
+
+
+
+
+ aria-log-role: ARIA23: Using role=log to identify sequential information updates
+
+
+
+
+
+
+
+
ARIA23: Using role=log to identify sequential information updates
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique is not referenced from any Understanding document.
+
+
+
Examples
+
+
Example 1: Updating the contents of a chat conversation
+
+
+
Comments that users type into a chat input field are appended to the end of the chat
+ history region. The region is marked with role of log so that new additions are announced by ATs. When each new chat message appears, a
+ screen reader should announce its content (depending on AT/browser compatibility).
+
An application log records time-stamped activities. The log is exposed in the app
+ as a view, with the region marked with the role of log so that the new additions are announced by the ATs. (The default value for the aria-relevant attribute is "additions", so the removal of the old top entries due to log size limitations
+ will not be announced.) When each new log entry is added, a screen reader announces
+ it.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/aria/img/work-phone.png b/wcag21/techniques/aria/img/work-phone.png
new file mode 100644
index 0000000000000000000000000000000000000000..323bf50ad08c06c74f6e5d2383bb099ffeb811f1
GIT binary patch
literal 1589
zcmai!X;9J$7{>ox3E}}p+A1bs6q@C+>6W7g2y0fFx!8JP9A*c0dgQSopr*36R;#R6
z9(i<#2$n~wm6m0$Nv@`OZkD+Tl_q2=*{;pB-*#p{yfe@5)BC*7GxKKn`Fa`Zo9hDr
zVCcP_<_`d%pk?g>2QRA}st-&4Qx5nC$YC$5n-ZFum#T7=Ow(&Xzd2X`o3-Nks{W>Z>^O;pg&Bd;$RrNjBX&=2xysjBrpZ?*w@aSpQ3IYfwuTg*
zO(Xvuew2GE<1u}jv;XkgAaxY+9=E-AL0O^jo(PJqlx7cjXLpx{v2=J8{&nV)b)v;n
zha3n_&{@Q+O-VM5jhmWNO$|Kb!v(v}zPAZJ*ZuR6Qn0#ecV4eHX#XGDTG#LQRf!&t
zqmIMt&v@R&KS#l_;7fjbv;}j^4vY%&)9p>Inhh^=MuqQjXg&3vvbh+ys^oVJUCZAU
z8A_8iivr@_p9pwv{WA>Q7z{%<$9GFOt-y-Ew~oS;=h3nSvMxw0WAql)Iw2#sk9a
zw4zYG&zT#q+%IY=Zy}fuTc{H>!akm#9@#3beR_zEINcvP8BJ;2y6W3fEXSC!(s9ie
z$j&sWnR?oXr@fNAKd&OW#nTd%>WWKDbH(Y$kTEI&sSi{NhttVWvA_>H5ki~!h;FV`
z?)@t-hr;|gZ;p;r{h01KbR7cxFK@2bz-FE<<4J7n{Xawl54V>Z!F?{JN!
zX-ex2Jayg)?`UEG(Oq4)2t~)m+nmvqgl}@LwtLgAv)+WX!+1FhZeH}Mr=jTjM;+*Z|2e??ny$S
zoNZgf<N{
zKN+`t7U;}v-SMWA&2Qvgf2~B?VYL^r<2Yl~q_E6N8h0UYjMrVv5fa#>BB6psjD6*>
zZKN*9U>dz*j5xSh5^_Pavw3ys6;IPJ6>;e=Qur~Zl`=Nikd&+`&Km#oJKt}Afu;NK
zG2N9LyKH?FQnR6iDC{v+GM8wfrtkBgx9Hky5}i9c7%&jw$PW|5H~K(D!v~D)63aeD
z5FzghXGkN_Yt8&WF)q86xB&s$j>{X9J6?o|&DS4(IGAu^qDNs}+t&N_*!I5bo^frZ
zM|$bQqqhz3Y(JFmCIG|CQ;E{1wywcN;!K$0`KJmJrQ5?OOxM@I9-MaJ)Vjgr~9pqjoU0<85ry
Z5~QvMP4v#GT(kV@0dKl5O-5yj{sF^!(`Ntx
literal 0
HcmV?d00001
diff --git a/wcag21/techniques/client-side-script/SCR1.html b/wcag21/techniques/client-side-script/SCR1.html
new file mode 100644
index 0000000..05abe92
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR1.html
@@ -0,0 +1,145 @@
+
+
+
+
+ SCR1: Allowing the user to extend the default time limit
+
+
+
+
+
+
+
+
+
+
Allowing the user to extend the default time limit
+
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+ Time limits that are controlled by client-side scripting.
+
+
The objective of this technique is to allow user to extend the default time limit
+ by providing a mechanism to extend the time when scripts provide functionality that
+ has default time limits. In order to allow the user to request a longer time limit,
+ the script can provide a form (for example) allowing the user to enter a larger time
+ limit or indicating that more time is needed. If the user is being warned that a time
+ limit is about to expire (see ), this form can be made available from the warning dialog. The user can extend the
+ time limit to at least 10 times the default time limit, either by allowing the user
+ to indicate how much additional time is needed or by repeatedly allowing the user
+ to extend the time limit.
+
+
+
+
Examples
+
+
+
+ A Web page contains current stock market statistics and is set to refresh periodically.
+ When the user is warned prior to refreshing the first time, the user is provided with
+ an option to extend the time period between refreshes.
+
+
+
+
+ In an online chess game, each player is given a time limit for completing each move.
+ When the player is warned that time is almost up for this move, the user is provided
+ with an option to increase the time.
+
+
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
+ On a Web page that uses scripts to enforce a time limit, wait until the time limit
+ has expired.
+
+
+
+
+ Determine if an option was provided to extend the time limit.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
+ #2 is true and more time is provided to complete the interaction.
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR14.html b/wcag21/techniques/client-side-script/SCR14.html
new file mode 100644
index 0000000..a7b69af
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR14.html
@@ -0,0 +1,156 @@
+
+
+
+
+ SCR14: Using scripts to make nonessential alerts optional
+
+
+
+
+
+
+
+
Using scripts to make nonessential alerts optional
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Scripting technologies which use scripting alerts for non-emergency communication.
The objective of this technique is to display a dialog containing a message (alert)
+ to the user. When the alert is displayed, it receives focus and the user must activate
+ the OK button on the dialog to dismiss it. Since these alerts cause focus to change
+ they may distract the user, especially when used for non-emergency information. Alerts
+ for non-emergency purposes such as displaying a quote of the day, helpful usage tip,
+ or count down to a particular event, are not presented unless the user enables them
+ through an option provided in the Web page.
+
+
This technique assigns a global JavaScript variable to store the user preference for
+ displaying alerts. The default value is false. A wrapper function is created to check
+ the value of this variable before displaying an alert. All calls to display an alert
+ are made to this wrapper function rather than calling the alert() function directly.
+ Early in the page, a button is provided for the user to enable the display of alerts
+ on the page. This technique works on a visit by visit basis. Each time the page
+ is loaded, alerts will be disabled and the user must manually enable them. Alternatively,
+ the author could use cookies to store user preferences across sessions.
+
+
+
+
Examples
+
+
Example 1
+
The script below will display a quote in an alert box every ten seconds, if the user
+ selects the "Turn Alerts On" button. The user can turn the quotes off again by choosing
+ "Turn Alerts Off".
+
+<script type="text/javascript">
+var bDoAlerts = false; // global variable which specifies whether to
+ // display alerts or not
+/* function to enable/disable alerts.
+ * param boolean bOn - true to enable alerts, false to disable them.
+*/
+function modifyAlerts(isEnabled) {
+ bDoAlerts = isEnabled;
+}
+/* wrapper function for displaying alerts. Checks the value of bDoAlerts
+*and only calls the alert() function when bDoAlerts is true.
+*/
+function doAlert(aMessage) {
+ if (bDoAlerts) {
+ alert(aMessage);
+ }
+}
+// example usage - a loop to display famous quotes.
+var gCounter = -1; // global to store counter
+// quotes variable would be initialized with famous quotations
+var quotes = new Array("quote 1", "quote 2", "quote 3", "quote 4", "quote 5");
+function showQuotes() {
+ if (++gCounter >= quotes.length) {
+ gCounter = 0;
+ }
+ doAlert(quotes[gCounter]);
+ setTimeout("showQuotes();", 10000);
+}
+showQuotes();
+</script>
+
Within the body of the page, include a way to turn the alerts on and off. Below is
+ one example:
+
+<body>
+<p>Press the button below to enable the display of famous quotes
+using an alert box<br />
+<button id="enableBtn" type="button" onclick="modifyAlerts(true);">
+Turn Alerts On</button><br />
+<button id="disableBtn" type="button" onclick="modifyAlerts(false);">
+Turn Alerts Off</button></p>
+
For a Web page that supports non-emergency interruptions using a JavaScript alert:
+
+
+
+
Load the Web page and verify that no non-emergency alerts are displayed.
+
+
Verify there is a mechanism to activate the non-emergency alerts.
+
+
Activate the non-emergency alerts and verify that the alerts are displayed.
+
+
+
+
+
+
Expected Results
+
+
+
+
For a Web page that supports non-emergency interruptions using a JavaScript alert,
+ checks 1, 2, and 3 above are true.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR16.html b/wcag21/techniques/client-side-script/SCR16.html
new file mode 100644
index 0000000..56831ab
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR16.html
@@ -0,0 +1,171 @@
+
+
+
+
+ SCR16: Providing a script that warns the user a time limit is about to expire
+
+
+
+
+
+
+
+
Providing a script that warns the user a time limit is about to expire
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+ Time limits exist that are controlled by script.
+
+
+ The objective of this technique is to notify users that they are almost out of time
+ to complete an interaction. When scripts provide functionality that has time limits,
+ the script can include functionality to warn the user of imminent time limits and
+ provide a mechanism to request more time. 20 seconds or more before the time limit
+ occurs, the script provides a confirm dialog that states that a time limit is imminent
+ and asks if the user needs more time. If the user answers "yes" then the time limit
+ is reset. If the user answers "no" or does not respond, the time limit is allowed
+ to expire.
+
+
+
+ This technique involves time limits set with the window.setTimeout() method. If, for
+ example, the time limit is set to expire in 60 seconds, you can set the time limit
+ for 40 seconds and provide the confirm dialog. When the confirm dialog appears, a
+ new time limit is set for the remaining 20 seconds. Upon expiry of the "grace period
+ time limit" the action that would have been taken at the expiry of the 60 second time
+ limit in the original design is taken.
+
+
+
+
+
Examples
+
+
Example 1
+
+ A page of stock market quotes uses script to refresh the page every five minutes in
+ order to ensure the latest statistics remain available. 20 seconds before the five
+ minute period expires, a confirm dialog appears asking if the user needs more time
+ before the page refreshes. This allows the user to be aware of the impending refresh
+ and to avoid it if desired.
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "https://www.w3.org/TR/html4/loose.dtd">
+<html lang="en">
+<head>
+<title>Stock Market Quotes</title>
+<script type="text/javascript">
+<!--
+function timeControl() {
+ // set timer for 4 min 40 sec, then ask user to confirm.
+ setTimeout('userCheck()', 280000);
+}
+function userCheck() {
+ // set page refresh for 20 sec
+ var id=setTimeout('pageReload()', 20000);
+ // If user selects "OK" the timer is reset
+ // else the page will refresh from the server.
+ if (confirm("This page is set to refresh in 20 seconds.
+ Would you like more time?"))
+ {
+ clearTimeout(id);
+ timeControl();
+ }
+}
+function pageReload() {
+ window.location.reload(true);
+}
+timeControl();
+-->
+</script>
+</head>
+<body>
+<h1>Stock Market Quotes</h1>
+...etc...
+</body>
+</html>
+
+ On a Web page that has a time limit controlled by a script:
+
+
+
+
+
+ load the page and start a timer that is 20 seconds less than the time limit.
+
+
+
+
+ when the timer expires, check that a confirmation dialog is displayed warning of the
+ impending time limit.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
+ #2 is true.
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR18.html b/wcag21/techniques/client-side-script/SCR18.html
new file mode 100644
index 0000000..a4b6cd4
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR18.html
@@ -0,0 +1,174 @@
+
+
+
+
+ SCR18: Providing client-side validation and alert
+
+
+
+
+
+
+
+
Providing client-side validation and alert
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to validate user input as values are entered for
+ each field, by means of client-side scripting. If errors are found, an alert dialog
+ describes the nature of the error in text. Once the user dismisses the alert dialog,
+ it is helpful if the script positions the keyboard focus on the field where the error
+ occurred.
+
+
+
+
Examples
+
+
Example 1: Checking a single control with an event handler
+
The following script will check that a valid date has been entered in the form control.
+<label for="date">Date:</label>
+<input type="text" name="date" id="date"
+onchange="if(isNaN(Date.parse(this.value)))
+alert('This control is not a valid date.
+Please re-enter the value.');" />
+
+
+
Example 2: Checking multiple controls when the user submits the form
+
The following sample shows multiple controls in a form. The form element uses the onsubmit attribute which creates an event handler to execute the validation script when the
+ user attempts to submit the form. If the validation is successful, the event returns
+ true and the form submission proceeds; if the validation finds errors, it displays an
+ error message and returns false to cancel the submit attempt so the user can fix the problems.
+
+
+
Note
+
+
+
This example demonstrates an alert for simplicity. A more helpful notification to
+ the user would be to highlight the controls with problems and add information to the
+ page about the nature of the errors and how to navigate to the controls that require
+ data fixes.
+
+
+
Although this example uses an onsubmit attribute on the form element for brevity, normal practice is to create a submit event listener when the
+ page is loaded.
+
+
+
+
+
Script code:
+function validate() {
+ // initialize error message
+ var msg = "";
+
+ //validate name
+ var pattern = /^[a-zA-Z\s]+$/;
+ var el = document.getElementById("name");
+ if (!pattern.test(el.value)) msg += "Name can only have letters and spaces. ";
+
+ // validate number
+ var pattern = /^[\d\-+\.\s]+$/;
+ var el = document.getElementById("tel");
+ if (!pattern.test(el.value)) msg += "Telephone number can only have digits and separators. ";
+
+ if (msg != "") {
+ alert(msg);
+ return false;
+ } else return true;
+}
+
determine if an alert describing the error is provided.
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR19.html b/wcag21/techniques/client-side-script/SCR19.html
new file mode 100644
index 0000000..cd7c4fc
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR19.html
@@ -0,0 +1,245 @@
+
+
+
+
+ SCR19: Using an onchange event on a select element without causing a change of
+ context
+
+
+
+
+
+
+
+
+
Using an onchange event on a select element without causing a change of
+ context
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
HTML and XHTML with support for scripting. This technique uses the try/catch
+ construct of JavaScript 1.4.
+
The objective of this technique is to demonstrate how to correctly use an
+ onchange event with a select element to update other elements on the Web page. This
+ technique will not cause a change of context. When there are one
+ or more select elements on the Web page, an onchange event on one, can
+ update the options in another select element on the Web page. All of the
+ data required by the select elements is included within the Web page.
+
+
It is important to note that the select item which is modified is after the
+ trigger select element in the reading order of the Web page. This ensures
+ that assistive technologies will pick up the change and users will encounter
+ the new data when the modified element receives focus. This technique relies
+ on JavaScript support in the user agent.
+
+
+
+
Examples
+
+
Example 1
+
This example contains two select elements. When an item is selected
+ in the first select, the choices in the other select are updated
+ appropriately. The first select element contains a list of
+ continents. The second select element will contain a partial list of
+ countries located in the selected continent. There is an onchange
+ event associated with the continent select. When the continent
+ selection changes, the items in the country select are modified
+ using JavaScript via the Document Object Model (DOM). All of the
+ data required, the list of countries and continents, is included
+ within the Web page.
+
+
Overview of the code below
+
+
+
countryLists array variable which contains the list of
+ countries for each continent in the trigger select element.
+
+
+
+
countryChange() function which is called by the onchange
+ event of the continent select element.
+
+
+
The XHTML code to create the select elements in the body of
+ the Web page.
+
+
+
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="content-type" content="text/xhtml; charset=utf-8" />
+ <title>Dynamic Select Statements</title>
+<script type="text/javascript">
+ //<![CDATA[
+ // array of possible countries in the same order as they appear in the country selection list
+ var countryLists = new Array(4)
+ countryLists["empty"] = ["Select a Country"];
+ countryLists["North America"] = ["Canada", "United States", "Mexico"];
+ countryLists["South America"] = ["Brazil", "Argentina", "Chile", "Ecuador"];
+ countryLists["Asia"] = ["Russia", "China", "Japan"];
+ countryLists["Europe"]= ["Britain", "France", "Spain", "Germany"];
+ /* CountryChange() is called from the onchange event of a select element.
+ * param selectObj - the select object which fired the on change event.
+ */
+ function countryChange(selectObj) {
+ // get the index of the selected option
+ var idx = selectObj.selectedIndex;
+ // get the value of the selected option
+ var which = selectObj.options[idx].value;
+ // use the selected option value to retrieve the list of items from the countryLists array
+ cList = countryLists[which];
+ // get the country select element via its known id
+ var cSelect = document.getElementById("country");
+ // remove the current options from the country select
+ var len=cSelect.options.length;
+ while (cSelect.options.length > 0) {
+ cSelect.remove(0);
+ }
+ var newOption;
+ // create new options
+ for (var i=0; i<cList.length; i++) {
+ newOption = document.createElement("option");
+ newOption.value = cList[i]; // assumes option string and value are the same
+ newOption.text=cList[i];
+ // add the new option
+ try {
+ cSelect.add(newOption); // this will fail in DOM browsers but is needed for IE
+ }
+ catch (e) {
+ cSelect.appendChild(newOption);
+ }
+ }
+ }
+//]]>
+</script>
+</head>
+<body>
+ <noscript>This page requires JavaScript be available and enabled to function properly</noscript>
+ <h1>Dynamic Select Statements</h1>
+ <label for="continent">Select Continent</label>
+ <select id="continent" onchange="countryChange(this);">
+ <option value="empty">Select a Continent</option>
+ <option value="North America">North America</option>
+ <option value="South America">South America</option>
+ <option value="Asia">Asia</option>
+ <option value="Europe">Europe</option>
+ </select>
+ <br/>
+ <label for="country">Select a country</label>
+ <select id="country">
+ <option value="0">Select a country</option>
+ </select>
+</body>
+ </html>
Navigate to the trigger select element (in this example, the one
+ to select continents) and change the value of the select.
+
+
+
Navigate to the select element that is updated by the trigger
+ (in this example, the one to select countries).
+
+
+
Check that the matching option values are displayed in the other
+ select element.
+
+
+
Navigate to the trigger select element, navigate through the
+ options but do not change the value.
+
+
+
Check that the matching option values are still displayed in the
+ associated element.
+
+
+
+
+
It is recommended that the select elements are tested with an assistive
+ technology to verify that the changes to the associated element are
+ recognized.
+
+
+
+
+
Expected Results
+
+
+
+
Step #3 and #5 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR2.html b/wcag21/techniques/client-side-script/SCR2.html
new file mode 100644
index 0000000..12552df
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR2.html
@@ -0,0 +1,198 @@
+
+
+
+
+ SCR2: Using redundant keyboard and mouse event handlers
+
+
+
+
+
+
+
+
Using redundant keyboard and mouse event handlers
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate using device independent events
+ to change a decorative image in response to a mouse or focus event. Use the onmouseover
+ and onmouseout events to change a decorative image when the mouse moves on top of
+ or away from an element on the page. Also, use the onfocus and onblur events to change
+ the image when the element receives and loses focus.
+
+
The example below has a decorative image in front of an anchor element. When the user
+ mouses over the anchor tag, the decorative image in front of the anchor is changed.
+ When the mouse moves off of the anchor, the image is changed back to its original
+ version. The same image change effect occurs when the user gives keyboard focus to
+ the anchor element. When focus is received the image changes, when focus is lost the
+ image is changed back. This is accomplished by attaching onmouseover, onmouseout,
+ onfocus and onblur event handlers to the anchor element. The event handler is a JavaScript
+ function called updateImage(), which changes the src attribute of the image. The updateImage()
+ is called in response to the onmouseover, onmouseout, onfocus, and onblur events.
+
+
Each image is given a unique id. This unique id is passed to updateImage() along with
+ a boolean value indicating which image is to be used: updateImage(imgId, isOver);.
+ The boolean value of true is passed when the mouse is over the anchor element or it
+ has focus. A false value is passed when the mouse moves off of the anchor element
+ or it loses focus. The updateImage() function uses the image id to load the image
+ and then changes the src attribue based on the boolean value. Note that since the
+ image is for decorative purposes, it has a null alt attribute.
+
+
+
Note
+
+
+
It is best to use images that are similar in size and to specify the height and width
+ attributes on the image element. This will prevent any changes to the layout of the
+ page when the image is updated. This example uses images which are identical in size.
+
+
+
+
+
+
+
+
Examples
+
+
Example 1
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "https://www.w3.org/TR/html4/loose.dtd">
+ <html lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ <title>Changing Image Source in a Device Independent Manner</title>
+ <script type="text/javascript">
+ /* This function will change the image src of an image element.
+ * param imgId - the id of the image object to change
+ * param isOver - true when mouse is over or object has focus,
+ * false when mouse move out or focus is lost
+ */
+ function updateImage(imgId, isOver) {
+ var theImage = document.getElementById(imgId);
+ if (theImage != null) { //could use a try/catch block for user agents supporting at least JavaScript 1.4
+ // These browsers support try/catch - NetScape 6, IE 5, Mozilla, Firefox
+ if (isOver) {
+ theImage.setAttribute("src","yellowplus.gif");
+ }
+ else {
+ theImage.setAttribute("src","greyplus.gif");
+ }
+ }
+ }
+ </script>
+ </head>
+ <body>
+ <p>Mouse over or tab to the links below and see the image change.</p>
+ <a href="https://www.w3.org/wai" onmouseover="updateImage('wai', true);" onfocus="updateImage('wai', true);"
+ onmouseout="updateImage('wai',false);" onblur="updateImage('wai',false);">
+ <img src="greyplus.gif" border="0" alt="" id="wai">
+ W3C Web Accessibility Initiative</a> &
+ <a href="https://www.w3.org/International/" onmouseover="updateImage('i18n', true);"
+ onfocus="updateImage('i18n',true);" onmouseout="updateImage('i18n',false);"
+ onblur="updateImage('i18n',false);">
+ <img src="greyplus.gif" border="0" alt="" id="i18n">
+ W3C Internationalization</a>
+ </body>
+ </html>
+
+
+
+
Tests
+
+
Procedure
+
+
Load the Web page and test the events using a mouse and via the keyboard.
+
+
+
+
Check that the "standard" image is displayed as expected when the Web page is loaded.
+
+
+
+
+
+
Using the Mouse
+
+
+
+
Move the mouse over the element containing the event handlers (in this example it
+ is an anchor element). Check that the image changes to the expected image.
+
+
+
Move the mouse off of the element. Check that the image changes back to the "standard"
+ image.
+
+
+
+
+
+
+
+
+
Using the Keyboard
+
+
+
+
Use the keyboard to set focus to the element containing the event handlers. Check
+ that the image changes to the expected image.
+
+
+
Use the keyboard to remove focus from the element (generally by moving focus to another
+ element). Check that the image changes to the "standard" image.
+
+
+
+
+
+
+
Verify that the layout of other elements on the page is not affected when the image
+ is changed.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
All of the steps for the above checks are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR20.html b/wcag21/techniques/client-side-script/SCR20.html
new file mode 100644
index 0000000..36f21e8
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR20.html
@@ -0,0 +1,280 @@
+
+
+
+
+ SCR20: Using both keyboard and other device-specific functions
+
+
+
+
+
+
+
+
Using both keyboard and other device-specific functions
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Applies to all content that uses Script to implement functionality.
+ The objective of this technique is to illustrate the use of both keyboard-specific
+ and mouse-specific events with code that has a scripting function associated with
+ an event. Using both keyboard-specific and mouse-specific events together ensures
+ that content can be operated by a wide range of devices. For example, a script may
+ perform the same action when a keypress is detected that is performed when a mouse
+ button is clicked. This technique goes beyond the Success Criterion requirement for
+ keyboard access by including not only keyboard access but access using other devices
+ as well.
+
+
+
+ In JavaScript, commonly used event handlers include, onblur, onchange, onclick, ondblclick,
+ onfocus, onkeydown, onkeypress, onkeyup, onload, onmousedown, onmousemove, onmouseout,
+ onmouseover, onmouseup, onreset, onselect, onsubmit, onunload. Some mouse-specific
+ functions have a logical corresponding keyboard-specific function (such as 'onmouseover'
+ and 'onfocus'). A keyboard event handler should be provided that executes the same
+ function as the mouse event handler.
+
+
+
+ The following table suggests keyboard event handlers to pair mouse event handlers.
+
+
+
+
+
Device Handler Correspondences
+
+
+
+
+
+
Use...
+
+
...with
+
+
+
+
+
+
+ mousedown
+
+
+
+
+ keydown
+
+
+
+
+
+
+
+
+ mouseup
+
+
+
+
+ keyup
+
+
+
+
+
+
+
+
+ click
+
+ [1]
+
+
+
+
+ keypress
+
+ [2]
+
+
+
+
+
+
+
+
+ mouseover
+
+
+
+
+ focus
+
+
+
+
+
+
+
+
+ mouseout
+
+
+
+
+ blur
+
+
+
+
+
+
+
+
+
+ 1 Although click is in principle a mouse event handler, most HTML and XHTML user agents
+ also process this event when a native HTML control (e.g. a button or a link) is activated,
+ regardless of whether it was activated with the mouse or the keyboard. In practice,
+ therefore, it is not necessary to duplicate this event when adding handlers to natively
+ focusable HTML elements. However, it is necessary when adding handlers to other events,
+ such as in Example 2 below.
+
+
+ 2 Since the keypress event handler reacts to any key, the event handler function should
+ check first to ensure the Enter key was pressed before proceeding to handle the event.
+ Otherwise, the event handler will run each time the user presses any key, even the
+ tab key to leave the control, and this is usually not desirable.
+
+
+
+ Some mouse-specific functions (such as dblclick and mousemove) do not have a corresponding
+ keyboard-specific function. This means that some functions may need to be implemented
+ differently for each device (for example, including a series of buttons to execute,
+ via keyboard, the equivalent mouse-specific functions implemented).
+
+
+
+
Examples
+
+
Example 1
+
In this example of an image link, the image is changed when the user positions the
+ pointer over the image. To provide keyboard users with a similar experience, the image
+ is also changed when the user tabs to it.
+
+
+ This example shows a custom image control for which both the mouse and the
+ keyboard can be used to activate the function. The mouse event onclick is duplicated
+ by an appropriate keyboard event onkeypress. The tabindex attribute ensures that the
+ keyboard will have a tab stop on the image. Note that in this example, the nextPage()
+ function should check that the keyboard key pressed was Enter, otherwise it will respond
+ to all keyboard actions while the image has focus, which is not the desired behavior.
+
+<img onclick="nextPage();" onkeypress="nextPage();" tabindex="0" src="arrow.gif"
+alt="Go to next page">
+
Note
+
+
+
This example uses tabindex on an img element. Even though this is currently invalid,
+ it is provided as a transitional technique to make this function work. Custom controls
+ like this should also use WAI-ARIA to expose the role and state of the control.
+
+
+
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
+ Check that all interactive functionality can be accessed using the keyboard alone
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
+ #2 is true
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR21.html b/wcag21/techniques/client-side-script/SCR21.html
new file mode 100644
index 0000000..573d571
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR21.html
@@ -0,0 +1,292 @@
+
+
+
+
+ SCR21: Using functions of the Document Object Model (DOM) to add content to a page
+
+
+
+
+
+
+
+
Using functions of the Document Object Model (DOM) to add content to a page
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how to use functions of the Document
+ Object Model (DOM) to add content to a page instead of using document.write or object.innerHTML.
+ The document.write() method does not work with XHTML when served with the correct
+ MIME type (application/xhtml+xml), and the innerHTML property is not part of the DOM
+ specification and thus should be avoided. If the DOM functions are used to add the
+ content, user agents can access the DOM to retrieve the content. The createElement()
+ function can be used to create elements within the DOM. The createTextNode() is used
+ to create text associated with elements. The appendChild(), removeChild(), insertBefore()
+ and replaceChild() functions are used to add and remove elements and nodes. Other
+ DOM functions are used to assign attributes to the created elements.
+
+
+
Note
+
+
+
When adding focusable elements into the document, do not add tabindex attributes to
+ explicitly set the tab order as this can cause problems when adding focusable elements
+ into the middle of a document. Let the default tab order be assigned to the new element
+ by not explicitly setting a tabindex attribute.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
This example demonstrates use of client-side scripting to validate a form. If errors
+ are found appropriate error messages are displayed. The example uses the DOM functions
+ to add error notification consisting of a title, a short paragraph explaining that
+ an error has occurred, and a list of errors in an ordered list. The content of the
+ title is written as a link so that it can be used to draw the user's attention to
+ the error using the focus method. Each item in the list is also written as a link
+ that places the focus onto the form field in error when the link is followed.
+
+
For simplicity, the example just validates two text fields, but can easily be extended
+ to become a generic form handler. Client-side validation should not be the sole means
+ of validation , and should be backed up with server-side validation. The benefit of
+ client-side validation is that you can provide immediate feedback to the user to save
+ them waiting for the errors to come back from the server, and it helps reduce unnecessary
+ traffic to the server.
+
+
Here is the script that adds the event handlers to the form. If scripting is enabled,
+ the validateNumbers() function will be called to perform client-side validation before
+ the form is submitted to the server. If scripting is not enabled, the form will be
+ immediately submitted to the server, so validation should also be implemented on the
+ server.
+
+
+window.onload = initialise;
+function initialise()
+{
+ // Ensure we're working with a relatively standards compliant user agent
+ if (!document.getElementById || !document.createElement || !document.createTextNode)
+ return;
+
+ // Add an event handler for the number form
+ var objForm = document.getElementById('numberform');
+ objForm.onsubmit= function(){return validateNumbers(this);};
+}
+
Here is the validation function. Note the use of the createElement(), createTextNode(),
+ and appendChild() DOM functions to create the error message elements.
+
+function validateNumbers(objForm)
+{
+ // Test whether fields are valid
+ var bFirst = isNumber(document.getElementById('num1').value);
+ var bSecond = isNumber(document.getElementById('num2').value);
+ // If not valid, display errors
+ if (!bFirst || !bSecond)
+ {
+ var objExisting = document.getElementById('validationerrors');
+ var objNew = document.createElement('div');
+ var objTitle = document.createElement('h2');
+ var objParagraph = document.createElement('p');
+ var objList = document.createElement('ol');
+ var objAnchor = document.createElement('a');
+ var strID = 'firsterror';
+ var strError;
+ // The heading element will contain a link so that screen readers
+ // can use it to place focus - the destination for the link is
+ // the first error contained in a list
+ objAnchor.appendChild(document.createTextNode('Errors in Submission'));
+ objAnchor.setAttribute('href', '#firsterror');
+ objTitle.appendChild(objAnchor);
+ objParagraph.appendChild(document.createTextNode('Please review the following'));
+ objNew.setAttribute('id', 'validationerrors');
+ objNew.appendChild(objTitle);
+ objNew.appendChild(objParagraph);
+ // Add each error found to the list of errors
+ if (!bFirst)
+ {
+ strError = 'Please provide a numeric value for the first number';
+ objList.appendChild(addError(strError, '#num1', objForm, strID));
+ strID = '';
+ }
+ if (!bSecond)
+ {
+ strError = 'Please provide a numeric value for the second number';
+ objList.appendChild(addError(strError, '#num2', objForm, strID));
+ strID = '';
+ }
+ // Add the list to the error information
+ objNew.appendChild(objList);
+ // If there were existing errors, replace them with the new lot,
+ // otherwise add the new errors to the start of the form
+ if (objExisting)
+ objExisting.parentNode.replaceChild(objNew, objExisting);
+ else
+ {
+ var objPosition = objForm.firstChild;
+ objForm.insertBefore(objNew, objPosition);
+ }
+ // Place focus on the anchor in the heading to alert
+ // screen readers that the submission is in error
+ objAnchor.focus();
+ // Do not submit the form
+ objForm.submitAllowed = false;
+ return false;
+ }
+ return true;
+}
+
+// Function to validate a number
+function isNumber(strValue)
+{
+ return (!isNaN(strValue) && strValue.replace(/^\s+|\s+$/, '') !== '');
+}
+
Below are the helper functions to create the error message and to set focus to the
+ associated form field.
+
+// Function to create a list item containing a link describing the error
+// that points to the appropriate form field
+function addError(strError, strFragment, objForm, strID)
+{
+ var objAnchor = document.createElement('a');
+ var objListItem = document.createElement('li');
+ objAnchor.appendChild(document.createTextNode(strError));
+ objAnchor.setAttribute('href', strFragment);
+ objAnchor.onclick = function(event){return focusFormField(this, event, objForm);};
+ objAnchor.onkeypress = function(event){return focusFormField(this, event, objForm);};
+ // If strID has a value, this is the first error in the list
+ if (strID.length > 0)
+ objAnchor.setAttribute('id', strID);
+ objListItem.appendChild(objAnchor);
+ return objListItem;
+}
+
+// Function to place focus to the form field in error
+function focusFormField(objAnchor, objEvent, objForm)
+{
+ // Allow keyboard navigation over links
+ if (objEvent && objEvent.type == 'keypress')
+ if (objEvent.keyCode != 13 && objEvent.keyCode != 32)
+ return true;
+ // set focus to the form control
+ var strFormField = objAnchor.href.match(/[^#]\w*$/);
+ objForm[strFormField].focus();
+ return false;
+}
This example is limited to client-side scripting, and should be backed up with server-side
+ validation. The example is limited to the creation of error messages when client-side
+ scripting is available.
+
+
Examine the source code and check that the new content is not created using document.write(),
+ innerHTML, outerHTML, innerText or outerText.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR22.html b/wcag21/techniques/client-side-script/SCR22.html
new file mode 100644
index 0000000..caf9cc4
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR22.html
@@ -0,0 +1,123 @@
+
+
+
+
+ SCR22: Using scripts to control blinking and stop it in five seconds or less
+
+
+
+
+
+
+
+
Using scripts to control blinking and stop it in five seconds or less
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Technologies that support script-controlled blinking of content.
The objective of this technique is to control blinking with script so it can be set
+ to stop in less than five seconds by the script. Script is used to start the blinking
+ effect of content, control the toggle between visible and hidden states, and also
+ stop the effect at five seconds or less. The setTimeout() function can be used to
+ toggle blinking content between visible and hidden states, and stop when the number
+ of iterations by the time between them adds up to nearly five seconds.
+
+
+
+
Examples
+
+
Example 1
+
This example uses JavaScript to control blinking of some HTML and XHTML content. JavaScript
+ creates the blinking effect by changing the visibility status of the content. It controls
+ the start of the effect and stops it within five seconds.
+
+...
+<div id="blink1" class="highlight">New item!</div>
+<script type="text/javascript">
+<!--
+// blink "on" state
+function show()
+{
+ if (document.getElementById)
+ document.getElementById("blink1").style.visibility = "visible";
+}
+// blink "off" state
+function hide()
+{
+ if (document.getElementById)
+ document.getElementById("blink1").style.visibility = "hidden";
+}
+// toggle "on" and "off" states every 450 ms to achieve a blink effect
+// end after 4500 ms (less than five seconds)
+for(var i=900; i < 4500; i=i+900)
+{
+ setTimeout("hide()",i);
+ setTimeout("show()",i+450);
+}
+-->
+</script>
+...
+
Start a timer for 5 seconds at the start of the blink effect.
+
+
When the timer expires, determine if the blinking has stopped.
+
+
+
+
+
+
Expected Results
+
+
+
+
For each instance of blinking content, #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR24.html b/wcag21/techniques/client-side-script/SCR24.html
new file mode 100644
index 0000000..16d52d6
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR24.html
@@ -0,0 +1,186 @@
+
+
+
+
+ SCR24: Using progressive enhancement to open new windows on user request
+
+
+
+
+
+
+
+
Using progressive enhancement to open new windows on user request
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to avoid confusion that may be caused by
+ the appearance of new windows that were not requested by the user. Suddenly
+ opening new windows can disorient or be missed completely by some users.
+ If the document type does not allow the target attribute (it
+ does not exist in HTML 4.01 Strict or XHTML 1.0 Strict) or if the developer
+ prefers not to use it, new windows can be opened with ECMAScript. The
+ example below demonstrates how to open new windows with script: it adds an
+ event handler to a link (a element) and warns the user that the
+ content will open in a new window.
+
+
+
+
Examples
+
+
Example 1
+
Markup:
+
The script is included in the head of the document, and the link has
+ an id that can be used as a hook by the script.
+
+// Use traditional event model whilst support for event registration
+// amongst browsers is poor.
+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);}
+ // UAAG requires that user agents handle events in a device-independent manner
+ // but only some browsers do this, so add keyboard event to be sure
+ objAnchor.onkeypress = function(event){return launchWindow(this, event);}
+ }
+}
+
+function launchWindow(objAnchor, objEvent)
+{
+ var iKeyCode, bSuccess=false;
+
+ // If the event is from a keyboard, we only want to open the
+ // new window if the user requested the link (return or space)
+ if (objEvent && objEvent.type == 'keypress')
+ {
+ if (objEvent.keyCode)
+ iKeyCode = objEvent.keyCode;
+ else if (objEvent.which)
+ iKeyCode = objEvent.which;
+
+ // If not carriage return or space, return true so that the user agent
+ // continues to process the action
+ if (iKeyCode != 13 && iKeyCode != 32)
+ return true;
+ }
+
+ bSuccess = window.open(objAnchor.href);
+
+ // If the window did not open, allow the browser to continue the default
+ // action of opening in the same window
+ if (!bSuccess)
+ return true;
+
+ // The window was opened, so stop the browser processing further
+ return false;
+}
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Activate each link in the document to check if it opens a new window.
+
+
+
+
For each link that opens a new window, check that it uses script to accomplish each
+ of the following:
+
+
+
+
+
indicates that the link will open in a new window,
+
+
uses device-independent event handlers, and
+
+
allows the browser to open the content in the same window if a new window was not
+ opened.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR26.html b/wcag21/techniques/client-side-script/SCR26.html
new file mode 100644
index 0000000..45200db
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR26.html
@@ -0,0 +1,135 @@
+
+
+
+
+ SCR26: Inserting dynamic content into the Document Object Model immediately following its
+ trigger element
+
+
+
+
+
+
+
+
+
Inserting dynamic content into the Document Object Model immediately following its
+ trigger element
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to place inserted user interface elements into
+ the Document Object Model (DOM) in such a way that the tab order and screen-reader
+ reading order are set correctly by the default behavior of the user agent. This technique
+ can be used for any user interface element that is hidden and shown, such as menus
+ and dialogs.
+
+
The reading order in a screen-reader is based on the order of the HTML or XHTML elements
+ in the Document Object Model, as is the default tab order. This technique inserts
+ new content into the DOM immediately following the element that was activated to trigger
+ the script. The triggering element must be a link or a button, and the script must
+ be called from its onclick event. These elements are natively focusable, and their
+ onclick event is device independent. Focus remains on the activated element and the
+ new content, inserted after it, becomes the next thing in both the tab order and screen-reader
+ reading order.
+
+
Note that this technique works for synchronous updates. For asynchronous updates (sometimes
+ called AJAX), an additional technique is needed to inform the assistive technology
+ that the asynchronous content has been inserted.
+
+
+
+
Examples
+
+
Example 1
+
This example creates a menu when a link is clicked and inserts it after the link.
+ The onclick event of the link is used to call the ShowHide script, passing in an ID
+ for the new menu as a parameter.
+
The ShowHide script creates a div containing the new menu, and inserts a link into
+ it. The last line is the core of the script. It finds the parent of the element that
+ triggered the script, and appends the div it created as a new child to it. This causes
+ the new div to be in the DOM after the link. When the user hits tab, the focus will
+ go to the first focusable item in the menu, the link we created.
+
function ShowHide(id,src)
+{
+ var el = document.getElementById(id);
+ if (!el)
+ {
+ el = document.createElement("div");
+ el.id = id;
+ var link = document.createElement("a");
+ link.href = "javascript:void(0)";
+ link.appendChild(document.createTextNode("Content"));
+ el.appendChild(link);
+ src.parentElement.appendChild(el);
+ }
+ else
+ {
+ el.style.display = ('none' == el.style.display ? 'block' : 'none');
+ }
+}
CSS is used to make the div and link look like a menu.
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Find all areas of the page that trigger dialogs that are not pop-up windows.
+
+
Check that the dialogs are triggered from the click event of a button or a link.
+
+
Using a tool that allows you to inspect the DOM generated by script, check that the
+ dialog is next in the DOM.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR27.html b/wcag21/techniques/client-side-script/SCR27.html
new file mode 100644
index 0000000..370f046
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR27.html
@@ -0,0 +1,196 @@
+
+
+
+
+ SCR27: Reordering page sections using the Document Object Model
+
+
+
+
+
+
+
+
Reordering page sections using the Document Object Model
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to provide a mechanism for re-ordering component
+ which is both highly usable and accessible. The two most common mechanisms for reordering
+ are to send users to a set-up page where they can number components, or to allow them
+ to drag and drop components to the desired location. The drag and drop method is much
+ more usable, as it allows the user to arrange the items in place, one at a time, and
+ get a feeling for the results. Unfortunately, drag and drop relies on the use of a
+ mouse. This technique allows users to interact with a menu on the components to reorder
+ them in place in a device independent way. It can be used in place of, or in conjunction
+ with drag and drop reordering functionality.
+
+
The menu is a list of links using the device-independent onclick event to trigger
+ scripts which re-order the content. The content is re-ordered in the Document Object
+ Model (DOM), not just visually, so that it is in the correct order for all devices.
+
+
+
+
+
Examples
+
+
Example 1
+
This example does up and down reordering. This approach can also be used for two-dimensional
+ reordering by adding left and right options.
+
+
The components in this example are list items in an unordered list. Unordered lists
+ are a very good semantic model for sets of similar items, like these components. The
+ menu approach can also be used for other types of groupings.
+
+
The modules are list items, and each module, in addition to content in div elements,
+ contains a menu represented as a nested list.
+
<ul id="swapper">
+ <li id="black">
+ <div class="module">
+ <div class="module_header">
+ <!-- menu link -->
+ <a href="#" onclick="ToggleMenu(event);">menu</a>
+ <!-- menu -->
+ <ul class="menu">
+ <li><a href="#" onclick="OnMenuClick(event)"
+ onkeypress="OnMenuKeypress(event);">up</a></li>
+ <li><a href="#" onclick="OnMenuClick(event)"
+ onkeypress="OnMenuKeypress(event);">down</a></li>
+ </ul>
+ </div>
+ <div class="module_body">
+ Text in the black module
+ </div>
+ </div>
+ </li>
+ ...
+</ul>
Since we've covered the showing and hiding of menus in the simple tree samples, we'll
+ focus here just on the code that swaps the modules. Once we harmonize the events and
+ cancel the default link action, we go to work. First, we set a bunch of local variables
+ for the elements with which we'll be working: the menu, the module to be reordered,
+ the menuLink. Then, after checking the reorder direction, we try to grab the node
+ to swap. If we find one, we then call swapNode() to swap our two modules, and PositionElement()
+ to move the absolutely-positioned menu along with the module, and then set focus back
+ on the menu item which launched the whole thing.
+
function MoveNode(evt,dir)
+{
+ HarmonizeEvent(evt);
+ evt.preventDefault();
+
+ var src = evt.target;
+ var menu = src.parentNode.parentNode;
+ var module = menu.parentNode.parentNode.parentNode;
+ var menuLink = module.getElementsByTagName("a")[0];
+ var swap = null;
+
+ switch(dir)
+ {
+ case 'up':
+ {
+ swap = module.previousSibling;
+ while (swap && swap.nodeType != 1)
+ {
+ swap = swap.previousSibling;
+ }
+ break;
+ }
+ case 'down':
+ {
+ swap = module.nextSibling;
+ while (swap && swap.nodeType != 1)
+ {
+ swap = swap.nextSibling;
+ }
+ break;
+ }
+ }
+ if (swap && swap.tagName == node.tagName)
+ {
+ module.swapNode(swap);
+ PositionElement(menu,menuLink,false,true);
+ }
+ src.focus();
+}
The CSS for the node swap is not much different than that of our previous tree samples,
+ with some size and color adjustment for the modules and the small menu.
+
Find all components in the Web Unit which can be reordered via drag and drop.
+
+
Check that there is also a mechanism to reorder them using menus build of lists of
+ links.
+
+
+
Check that the menus are contained within the reorderable items in the DOM.
+
+
Check that scripts for reordering are triggered only from the onclick event of links.
+
+
Check that items are reordered in the DOM, not only visually.
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 through #5 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR28.html b/wcag21/techniques/client-side-script/SCR28.html
new file mode 100644
index 0000000..046e51a
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR28.html
@@ -0,0 +1,193 @@
+
+
+
+
+ SCR28: Using an expandable and collapsible menu to bypass block of content
+
+
+
+
+
+
+
+
Using an expandable and collapsible menu to bypass block of content
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique allows users to skip repeated material by placing that material in
+ a menu that can be expanded or collapsed under user control. The user can skip the
+ repeated material by collapsing the menu. The user invokes a user interface control
+ to hide or remove the elements of the menu. The resources section lists several techniques
+ for menus, toolbars and trees, any of which can be used to provide a mechanism for
+ skipping navigation.
+
+
+
Note
+
+
+
Similiar approaches can be implemented using server-side scripting and reloading a
+ modified version of the Web page.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
The navigation links at top of a Web page are all entries in a menu implemented using
+ HTML, CSS, and Javascript. When the navigation bar is expanded, the navigation links
+ are available to the user. When the navigation bar is collapsed, the links are not
+ available.
+
The table of contents for a set of Web pages is repeated near the beginning of each
+ Web page. A button at the beginning of the table of contents lets the user remove
+ or restore it on the page.
+
Check that some user interface control allows the repeated content to be expanded
+ or collapsed.
+
+
+
Check that when the content is expanded, it is included in the programmatically determined
+ content at a logical place in the reading order.
+
+
+
Check that when the content is collapsed, it is not part of the programmatically determined
+ content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
All checks above are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR29.html b/wcag21/techniques/client-side-script/SCR29.html
new file mode 100644
index 0000000..d3f6ec0
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR29.html
@@ -0,0 +1,226 @@
+
+
+
+
+ SCR29: Adding keyboard-accessible actions to static HTML elements
+
+
+
+
+
+
+
+
Adding keyboard-accessible actions to static HTML elements
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how to provide keyboard access to
+ a user interface control that is implemented by actions to static HTML elements such
+ as div or span. This technique ensures that the element is focusable by setting the
+ tabindex attribute, and it ensures that the action can be triggered from the keyboard
+ by providing an onkeyup or onkeypress handler in addition to an onclick handler.
+
+
When the tabindex attribute has the value 0, the element can be focused via the keyboard
+ and is included in the tab order of the document. When the tabindex attribute has
+ the value -1, the element cannot be tabbed to, but focus can be set programmatically,
+ using element.focus().
+
+
Because static HTML elements do not have actions associated with them, it is not possible
+ to provide a backup implementation or explanation in environments in which scripting
+ is not available. This technique should only be used in environments in which client-side
+ scripting can be relied upon.
+
+
+
Note
+
+
+
Such user interface controls must still satisfy Success Criterion 4.1.2. Applying
+ this technique without also providing role, name, and state information about the
+ user interface control will results in Failure F59, Failure of Success Criterion 4.1.2
+ due to using script to make div or span a user interface control in HTML.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Adding a JavaScript action to a div element
+
The div element on the page is given a unique id attribute and a tabindex attribute
+ with value 0. A script uses the Document Object Model (DOM) to find the div element
+ by its id and add the onclick handler and the onkeyup handler. The onkeyup handler
+ will invoke the action when the Enter key is pressed. Note that the div element must
+ be loaded into the DOM before it can be found and modified. This is usually accomplished
+ by calling the script from the onload event of the body element. The script to add
+ the event handlers will only execute if the user agent supports and has JavaScript
+ enabled.
+
+...
+<script type="text/javascript">
+ // this is the function to perform the action. This simple example toggles a message.
+ function doSomething(event) {
+ var msg=document.getElementById("message");
+ msg.style.display = msg.style.display=="none" ? "" : "none";
+ //return false from the function to make certain that the href of the link does not get invoked
+ return false;
+ }
+ // this is the function to perform the action when the Enter key has been pressed.
+ function doSomethingOnEnter(event) {
+ var key = 0;
+ // Determine the key pressed, depending on whether window.event or the event object is in use
+ if (window.event) {
+ key = window.event.keyCode;
+ } else if (event) {
+ key = event.keyCode;
+ }
+ // Was the Enter or Space key pressed?
+ if (key == 13 || key == 32) {
+ return doSomething(event);
+ }
+ // The event has not been handled, so return true
+ return true;
+ }
+ // This setUpActions() function must be called to set the onclick and onkeyup event handlers onto the existing
+ // div element. This function must be called after the div element with id="active" has been loaded into the DOM.
+ // In this example the setUpActions() function is called from the onload event for the body element.
+ function setUpActions() {
+ // get the div object
+ var active=document.getElementById("active");
+ // assign the onclick handler to the object.
+ active.onclick=doSomething;
+ // assign the onkeyup handler to the object.
+ active.onkeyup=doSomethingOnEnter;
+ }
+ </script>
+
+ <body onload="setUpActions();">
+ <p>Here is the link to modify with a javascript action:</p>
+ <div>
+ <span id="active" tabindex="0" role="button" >Do Something</span>
+ </div>
+ <div aria-live="polite">
+ <div id="message">Hello, world!</div>
+ </div>
+...
+
Check that it is possible to navigate to and give focus to the control via the keyboard
+
+
Set keyboard focus to the control
+
+
Check that pressing ENTER or SPACE invokes the scripting action.
+
+
+
+
+
+
Expected Results
+
+
+
+
All of the checks are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR30.html b/wcag21/techniques/client-side-script/SCR30.html
new file mode 100644
index 0000000..9f13ff9
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR30.html
@@ -0,0 +1,200 @@
+
+
+
+
+ SCR30: Using scripts to change the link text
+
+
+
+
+
+
+
+
Using scripts to change the link text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to allow users to choose to have additional information
+ added to the text of links so that the links can be understood out of context.
+
+
Some users prefer to have links that are self-contained, where there is no need to
+ explore the context of the link. Other users find including the context information
+ in each link to be repetitive and to reduce their ability to use a site. Among users
+ of assistive technology, the feedback to the working group on which is preferable
+ has been divided. This technique allows users to pick the approach that works best
+ for them.
+
+
A link is provided near the beginning of the page that will expand the link text of
+ the links on the page so that no additional context is needed to understand the purpose
+ of any link. It must always be possible to understand the purpose of the expansion
+ link directly from its link text.
+
+
This technique expands the links only for the current page view. It is also possible,
+ and in some cases would be advisable, to save this preference in a cookie or server-side
+ user profile, so that users would only have to make the selection once per site.
+
+
+
+
Examples
+
+
Example 1
+
This example uses Javascript to add contextual information directly to the text of
+ a link. The link class is used to determine which additional text to add. When the
+ "Expand Links" link is activated, each link on the page is tested to see whether additional
+ text should be added.
+
+...
+<script type="text/javascript">
+var expanded = false;
+var linkContext = {
+ "hist":" version of The History of the Web",
+ "cook":" version of Cooking for Nerds"
+};
+
+function doExpand() {
+ var links = document.links;
+
+ for (var i=0; i<links.length; i++) {
+ var link = links[i];
+ var cn = link.className;
+ if (linkContext[cn]) {
+ span = link.appendChild(document.createElement("span"));
+ span.setAttribute("class", "linkexpansion");
+ span.appendChild(document.createTextNode(linkContext[cn]));
+ }
+ }
+ objUpdate = document.getElementById('expand');
+ if (objUpdate)
+ {
+ objUpdate.childNodes[0].nodeValue = "Collapse links";
+ }
+ expanded = true;
+}
+
+function doCollapse() {
+ objUpdate = document.getElementById('expand');
+ var spans = document.getElementsByTagName("span");
+ var span;
+
+ // go backwards through the set as removing from the front changes indices
+ // and messes up the process
+ for (i = spans.length - 1; i >= 0; i--) {
+ span = spans[i];
+ if (span.getAttribute("class") == "linkexpansion")
+ span.parentNode.removeChild(span);
+ }
+ if (objUpdate)
+ {
+ objUpdate.childNodes[0].nodeValue = "Expand links";
+ }
+ expanded = false;
+}
+
+function toggle() {
+ if (expanded) doCollapse();
+ else doExpand();
+}
+</script>
+
+...
+
+<h1>Books for download</h1>
+<p><button id="expand" onclick="toggle();">Expand Links</button></p>
+<ul>
+ <li>The History of the Web: <a href="history.docx" class="hist">Word</a>, <a href="history.pdf" class="hist">PDF</a>, <a href="history.html" class="hist">HTML</a> </li>
+
+ <li>Cooking for Nerds: <a href="history.docx" class="cook">Word</a>, <a href="history.pdf" class="cook">PDF</a>, <a href="history.html" class="cook">HTML</a> </li>
+</ul>
+
+...
+
Check that there is a link near the beginning of the page to expand links
+
+
Check that the link identified in step 1 can be identified from link text alone
+
+
Find any links on the page that cannot be identified from link text alone
+
+
Activate the control identified in step 1
+
+
Check that the purpose of the links identified in step 3 can now be identified from
+ link text alone
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1, #2, and #5 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR31.html b/wcag21/techniques/client-side-script/SCR31.html
new file mode 100644
index 0000000..2057bef
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR31.html
@@ -0,0 +1,115 @@
+
+
+
+
+ SCR31: Using script to change the background color or border of the element with focus
+
+
+
+
+
+
+
+
Using script to change the background color or border of the element with focus
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This purpose of this technique is to allow the author to use JavaScript to apply CSS,
+ in order to make the focus indicator more visible than it would ordinarily be. When
+ an element receives focus, the background color or border is changed to make it visually
+ distinct. When the element loses focus, it returns to its normal styling. This technique
+ can be used on any HTML user agent that supports Script and CSS, regardless of whether
+ it supports the :focus pseudoclass.
+
+
+
+
Examples
+
+
Example 1
+
In this example, when the link receives focus, its background turns yellow. When it
+ loses focus, the yellow is removed. Note that if the link had a background color to
+ begin with, you would use that color rather than "" in the script.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR32.html b/wcag21/techniques/client-side-script/SCR32.html
new file mode 100644
index 0000000..83cf85e
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR32.html
@@ -0,0 +1,516 @@
+
+
+
+
+ SCR32: Providing client-side validation and adding error text via the DOM
+
+
+
+
+
+
+
+
Providing client-side validation and adding error text via the DOM
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate the display of an error message
+ when client side validation of a form field has failed. Anchor elements are used to
+ display the error messages in a list and are inserted above the fields to be validated.
+ Anchor elements are used in the error messages so that focus can be placed on the
+ error message(s), drawing the user's attention to it. The href of the anchor elements contain an in-page link which references the fields where
+ error(s) have been found.
+
+
In a deployed application, if Javascript is turned off, client side validation will
+ not occur. Therefore, this technique would only be sufficient in situations where
+ scripting is relied upon for conformance or when server side validation techniques
+ are also used to catch any errors and return the page with information about the fields
+ with errors.
+
+
+
+
Examples
+
+
Example 1
+
This example validates required fields as well as fields where a specific format is
+ required. When an error is identified, the script inserts a list of error messages
+ into the DOM and moves focus to them.
+
+
+
+ HTML and Javascript code
+
+
+
Here is the HTML for the example form:
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
+<html>
+ <head>
+ <title>Form Validation</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+ <link href="css/validate.css" rel="stylesheet" type="text/css"/>
+ <script type="text/javascript" src="scripts/validate.js"/>
+ </head>
+ <body>
+
+ <h1>Form Validation</h1>
+
+ <p>The following form is validated before being submitted if scripting is available,
+ otherwise the form is validated on the server. All fields are required, except those
+ marked optional. If errors are found in the submission, the form is cancelled and
+ a list of errors is displayed at the top of the form.</p>
+
+ <p> Please enter your details below. </p>
+
+ <h2>Validating Form</h2>
+
+ <form id="personalform" method="post" action="index.php">
+ <div class="validationerrors"/>
+ <fieldset>
+ <legend>Personal Details</legend>
+ <p>
+ <label for="forename">Please enter your forename</label>
+ <input type="text" size="20" name="forename" id="forename" class="string"
+ value=""/>
+ </p>
+ <p>
+ <label for="age">Please enter your age</label>
+ <input type="text" size="20" name="age" id="age" class="number" value=""/>
+ </p>
+ <p>
+ <label for="email">Please enter your email address</label>
+ <input type="text" size="20" name="email" id="email" class="email" value=""/>
+ </p>
+ </fieldset>
+ <p>
+ <input type="submit" name="signup" value="Sign up"/>
+ </p>
+ </form>
+ <h2>Second Form</h2>
+ <form id="secondform" method="post" action="index.php#focuspoint">
+ <div class="validationerrors"/>
+ <fieldset>
+ <legend>Second Form Details</legend>
+ <p>
+ <label for="suggestion">Enter a suggestion</label>
+ <input type="text" size="20" name="suggestion" id="suggestion"
+ class="string" value=""/>
+ </p>
+ <p>
+ <label for="optemail">Please enter your email address (optional)</label>
+ <input type="text" size="20" name="optemail" id="optemail"
+ class="optional email" value=""/>
+ </p>
+ <p>
+ <label for="rating">Please rate this suggestion</label>
+ <input type="text" size="20" name="rating" id="rating"
+ class="number" value=""/>
+ </p>
+ <p>
+ <label for="jibberish">Enter some jibberish (optional)</label>
+ <input type="text" size="20" name="jibberish" id="jibberish" value=""/>
+ </p>
+
+ </fieldset>
+ <p>
+ <input type="submit" name="submit" value="Add Suggestion"/>
+ </p>
+ </form>
+ </body>
+</html>
Here is the Javascript which performs the validation and inserts the error messages:
+
+
+window.onload = initialise;
+
+function initialise()
+{
+ var objForms = document.getElementsByTagName('form');
+ var iCounter;
+
+ // Attach an event handler for each form
+ for (iCounter=0; iCounter<objForms.length; iCounter++)
+ {
+ objForms[iCounter].onsubmit = function(){return validateForm(this);};
+ }
+}
+
+
+// Event handler for the form
+function validateForm(objForm)
+{
+ var arClass = [];
+ var iErrors = 0;
+ var objField = objForm.getElementsByTagName('input');
+ var objLabel = objForm.getElementsByTagName('label');
+ var objList = document.createElement('ol');
+ var objError, objExisting, objNew, objTitle, objParagraph, objAnchor, objPosition;
+ var strLinkID, iFieldCounter, iClassCounter, iCounter;
+
+ // Get the id or name of the form, to make a unique
+ // fragment identifier
+ if (objForm.id)
+ {
+ strLinkID = objForm.id + 'ErrorID';
+ }
+ else
+ {
+ strLinkID = objForm.name + 'ErrorID';
+ }
+
+ // Iterate through input form controls, looking for validation classes
+ for (iFieldCounter=0; iFieldCounter<objField.length; iFieldCounter++)
+ {
+ // Get the class for the field, and look for the appropriate class
+ arClass = objField[iFieldCounter].className.split(' ');
+ for (iClassCounter=0; iClassCounter<arClass.length; iClassCounter++)
+ {
+ switch (arClass[iClassCounter])
+ {
+ case 'string':
+ if (!isString(objField[iFieldCounter].value, arClass))
+ {
+ if (iErrors === 0)
+ {
+ logError(objField[iFieldCounter], objLabel, objList, strLinkID);
+ }
+ else
+ {
+ logError(objField[iFieldCounter], objLabel, objList, '');
+ }
+ iErrors++;
+ }
+ break;
+ case 'number':
+ if (!isNumber(objField[iFieldCounter].value, arClass))
+ {
+ if (iErrors === 0)
+ {
+ logError(objField[iFieldCounter], objLabel, objList, strLinkID);
+ }
+ else
+ {
+ logError(objField[iFieldCounter], objLabel, objList, '');
+ }
+ iErrors++;
+ }
+ break;
+
+ case 'email' :
+ if (!isEmail(objField[iFieldCounter].value, arClass))
+ {
+ if (iErrors === 0)
+ {
+ logError(objField[iFieldCounter], objLabel, objList, strLinkID);
+ }
+ else
+ {
+ logError(objField[iFieldCounter], objLabel, objList, '');
+ }
+ iErrors++;
+ }
+ break;
+ }
+ }
+ }
+
+ if (iErrors > 0)
+ {
+ // If not valid, display error messages
+ objError = objForm.getElementsByTagName('div');
+
+ // Look for existing errors
+ for (iCounter=0; iCounter<objError.length; iCounter++)
+ {
+ if (objError[iCounter].className == 'validationerrors')
+ {
+ objExisting = objError[iCounter];
+ }
+ }
+
+ objNew = document.createElement('div');
+ objTitle = document.createElement('h2');
+ objParagraph = document.createElement('p');
+ objAnchor = document.createElement('a');
+
+ if (iErrors == 1)
+ {
+ objAnchor.appendChild(document.createTextNode('1 Error in Submission'));
+ }
+ else
+ {
+ objAnchor.appendChild(document.createTextNode(iErrors + ' Errors in Submission'));
+ }
+ objAnchor.href = '#' + strLinkID;
+ objAnchor.className = 'submissionerror';
+
+ objTitle.appendChild(objAnchor);
+ objParagraph.appendChild(document.createTextNode('Please review the following'));
+ objNew.className = 'validationerrors';
+
+ objNew.appendChild(objTitle);
+ objNew.appendChild(objParagraph);
+ objNew.appendChild(objList);
+
+ // If there were existing error, replace them with the new lot,
+ // otherwise add the new errors to the start of the form
+ if (objExisting)
+ {
+ objExisting.parentNode.replaceChild(objNew, objExisting);
+ }
+ else
+ {
+ objPosition = objForm.firstChild;
+ objForm.insertBefore(objNew, objPosition);
+ }
+
+ // Allow for latency
+ setTimeout(function() { objAnchor.focus(); }, 50);
+
+ // Don't submit the form
+ objForm.submitAllowed = false;
+ return false;
+ }
+
+ // Submit the form
+ return true;
+}
+
+// Function to add a link in a list item that points to problematic field control
+function addError(objList, strError, strID, strErrorID)
+{
+ var objListItem = document.createElement('li');
+ var objAnchor = document.createElement('a');
+
+ // Fragment identifier to the form control
+ objAnchor.href='#' + strID;
+
+ // Make this the target for the error heading
+ if (strErrorID.length > 0)
+ {
+ objAnchor.id = strErrorID;
+ }
+
+ // Use the label prompt for the error message
+ objAnchor.appendChild(document.createTextNode(strError));
+ // Add keyboard and mouse events to set focus to the form control
+ objAnchor.onclick = function(event){return focusFormField(this, event);};
+ objAnchor.onkeypress = function(event){return focusFormField(this, event);};
+ objListItem.appendChild(objAnchor);
+ objList.appendChild(objListItem);
+}
+
+function focusFormField(objAnchor, objEvent)
+{
+ var strFormField, objForm;
+
+ // Allow keyboard navigation over links
+ if (objEvent && objEvent.type == 'keypress')
+ {
+ if (objEvent.keyCode != 13 && objEvent.keyCode != 32)
+ {
+ return true;
+ }
+ }
+
+ // set focus to the form control
+ strFormField = objAnchor.href.match(/[^#]\w*$/);
+ objForm = getForm(strFormField);
+ objForm[strFormField].focus();
+ return false;
+}
+
+// Function to return the form element from a given form field name
+function getForm(strField)
+{
+ var objElement = document.getElementById(strField);
+
+ // Find the appropriate form
+ do
+ {
+ objElement = objElement.parentNode;
+ } while (!objElement.tagName.match(/form/i) && objElement.parentNode);
+
+ return objElement;
+}
+
+// Function to log the error in a list
+function logError(objField, objLabel, objList, strErrorID)
+{
+ var iCounter, strError;
+
+ // Search the label for the error prompt
+ for (iCounter=0; iCounter<objLabel.length; iCounter++)
+ {
+ if (objLabel[iCounter].htmlFor == objField.id)
+ {
+ strError = objLabel[iCounter].firstChild.nodeValue;
+ }
+ }
+
+ addError(objList, strError, objField.id, strErrorID);
+}
+
+// Validation routines - add as required
+
+function isString(strValue, arClass)
+{
+ var bValid = (typeof strValue == 'string' && strValue.replace(/^\s*|\s*$/g, '')
+ !== '' && isNaN(strValue));
+
+ return checkOptional(bValid, strValue, arClass);
+}
+
+function isEmail(strValue, arClass)
+{
+ var objRE = /^[\w-\.\']{1,}\@([\da-zA-Z\-]{1,}\.){1,}[\da-zA-Z\-]{2,}$/;
+ var bValid = objRE.test(strValue);
+
+ return checkOptional(bValid, strValue, arClass);
+}
+
+function isNumber(strValue, arClass)
+{
+ var bValid = (!isNaN(strValue) && strValue.replace(/^\s*|\s*$/g, '') !== '');
+
+ return checkOptional(bValid, strValue, arClass);
+}
+
+function checkOptional(bValid, strValue, arClass)
+{
+ var bOptional = false;
+ var iCounter;
+
+ // Check if optional
+ for (iCounter=0; iCounter<arClass.length; iCounter++)
+ {
+ if (arClass[iCounter] == 'optional')
+ {
+ bOptional = true;
+ }
+ }
+
+ if (bOptional && strValue.replace(/^\s*|\s*$/g, '') === '')
+ {
+ return true;
+ }
+
+ return bValid;
+ }
+
Working example of this technique implemented using PHP, Javascript, CSS and XHTML:
+ Form Validation Example.
+
Create error messages using anchor tags and appropriate scripting via the technique
+ above.
+
+
+
+
+
Load the page.
+
+
Enter a valid value in the field(s) associated with an error message and verify that
+ no error messages are displayed.
+
+
+
Enter an invalid value in the field(s) associated with an error message and verify
+ that the correct error message for the field is displayed.
+
+
+
Verify that the error messages receive focus.
+
+
Enter a valid value in the field(s) associated with the displayed error message and
+ verify that the error message is removed.
+
+
+
Repeat for all fields with associated error messages created via anchor tags.
+
+
+
+
+
Note
+
+
+
It is recommended that you also run the above procedure using an assistive technology.
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #2, #3, #4, and #5 are all true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR33.html b/wcag21/techniques/client-side-script/SCR33.html
new file mode 100644
index 0000000..40324c4
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR33.html
@@ -0,0 +1,269 @@
+
+
+
+
+ SCR33: Using script to scroll content, and providing a mechanism to pause it
+
+
+
+
+
+
+
+
Using script to scroll content, and providing a mechanism to pause it
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Technologies that support script-controlled scrolling of content.
The objective of this technique is to provide a way for users to stop scrolling content
+ when the scrolling is created by a script. Scrolling content can be difficult or impossible
+ to read by users with low vision or with cognitive disabilities. The movement can
+ also be distracting for some people making it difficult for them to concentrate on
+ other parts of the Web page.
+
+
+
+
Examples
+
+
Example 1
+
In this example CSS and Javascript are used to visually present some text in a scrolling
+ format. A link is included to pause the scrolling movement.
+
+
This implementation will display the full text and omit the link when Javascript or
+ CSS are unsupported or inactive.
+
+
The following code is an amended version of webSemantic's Accessible Scroller (as
+ at July 2008).
+
+
The XHTML component:
+...
+<div id="scroller">
+<p id="tag">This text will scroll and a Pause/Scroll link will be present
+when Javascript and CSS are supported and active.</p>
+</div>
+...
+
The CSS component:
+...
+body {font:1em verdana,sans-serif; color:#000; margin:0}
+
+/* position:relative and overflow:hidden are required */
+#scroller { position:relative; overflow:hidden; width:15em; border:1px solid #008080; }
+
+/* add formatting for the scrolling text */
+#tag { margin:2px 0; }
+
+/* #testP must also contain all text-sizing properties of #tag */
+#testP { visibility:hidden; position:absolute; white-space:nowrap; }
+
+/* used as a page top marker and to limit width */
+#top { width:350px; margin:auto; }
+...
+
The JavaScript component:
+var speed=50 // speed of scroller
+var step=3 // smoothness of movement
+var StartActionText= "Scroll" // Text for start link
+var StopActionText = "Pause" // Text for stop link
+
+var x, scroll, divW, sText=""
+
+function onclickIE(idAttr,handler,call){
+ if ((document.all)&&(document.getElementById)){idAttr[handler]="Javascript:"+call}
+}
+
+function addLink(id,call,txt){
+ var e=document.createElement('a')
+ e.setAttribute('href',call)
+ var linktext=document.createTextNode(txt)
+ e.appendChild(linktext)
+ document.getElementById(id).appendChild(e)
+}
+
+function getElementStyle() {
+ var elem = document.getElementById('scroller');
+ if (elem.currentStyle) {
+ return elem.currentStyle.overflow;
+ } else if (window.getComputedStyle) {
+ var compStyle = window.getComputedStyle(elem, '');
+ return compStyle.getPropertyValue("overflow");
+ }
+ return "";
+}
+
+function addControls(){
+// test for CSS support first
+// test for the overlow property value set in style element or external file
+if (getElementStyle()=="hidden") {
+ var f=document.createElement('div');
+ f.setAttribute('id','controls');
+ document.getElementById('scroller').parentNode.appendChild(f);
+ addLink('controls','Javascript:clickAction(0)',StopActionText);
+ onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction(0)');
+ document.getElementById('controls').style.display='block';
+ }
+}
+
+function stopScroller(){clearTimeout(scroll)}
+
+function setAction(callvalue,txt){
+ var c=document.getElementById('controls')
+ c.childNodes[0].setAttribute('href','Javascript:clickAction('+callvalue+')')
+ onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction
+
+('+callvalue+')')
+ c.childNodes[0].firstChild.nodeValue=txt
+}
+
+function clickAction(no){
+ switch(no) {
+ case 0:
+ stopScroller();
+ setAction(1,StartActionText);
+ break;
+ case 1:
+ startScroller();
+ setAction(0,StopActionText);
+ }
+}
+
+function startScroller(){
+ document.getElementById('tag').style.whiteSpace='nowrap'
+ var p=document.createElement('p')
+ p.id='testP'
+ p.style.fontSize='25%' //fix for mozilla. multiply by 4 before using
+ x-=step
+ if (document.getElementById('tag').className) p.className=document.getElementById
+
+('tag').className
+ p.appendChild(document.createTextNode(sText))
+ document.body.appendChild(p)
+ pw=p.offsetWidth
+ document.body.removeChild(p)
+ if (x<(pw*4)*-1){x=divW}
+ document.getElementById('tag').style.left=x+'px'
+ scroll=setTimeout('startScroller()',speed)
+}
+
+function initScroller(){
+ if (document.getElementById && document.createElement && document.body.appendChild) {
+ addControls();
+ divW=document.getElementById('scroller').offsetWidth;
+ x=divW;
+ document.getElementById('tag').style.position='relative';
+ document.getElementById('tag').style.left=divW+'px';
+ var ss=document.getElementById('tag').childNodes;
+ for (i=0;i<ss.length;i++) {sText+=ss[i].nodeValue+" "};
+ scroll=setTimeout('startScroller()',speed);
+ }
+}
+
+function addLoadEvent(func) {
+ if (!document.getElementById | !document.getElementsByTagName) return
+ var oldonload = window.onload
+ if (typeof window.onload != 'function') {
+ window.onload = func;
+ } else {
+ window.onload = function() {
+ oldonload()
+ func()
+ }
+ }
+}
+
+addLoadEvent(initScroller)
+
Check that a mechanism is provided to pause the scrolling content.
+
+
Use the pause mechanism to pause the scrolling content.
+
+
Check that the scrolling has stopped and does not restart by itself.
+
+
Check that a mechanism is provided to restart the paused content.
+
+
Use the restart mechanism provided to restart the scrolling content.
+
+
Check that the scrolling has resumed from the point where it was stopped.
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #3 and #6 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR34.html b/wcag21/techniques/client-side-script/SCR34.html
new file mode 100644
index 0000000..f3a92b5
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR34.html
@@ -0,0 +1,195 @@
+
+
+
+
+ SCR34: Calculating size and position in a way that scales with text size
+
+
+
+
+
+
+
+
Calculating size and position in a way that scales with text size
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to calculate the size and position of elements
+ in a way that will scale appropriately as the text size is scaled.
+
+
There are four properties in JavaScript that help determine the size and position
+ of elements:
+
+
+
+
+ offsetHeight (the height of the element in pixels)
+
+
+
+ offsetWidth (the width of the element in pixels)
+
+
+
+ offsetLeft (the distance of the element from the left of its parent (offsetParent)
+ in pixels)
+
+
+
+ offsetTop (the distance of the element from the top of its parent (offsetParent) in
+ pixels)
+
+
+
+
Calculating the height and width using offsetHeight and offsetWidth is straightforward,
+ but when calculating an object's left and top position as absolute values, we need
+ to consider the parent element. The calculatePosition function below iterates through
+ all of an element's parent nodes to give a final value. The function takes two parameters;
+ objElement (the name of the element in question), and the offset property (offsetLeft
+ or offsetTop):
+
+
+
+
Examples
+
+
Example 1
+
The Javascript function:
+function calculatePosition(objElement, strOffset)
+{
+ var iOffset = 0;
+
+ if (objElement.offsetParent)
+ {
+ do
+ {
+ iOffset += objElement[strOffset];
+ objElement = objElement.offsetParent;
+ } while (objElement);
+ }
+
+ return iOffset;
+}
+
+
The following example illustrates using the function above by aligning an object beneath
+ a reference object, the same distance from the left:
+
+// Get a reference object
+var objReference = document.getElementById('refobject');
+// Get the object to be aligned
+var objAlign = document.getElementById('lineup');
+
+objAlign.style.position = 'absolute';
+objAlign.style.left = calculatePosition(objReference, 'offsetLeft') + 'px';
+objAlign.style.top = calculatePosition(objReference, 'offsetTop') + objReference.offsetHeight + 'px';
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Open a page that is designed to adjust container sizes as text size changes.
+
+
Increase the text size up to 200% using the browser's text size adjustment (not the
+ zoom feature).
+
+
+
Examine the text to ensure the text container size is adjusted to accommodate the
+ size of the text.
+
+
+
Ensure that no text is "clipped" or has disappeared as a result of the increase in
+ text size.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #3 and #4 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR35.html b/wcag21/techniques/client-side-script/SCR35.html
new file mode 100644
index 0000000..255d96c
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR35.html
@@ -0,0 +1,291 @@
+
+
+
+
+ SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons
+
+
+
+
+
+
+
+
Making actions keyboard accessible by using the onclick event of anchors and buttons
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how to invoke a scripting function
+ in a way that is keyboard accessible by attaching it to a keyboard-accessible control.
+ In order to ensure that scripted actions can be invoked from the keyboard, they are
+ associated with "natively actionable" HTML elements (links and buttons). The onclick
+ event of these elements is device independent. While "onclick" sounds like it is tied
+ to the mouse, the onclick event is actually mapped to the default action of a link
+ or button. The default action occurs when the user clicks the element with a mouse,
+ but it also occurs when the user focuses the element and hits enter or space, and
+ when the element is triggered via the accessibility API.
+
+
This technique relies on client-side scripting. However, it is beneficial to provide
+ a backup implementation or explanation for environments in which scripting is not
+ available. When using anchor elements to invoke a JavaScript action, a backup implementation
+ or explanation is provided via the href attribute. When using buttons, it is provided via a form post.
+
+
+
+
Examples
+
+
Example 1
+
Link that runs a script and has no fallback for non-scripted browsers. This approach
+ should only be used when script is relied upon as an Accessibility Supported Technology.
+
+
Even though we do not want to navigate from this link, we must use the href attribute
+ on the a element in order to make this a true link and get the proper eventing. In this case,
+ we're using "#" as the link target, but you could use anything. This link will never
+ be navigated.
+
+
The "return false;" at the end of the doStuff() event handling function tells the
+ browser not to navigate to the URI. Without it, the page would refresh after the script
+ ran.
+
Link that runs script, but navigates to another page when script is not available.
+ This approach can be used to create sites that don't rely on script, if and only if
+ the navigation target provides the same functionality as the script. This example
+ is identical to the example 1, except that its href is now set to a real page, dostuff.htm.
+ Dostuff.htm must provide the same functionality as the script.The "return false;"
+ at the end of the doStuff() event handling function tells the browser not to navigate
+ to the URI. Without it, the browser would navigate to dostuff.htm after the script
+ ran.
+
Button that runs a script and falls back to a form post for users without script.
+ This approach can be used by sites that do not rely on script, if and only if the
+ form post provides the same functionality as the script. The onsubmit="return false;"
+ prevents the form from submitting.
+
Button that runs a script, implemented with input type="image". Note that an alt attribute
+ must be added to the input to provide a text equivalent for the image. This approach should only be used when
+ script is relied upon.
+
Button that runs a script, implemented with input type="submit", input type="reset"
+ or input type="button". This approach should only be used when script is relied upon.
+
+
Button that runs a script, implemented with button…/button. This is valuable when you want more control over the look of your button. In this
+ particular example, the button contains both an icon and some text. This approach
+ should only be used when script is relied upon.
+
For all script actions associated with a, button, or input elements:
+
+
+
+
+
+
+
In a user agent that supports Scripting
+
+
+
+
Click on the control with the mouse.
+
+
Check that the scripting action executes properly.
+
+
If the control is an anchor element, check that the URI in the href attribute of the anchor element is not invoked.
+
+
+
Check that it is possible to navigate to and give focus to the control via the keyboard.
+
+
Set keyboard focus to the control.
+
+
Check that pressing ENTER invokes the scripting action.
+
+
If the control is an anchor element, check that the URI in the href attribute of the anchor element is not invoked.
+
+
+
+
+
+
+
+
+
In a user agent that does not support Scripting
+
+
+
+
Click on the control with the mouse.
+
+
If the control is an anchor element, check that the URI in the href attribute of the anchor element is invoked.
+
+
+
Check that it is possible to navigate to and give focus to the control via the keyboard.
+
+
Set keyboard focus to the control.
+
+
If the control is an anchor element, check that pressing ENTER invokes the URI of
+ the anchor element's href attribute.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
All of the above checks are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR36.html b/wcag21/techniques/client-side-script/SCR36.html
new file mode 100644
index 0000000..3507c4c
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR36.html
@@ -0,0 +1,176 @@
+
+
+
+
+ SCR36: Providing a mechanism to allow users to display moving, scrolling, or auto-updating
+ text in a static window or area
+
+
+
+
+
+
+
+
+
Providing a mechanism to allow users to display moving, scrolling, or auto-updating
+ text in a static window or area
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Any technology that moves, blinks, or updates text and can create a static block of
+ text.
+
Some Web pages display scrolling text because there is limited space available. Scrolling
+ the text in a small text window makes the content available for users who can read
+ quickly enough, but causes problems for users who read more slowly or use assistive
+ technology. This technique provides a mechanism to stop the movement and make the
+ entire block of text available statically. The text may be made available in a separate
+ window or in a (larger) section of the page. Users can then read the text at their
+ own speed.
+
+
This technique does not apply when the text that is moving can not be displayed all
+ at once on the screen (e.g., a long chat conversation).
+
A large block of text is scrolled through a small marquee area of the page. A button
+ lets the user stop the scrolling and display the entire block of text.
+
+
+
Note
+
+
+
This code example requires that both CSS and JavaScript be turned on and available.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR37.html b/wcag21/techniques/client-side-script/SCR37.html
new file mode 100644
index 0000000..df12a4a
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR37.html
@@ -0,0 +1,257 @@
+
+
+
+
+ SCR37: Creating Custom Dialogs in a Device Independent Way
+
+
+
+
+
+
+
+
Creating Custom Dialogs in a Device Independent Way
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Site designers often want to create dialogs that do not use the pop-up windows supplied
+ by the browser. This is typically accomplished by enclosing the dialog contents in
+ a div and placing the div above the page content using z-order and absolute positioning in CSS.
+
+
To be accessible, these dialogs must follow a few simple rules.
+
+
+
Trigger the script that launches the dialog from the onclick event of a link or button.
+
+
Place the dialog div into the Document Object Model (DOM) immediately after the element that triggered
+ it. The triggering element will maintain focus, and inserting the dialog content after
+ that element will make the content inside the dialog next in the screen-reader reading
+ order and next in the tab order. The dialog can still be absolutely positioned to
+ be elsewhere on the page visually. This can be done either by creating the dialog
+ in the HTML and hiding it with CSS, as in the example below, or by inserting it immediately
+ after the triggering element with script.
+
+
+
Ensure that the HTML inside the dialog div meets the same accessibility standard as
+ other content.
+
+
+
+
It is also nice, but not always necessary, to make the launching link toggle the dialog
+ open and closed, and to close the dialog when the keyboard focus leaves it.
+
+
+
+
Examples
+
+
Example 1: An options button that opens a dialog
+
The HTML for this example includes a triggering Element, in this case a button, and
+ a div that acts as the frame for the dialog.
+
+
The triggering element is a button and the script is triggered from the onclick event.
+ This sends the appropriate events to the operating system so that assistive technology
+ is aware of the change in the DOM.
+
+
In this example, the Submit and Reset buttons inside the dialog simply hide the div.
+
Find all areas of the page that trigger dialogs that are not pop-up windows.
+
+
Check that the dialogs can be opened by tabbing to the area and hitting enter.
+
+
Check that, once opened, the dialog is next in the tab order.
+
+
Check that the dialogs are triggered from the click event of a button or a link.
+
+
Using a tool that allows you to inspect the DOM generated by script, check that the
+ dialog is next in the DOM.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #2, #3, #4 and #5 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR38.html b/wcag21/techniques/client-side-script/SCR38.html
new file mode 100644
index 0000000..5a54d33
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR38.html
@@ -0,0 +1,284 @@
+
+
+
+
+ SCR38: Creating a conforming alternate version for a web page designed with progressive enhancement
+
+
+
+
+
+
+
+
Creating a conforming alternate version for a web page designed with progressive enhancement
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
HTML with scripting.
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
This objective of this technique is to offer a conforming alternate version for a
+ web page designed with progressive enhancement. The technique demonstrates how to
+ use a scripting technique to accomplish this by:
+
+
+
+
Storing the initial pre-enhanced version of the web page so that it can act as a "conforming
+ alternate version" for any later enhanced versions of the content; and
+
+
+
Inserting a mechanism into all enhanced versions of the web page which allows a user
+ to revert the content back to the stored pre-enhanced Alternate Version.
+
+
+
+
Web pages designed with progressive enhancement detect features in the web-enabled
+ accessing device (size, capability and software) to allow those supported web technologies
+ to be applied in layers on top of an HTML foundation. The basic content and functionality
+ of such a web page are available through the HTML foundation to anyone using a more
+ simple web-enabled accessing device, whilst enhanced versions of the page are created
+ to suit the different features in more advanced accessing devices.
+
+
The current guidance for web pages delivered in alternate versions reads: "Note 4:
+ Alternate versions may be provided to accommodate different technology environments
+ or user groups. Each version should be as conformant as possible. One version would
+ need to be fully conformant in order to meet conformance requirement 1." With regard
+ to web pages designed with progressive enhancement this leaves the problem of which
+ version to select as the one fully conformant version - all whilst trying to ensure
+ that no set of users is disadvantaged by that choice.
+
+
One solution to this challenge is to select the pre-enhanced version of the web page
+ (e.g. the DOM state created solely from the HTML in the source code in the absence
+ of support for scripts, styles or non-HTML plugins) as the "fully conformant version",
+ due to its broad reach, with regard to support, across all the possible web-enabled
+ devices accessing the content.
+
+
+
Note
+
+
This technique removes all scripts, styles, and plugins, but it is important to state
+ that this is not required for conformance with WCAG 2.0. An author could use a similar
+ technique, but retain a reduced set of styles and scripts in the “pre-enhanced” version.
+
+
+
+
While this technique offers a way to base conformance claims on a single version,
+ authors should continue to work to ensure that each enhanced version of the web page
+ is as conformant as possible.
+
+
+
+
Examples
+
+
Example 1: Using JavaScript
+
The example uses JavaScript in the "accToggle.js" file to store the initial pre-enhanced
+ version of the web page, created solely from the HTML in the source code, so that
+ it can act as a "conforming alternate version" for any later enhanced versions of
+ the web page; and inserts a toggle link into all enhanced versions of the web page
+ which allows a user to revert the web page back to the stored pre-enhanced "Conforming
+ Alternate Version". Note: The "sayhello.js" file is simply there as an example payload
+ external file, and is to be replaced by any other external scripts which are desired.
+
+
The script in the acctoggle.js file stores the pre-enhanced version - assigning the
+ version the url postfix #accessible. Clicking the "WCAG 2.0 conforming alternate version"
+ link (inserted as the first child of the body element in any enhanced versions) changes the url to include the postfix "#accessible"
+ which then resets the html located in the body element and the head element to pre-enhanced code. The pre-enhanced state can be reached from the link,
+ or directly from a url typed into the browser. In addition, a link is inserted into
+ the pre-enhanced "Conforming Alternate Version" which allows the user to re-enhance
+ the web page (something which can also be done using the web browser's back button).
+
+
acctoggle.js source code:
window.onload = function(event) {
+
+ // store pre-enhanced element content
+ var initialHead = document.head.innerHTML;
+ var initialBody = document.body.innerHTML;
+ var initialURL = location.href;
+
+ var runOnce = function() {
+ // payload you want to run per page call - e.g. Google Analytics code
+ }
+
+ var setup = function() {
+ // create conforming alternate version link
+
+ var toggleEnhanced = document.querySelector("#toggle_enhanced");
+ if (toggleEnhanced) {
+ toggleEnhanced.outerHTML = "";
+ }
+
+ var nel = document.createElement("a");
+ nel.id = "acctoggle";
+ nel.setAttribute("href", "#accessible");
+ nel.innerHTML = "WCAG 2.0 conforming alternate version";
+ document.body.insertBefore(nel, document.body.firstChild);
+
+ // payload
+ var s = document.createElement("SCRIPT");
+ s.setAttribute("src", "sayhello.js");
+ document.querySelector("HEAD").appendChild(s);
+ }
+
+ setup();
+ runOnce();
+
+ window.onpopstate = function(event) {
+ if (location.href.indexOf("#accessible") != -1) {
+ // revert element contents to pre-enhanced version
+ document.head.innerHTML = initialHead;
+ document.body.innerHTML = initialBody;
+
+ // create enhanced version link
+ var el = document.createElement("a");
+ el.id = "toggle_enhanced";
+ el.setAttribute("href", "");
+ el.innerHTML = "Enhanced version";
+ var back = function(e) {
+ e.preventDefault();
+ window.history.back();
+ }
+ el.addEventListener("click", back, false);
+ document.body.insertBefore(el, document.body.firstChild);
+ }
+ if (location.href == initialURL) {
+ setup();
+ }
+ };
+}
+
var change = document.querySelector("#change");
+ change.innerText = "Hello";
+
+
+
Example 2: Using EnhanceJS - A Javascript framework designed to improve the application
+ of Progressive Enhancement
+
+
EnhanceJS is an open source JavaScript framework "designed to improve the application of Progressive
+ Enhancement by first testing browser capabilities for key Javascript and CSS support
+ before applying advanced styles and scripts to the page". In addition, the default
+ EnhanceJS script automatically creates a toggle link in any post-enhanced versions
+ of the page which allows a user to return the web page to its pre-enhanced state (in
+ EnhanceJS with default settings this is called the "low bandwidth version"). The setting
+ have been changed in EnhanceJS to indicate that the pre-enhanced state is to be considered
+ the "WCAG 2.0 conforming alternate version", rather than the "low bandwidth version".
+
Check enhanced versions of the web page contain a link to the "Conforming Alternate
+ Version".
+
+
+
Check that the alternate version is a conforming alternate version of the original page and that it conforms to WCAG 2.0 at the claimed conformance
+ level.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/client-side-script/SCR39.html b/wcag21/techniques/client-side-script/SCR39.html
new file mode 100644
index 0000000..37fda5e
--- /dev/null
+++ b/wcag21/techniques/client-side-script/SCR39.html
@@ -0,0 +1,148 @@
+
+
+
+
+ SCR39: Making content on focus or hover hoverable, dismissible, and persistent
+
+
+
+
+
+
+
+
Making content on focus or hover hoverable, dismissible, and persistent
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
The Technique is applicable to any technology that supports the display of additional
+ content on pointer hover.
+
+
Additional content that is displayed when a user moves the pointer over a trigger
+ or moves the keyboard focus to the trigger (for example, a pop-up) must remain visible
+ to allow users time to read and interact with the content and must allow the user
+ to move the pointer over the additional content.
+
+
Low vision users who magnify their screens often see only a small part of the screen
+ at a time (their viewport).
+ This means that the additional content may not be fully visible in the current viewport
+ and users may need to move
+ their mouse over the additional content to read it. Web authors should therefore ensue
+ that additional content stays visible
+ when the pointer moves away from the trigger to the (mostly adjacent) additional content.
+ additional content should also be
+ dismissible without moving the focus, so that users can read content covered by the
+ additional content.
+
+
+
+
Examples
+
+
Example 1: Example 1: Content preview for links
+
When hovering over or focusing on a link, a content preview for the link appears just
+ above or below that link.
+ Users can move the pointer over the additional content (pop-up) so that they can
+ fully read the additional content. Pressing the Esc
+ key dismisses (closes) the additional content.
+
+
+
+
HTML of example 1
+
<p>This is the <a class="a-and-tooltip" id="parent" href="index.html">trigger
+<span id="popup" role="tooltip">And this additional text
+gives additional context on the trigger term</span></a>.
+Text and popup are <strong>in one link (a)</strong> element.</p>
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to specify text font size proportionally so that
+ user agents can scale content effectively. If a font-size is specified for the body element, all other elements inherit that value, unless overridden by a more specific
+ selector.
+
+
+
+
Examples
+
+
Example 1: Percent font sizes in CSS
+
This example defines the font size for the strong element so that its text will always be larger than the surrounding text, in whatever
+ context it is used. Assuming that headings and paragraphs use different font sizes,
+ the emphasized words in this example will each be larger than their surrounding text.
+
+strong {font-size: 120%}
+
+...
+
+<h1>Letting the <strong>user</strong> control text size</h1>
+<p>Since only the user can know what size text works for him,
+it is <strong>very</strong> important to let him configure the text size.
+…
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that the value of the CSS property that defines the font size is a percentage.
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C13.html b/wcag21/techniques/css/C13.html
new file mode 100644
index 0000000..bf8482f
--- /dev/null
+++ b/wcag21/techniques/css/C13.html
@@ -0,0 +1,135 @@
+
+
+
+
+ C13: Using named font sizes
+
+
+
+
+
+
+
+
Using named font sizes
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to specify a named font size that expresses the
+ relative font size desired. These values provide hints so that the user agent can
+ choose a font-size relative to the inherited font-size.
+
+
+
+
Examples
+
+
Example 1: Named font sizes in CSS
+
This example selects a larger font size for strong elements so that their text will always be larger than the surrounding text, in whatever
+ context they are used. Assuming that headings and paragraphs use different font sizes,
+ the emphasized words in this example will each be larger than their surrounding text.
+
+strong {font-size: larger}
+
+...
+
+<h1>Letting the <strong>user</strong> control text size</h1>
+<p>Since only the user can know what size text works for him,
+it is <strong>very</strong> important to let him configure the text size.
+…
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that the value of the CSS property that defines the font size is one of xx-small,
+ xx-small, x-small, small, medium, large, x-large, xx-large, xsmaller, or larger.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C14.html b/wcag21/techniques/css/C14.html
new file mode 100644
index 0000000..657cef4
--- /dev/null
+++ b/wcag21/techniques/css/C14.html
@@ -0,0 +1,137 @@
+
+
+
+
+ C14: Using em units for font sizes
+
+
+
+
+
+
+
+
Using em units for font sizes
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to specify text font size in em units so that user
+ agents can scale content effectively. Since the em is a property of the font, it scales
+ as the font changes size. If a font-size is specified for the body element, all other elements inherit that value, unless overridden by a more specific
+ selector.
+
+
+
+
Examples
+
+
Example 1: Em font sizes in CSS
+
This example defines the font size for strong element so that its text will always
+ be larger than the surrounding text, in whatever context it is used. Assuming that
+ headings and paragraphs use different font sizes, the strong words in this example
+ will each be larger than their surrounding text.
+
+strong {font-size: 1.6em}
+
+...
+
+<h1>Letting the <strong>user</strong> control text size</h1>
+<p>Since only the user can know what size text works for him,
+it is <strong>very</strong> important to let him configure the text size. </p>
+…
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that the value of the CSS property that defines the font size is expressed in
+ em units.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C15.html b/wcag21/techniques/css/C15.html
new file mode 100644
index 0000000..e312920
--- /dev/null
+++ b/wcag21/techniques/css/C15.html
@@ -0,0 +1,184 @@
+
+
+
+
+ C15: Using CSS to change the presentation of a user interface component when it receives
+ focus
+
+
+
+
+
+
+
+
+
Using CSS to change the presentation of a user interface component when it receives
+ focus
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how visual appearance may be enhanced
+ via style sheets to provide visual feedback when an interactive element has focus
+ or when a user hovers over it using a pointing device. Highlighting the element that
+ has focus or is hovered over can provide information such as the fact that the element
+ is interactive or the scope of the interactive element.
+
+
Providing visual feedback may be possible through more than one mode. Usually, it
+ is attained through using a mouse to hover over the element or a keyboard to tab to
+ the element.
+
+
+
+
Examples
+
+
Example 1: Link elements
+
In this example, mouse and keyboard focus indicators have been applied to the link
+ elements. CSS has been used to apply a background color when the link elements receive
+ focus.
+
Example 2: Highlighting elements that receive focus
+
In this example, the :focus pseudo-class is used to change the style applied to input
+ fields when they receive focus by changing the background color.
+
Check that the background or border changes color.
+
+
Move the mouse away from the object before attempting keyboard focus.
+
+
Using a keyboard, tab to the element.
+
+
Check that the background or border changes color.
+
+
Check that the background or border changes in color are removed when the element
+ loses focus.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #2, #5 and #6 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C17.html b/wcag21/techniques/css/C17.html
new file mode 100644
index 0000000..071bd6e
--- /dev/null
+++ b/wcag21/techniques/css/C17.html
@@ -0,0 +1,116 @@
+
+
+
+
+ C17: Scaling form elements which contain text
+
+
+
+
+
+
+
+
Scaling form elements which contain text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to ensure text-based form controls resize when
+ text size is changed in the user agent. This will allow users to enter text and read
+ what they have entered in input boxes because the text is displayed at the size required
+ by the user.
+
+
Text-based form controls include input boxes (text and textarea) as well as buttons.
+
+
+
Examples
+
+
Example 1: A Contact Form
+
A Contact Us form has some introductory information and then form controls for users
+ to enter their first name, last name, telephone number and email address. All of the
+ text and form controls have been implemented in a scalable way. This includes specifying
+ a font size for the form controls themselves because the font size is not inherited
+ in Internet Explorer.
+
+
The XHTML component:
<h1>Contact Us</h1>
+<p>Please provide us with your details and we will contact you as soon as we can. Note that all of the form fields are required.</p>
+<label for="fname">First Name</label><input type="text" name="fname" id="fname" /><br />
+<label for="lname">Last Name</label><input type="text" name="lname" id="lname" /><br />
+<label for="phone">Telephone</label><input type="text" name="phone" id="phone" /><br />
+<label for="email">Email</label><input type="text" name="email" id="email" /><br />
+<input type="submit" name="Submit" value="Submit" id="Submit" />
Enter some text into text-based form controls that receive user entered text.
+
+
Increase the text size of the content by 200%.
+
+
Check that the text in text-based form controls has increased by 200%.
+
+
+
+
+
+
Expected Results
+
+
+
+
#3 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C18.html b/wcag21/techniques/css/C18.html
new file mode 100644
index 0000000..c240a72
--- /dev/null
+++ b/wcag21/techniques/css/C18.html
@@ -0,0 +1,130 @@
+
+
+
+
+ C18: Using CSS margin and padding rules instead of spacer images for layout design
+
+
+
+
+
+
+
+
Using CSS margin and padding rules instead of spacer images for layout design
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Web designers sometimes use spacer images (usually 1x1 pixel, transparent GIFs) for
+ better control over layout, for example in tables or to indent a paragraph. However,
+ Cascading Style Sheets (CSS) allow sufficient control over layout to replace spacer
+ images. The CSS properties for margins and padding can be used on their own or in
+ combination to control the layout. The margin properties ('margin-top', 'margin-right',
+ 'margin-bottom', 'margin-left', and the shorthand 'margin') can be used on any element
+ that is displayed as a block; they add space at the outside of an element. The padding
+ properties ('padding-top', 'padding-right', 'padding-bottom', 'padding-left', and
+ the shorthand 'padding') can be used on any element; they add space inside the element.
+
+
+
+
Examples
+
+
Example 1
+
The following example consists of two parts: the CSS code, which specifies a margin
+ on all sides of the table, and padding for the table cells; and the HTML code for
+ the table, which does not contain spacer images and is not nested inside another table.
+
+
+ table { margin: .5em; border-collapse: collapse; }
+ td, th { padding: .4em; border: 1px solid #000; }
+
+ ...
+
+ <table summary="Titles, authors and publication dates of books in Web development category">
+ <caption>Books in the category 'Web development'</caption>
+ <thead>
+ <tr>
+ <th>Title</th>
+ <th>Author</th>
+ <th>Date</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>How to Think Straight About Web Standards</td>
+ <td>Andrew Stanovich</td>
+ <td>1 April 2007</td>
+ </tr>
+ </tbody>
+ </table>
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C19.html b/wcag21/techniques/css/C19.html
new file mode 100644
index 0000000..783d5fa
--- /dev/null
+++ b/wcag21/techniques/css/C19.html
@@ -0,0 +1,86 @@
+
+
+
+
+ C19: Specifying alignment either to the left OR right in CSS
+
+
+
+
+
+
+
+
Specifying alignment either to the left OR right in CSS
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique describes how to align blocks of text either left or right by setting
+ the CSS text-align property.
+
+
+
+
Examples
+
+
Example 1
+
In the following example, text is aligned left. In the style sheet, define the class:
p.left {text-align: left}
In the content call the up the class.
<p class="left"> Lorem ipsum dolor sit …</p>
+
+
Example 2
+
In the following example, text is aligned right.
p.right {text-align: right}
In the content call the up the class.
<p class="right"> Lorem ipsum dolor sit …</p>
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check that the text is aligned either left or right.
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C20.html b/wcag21/techniques/css/C20.html
new file mode 100644
index 0000000..47b10d5
--- /dev/null
+++ b/wcag21/techniques/css/C20.html
@@ -0,0 +1,169 @@
+
+
+
+
+ C20: Using relative measurements to set column widths so that lines can average 80 characters
+ or less when the browser is resized
+
+
+
+
+
+
+
+
+
Using relative measurements to set column widths so that lines can average 80 characters
+ or less when the browser is resized
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The purpose of this technique is to ensure that CSS is used in a way that allows users
+ to view content in such a way that line length can average 80 characters or less.
+ This makes it possible for users with certain reading or vision disabilities that
+ have trouble keeping their place when reading long lines of text to view and interact
+ with the content more efficiently. This technique also allows for column width to
+ grow wider as font sizes increase, which will reduce the possibility of clipping as
+ the text size increases..
+
+
+ Note that this technique does not require authors to use CSS to limit the width of
+ lines of text to less than 80 characters in the default view. Rather, the recommendation
+ to use relative measurements in CSS layouts helps to ensure that authors do not set
+ column widths in such a way that makes it impossible for users to view content with
+ line lengths of 80 characters or less.
+
+
+
+
Examples
+
+
Example 1
+
In this example the div width is set in ems in the stylesheet.
+
+
+
Note
+
+
+
The CSS property max-width is not supported in versions of Internet Explorer 6 and
+ below.
+
+
+
+
#main_content {max-width: 70em}
And the text block would be placed inside the div in the content
+
+<div id="main_content">
+ <p>Lorem ipsum dolor sit amet, consectetur adipisicing ...</p>
+</div>
+
+
Example 2
+
In this example the div width is set in percent in the stylesheet
+
#main_content {width: 90%}
And the text block would be placed inside the div in the content
+
+<div id="main_content">
+ <p>Lorem ipsum dolor sit amet, consectetur adipisicing ...</p>
+</div>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Test to see that the columns are defined in relative units.
+
+
Check to see that line length can be set to 80 characters or less by resizing the
+ browser window.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1 and #2 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C21.html b/wcag21/techniques/css/C21.html
new file mode 100644
index 0000000..f229755
--- /dev/null
+++ b/wcag21/techniques/css/C21.html
@@ -0,0 +1,101 @@
+
+
+
+
+ C21: Specifying line spacing in CSS
+
+
+
+
+
+
+
+
Specifying line spacing in CSS
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Many people with cognitive disabilities have trouble tracking lines of text when a
+ block of text is single spaced. Providing spacing between 1.5 to 2 allows them to
+ start a new line more easily once they have finished the previous one.
+
+
+
+
Examples
+
+
Example 1
+
Setting the element to 1.5 line height. In the style sheet set the characteristics
+ of the element.
+
p { line-height: 150%; }
In the content the element will now be 1.5 line height, throughout the document.
<p> Lorem ipsum dolor sit … </p>
+
+
Example 2
+
Setting a class to 1.5 line height (space-and-a-half line spacing). In the stylesheet,
+ define the class.
+
p.tall {line-height:150%}
In the content, call up the class = "left".
<p class="tall"> Lorem ipsum dolor sit … </p>
+
+
Example 3
+
Setting a class to double-spaced line height. In the stylesheet, define the class.
p.tall {line-height:200%}
In the content, call up the class = "right".
<p class="tall"> Lorem ipsum dolor sit … </p>
+
+
+
Tests
+
+
Procedure
+
+
+
+
Open content in a browser.
+
+
Check that the spacing between lines in blocks of text is between 1.5 and 2.
+
+
+
+
+
+
Expected Results
+
+
+
+
Test Procedure #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C22.html b/wcag21/techniques/css/C22.html
new file mode 100644
index 0000000..9ec487d
--- /dev/null
+++ b/wcag21/techniques/css/C22.html
@@ -0,0 +1,381 @@
+
+
+
+
+ C22: Using CSS to control visual presentation of text
+
+
+
+
+
+
+
+
Using CSS to control visual presentation of text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how CSS can be used to control the
+ visual presentation of text. This will allow users to modify, via the user agent,
+ the visual characteristics of the text to meet their requirement. The text characteristics
+ include aspects such as size, color, font family and relative placement.
+
+
CSS benefits accessibility primarily by separating document structure from presentation.
+ Style sheets were designed to allow precise control - outside of markup - of character
+ spacing, text alignment, object position on the page, audio and speech output, font
+ characteristics, etc. By separating style from markup, authors can simplify and clean
+ up the markup in their content, making it more accessible at the same time.
+
+
Text within images has several accessibility problems, including the inability to:
+
+
+
be scaled according to settings in the browser
+
+
be displayed in colors specified by settings in the browser or rules in user-defined
+ style sheets
+
+
+
honor operating system settings, such as high contrast
+
+
+
It is better to use real text for the text portion of these elements, and a combination
+ of semantic markup and style sheets to create the appropriate visual presentation.
+ For this to work effectively, choose fonts that are likely to be available on the
+ user's system and define fallback fonts for users who may not have the first font
+ that is specified. Newer machines and user agents often smooth or anti-alias all text,
+ so it is likely that your headings and buttons will look nice on these systems without
+ resorting to images of text.
+
+
The following CSS properties are useful to style text and avoid the need for text
+ in images:
+
+
+
+
The font-family property is used to display the code aspect in a monospace font family.
+
+
The text-align property is used to display the text to the right of the viewport.
+
+
The font-size property is used to display the text in a larger size.
+
+
The font-style property is used to display text in italics.
+
+
The font-weight property is used to set how thick or thin characters in text should
+ be displayed.
+
+
+
The color property is used to display the color of text or text containers.
+
+
The line-height property is used to display the line height for a block of text.
+
+
The text-transform property is used to control the case of letters in text.
+
+
The letter-spacing property is used to control the spacing of letters in text.
+
+
The background-image property can be used to display text on a non-text background.
+
+
The first-line pseudo class can be used to modify the presentation of the first line
+ in a block of text.
+
+
+
The :first-letter pseudo class can be used to modify the presentation of the first
+ letter in a block of text.
+
+
+
The :before and :after pseudo classes can be used to insert decorative non-text content
+ before or after blocks of text.
+
+
+
+
+
+
Examples
+
+
Example 1: Using CSS font-family to control the font family for text
+
The XHTML component:
+<p>The Javascript method to convert a string to uppercase is <code>toUpperCase()</code>.</p>
+
Example 7: Using CSS text-transform to control the case of text
+
+
Note
+
+
+
The style used in this example is not used to convey information, structure or relationships.
+
+
+
+
The XHTML component:
+<p>09 <span class="caps">March</span> 2008</p>
+
The CSS component:
+.caps { text-transform:uppercase; }
+
+
+
Example 8: Using CSS line-height to control spacing between lines of text
+
The CSS line-height property is used to display the line height for the paragraph
+ at twice the height of the font.
+
+
The XHTML component:
+<p>Concern for man and his fate must always form the<br />
+chief interest of all technical endeavors. <br />
+Never forget this in the midst of your diagrams and equations. </p>
+
The CSS component:
+p { line-height:2em; }
+
The CSS line-height property is used to display the line height for the text at less
+ than the height of the font. The second line of text is positioned after the first
+ line of text and visually appears as though the text is part of the first line but
+ dropped a little.
+
Example 10: Using CSS background-image to layer text and images
+
The CSS font-style property is used to display the textual component of a banner and
+ background-image property is used to display a picture behind the text.
+
+
The XHTML component:
+<div id="banner"><span id="bannerstyle1">Welcome</span>
+<span id="bannerstyle2">to your local city council</span></div>
+
Check whether CSS properties were used to control the visual presentation of text
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C23.html b/wcag21/techniques/css/C23.html
new file mode 100644
index 0000000..654ef52
--- /dev/null
+++ b/wcag21/techniques/css/C23.html
@@ -0,0 +1,172 @@
+
+
+
+
+ C23: Specifying text and background colors of secondary content such as banners, features
+ and navigation in CSS while not specifying text and background colors of the main
+ content
+
+
+
+
+
+
+
+
+
Specifying text and background colors of secondary content such as banners, features
+ and navigation in CSS while not specifying text and background colors of the main
+ content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Some Web pages use colors to identify different groupings. The objective of this technique
+ is to allow users to select specific color combinations for the text and background
+ of the main content while retaining visual clues to the groupings and organization
+ of the web page. When a user overrides the foreground and background colors of all
+ the text on a page, visual clues to the grouping and organization of the Web page
+ may be lost, making it much more difficult to understand and use.
+
+
When an author does not specify the colors of the text and background of the main
+ content, it is possible to change the colors of those regions in the browser without
+ the need to override the colors with a user style sheet. Specifying the text and background
+ colors of secondary content means that the browser will not override those colors.
+
+
With this technique the author uses the default text color and background color of
+ the main area. As a result the colors are completely determined by the user agent
+ via the user's color preferences. The user can ensure that the color selection best
+ meets his needs and provides the best reading experience.
+
+
+
+
Examples
+
+
Example 1
+
An HTML Web page uses CSS to specify the text and background colors of all secondary
+ content such as navigation bars, menu bars, and the table of contents. Neither the
+ text color nor background of the main content is specified. The user sets their own
+ color preferences in the browser so that they view the main content in colors and
+ contrasts that work well for them. The distinction between the separate sections of
+ the page are still visually obvious.
+
+
+
+
Example 2
+
A music magazine has an article that is blue text on a white background. The site
+ provides a link near the beginning of the page which assigns a different style sheet
+ to the page. The new style sheet does not have any colors specified for the text or
+ background.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Change the text, link and background colors in the browser settings so they are different
+ from the default color and different from those specified in the secondary content.
+
+
+
+
Note
+
+
+
Do not select the option that tells the browser to ignore the colors specified in
+ the page.
+
+
+
+
+
+
+
+
Check that the main content uses the new text, link and background colors.
+
+
Check that the colors of the text, links and backgrounds in the secondary content
+ has not changed.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #2 and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C24.html b/wcag21/techniques/css/C24.html
new file mode 100644
index 0000000..c9dcbcb
--- /dev/null
+++ b/wcag21/techniques/css/C24.html
@@ -0,0 +1,107 @@
+
+
+
+
+ C24: Using percentage values in CSS for container sizes
+
+
+
+
+
+
+
+
Using percentage values in CSS for container sizes
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to enable users to increase the size of text without
+ having to scroll horizontally to read that text. To use this technique, an author
+ specifies the width of text containers using percent values.
+
+
+
+
Examples
+
+
Example 1
+
A newspaper has content in the middle of the window. The width of the container for
+ the content is specified in page percentages, so that when a person with low vision
+ increases the font size the text reflows inside the browser window at the new size
+ and there is no need to scroll horizontally.
+
Check that all container widths are specified as percentage values.
+
+
Increase the text size to 200%.
+
+
Check to make sure that horizontal scrolling is not required to read any line of text.
+
+
+
+
Check that all text is still visible on the page.
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1, #3, and #4 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C25.html b/wcag21/techniques/css/C25.html
new file mode 100644
index 0000000..0332576
--- /dev/null
+++ b/wcag21/techniques/css/C25.html
@@ -0,0 +1,165 @@
+
+
+
+
+ C25: Specifying borders and layout in CSS to delineate areas of a Web page while not specifying
+ text and text-background colors
+
+
+
+
+
+
+
+
+
Specifying borders and layout in CSS to delineate areas of a Web page while not specifying
+ text and text-background colors
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The intent of this technique is to specify borders and layout using CSS and leave
+ text and background colors to render according to the user's browser and/or operating
+ system settings (Please see above note in relation to Safari). This allows users to
+ view the text in the colors they require while maintaining other aspects of the layout
+ and page design such as columns of text, borders around sections or vertical lines
+ between a menu and main content area. It will also prevent some display issues in
+ some browsers when pages contain Javascript pop-up boxes or drop-down menus and have
+ the colors overridden.
+
+
Borders and layout indicators help many people with cognitive disabilities, as does
+ flexibility over the text and background colors. Sometimes these two needs are in
+ conflict when the user has to over-ride the author's color selection of text and background
+ in the browser and the browser also removes the borders and the intended layout. This
+ can mean the page is displayed in a single column with one block of content below
+ the other, which can result in unnecessary whitespace and long lines of text. It can
+ also mean that pop-up boxes gain a transparent background, superimposing the text
+ of the box on the text of the page, and drop-down menus either become transparent
+ or gain a dark-grey background. When a Web author does not specify the colors of any
+ text and background, while specifying border colors and layout, it is possible, in
+ most popular browsers, to change the text and background colors without affecting
+ the other (author-specified) CSS declarations.
+
+
+
+
Examples
+
+
Example 1
+
A Web page is designed using HTML. CSS is used to specify border colors around discrete
+ areas of the page and to layout the content so that the menu floats to the left of
+ the main content area. Neither the text color nor background is specified. The user
+ sets their own colors in the browser. They can view the page in colors and contrasts
+ that work well for them without disrupting the layout.
+
Open the Web page in a browser that allows users to change colors of HTML content.
+
+
+
+
+
+
Change the text, link and background colors in the browser settings so they are different
+ than those currently set in the browser.
+
+
+
+
Note
+
+
+
Make sure that you do not select the option that tells the browser to ignore the colors
+ specified in the page.
+
+
+
+
+
+
+
+
Return to the page and check that it is displaying the page in the new text, link
+ and background colors.
+
+
+
Check that any borders are still displayed and that the layout is retained.
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #3 and Check #4 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C27.html b/wcag21/techniques/css/C27.html
new file mode 100644
index 0000000..f001943
--- /dev/null
+++ b/wcag21/techniques/css/C27.html
@@ -0,0 +1,166 @@
+
+
+
+
+ C27: Making the DOM order match the visual order
+
+
+
+
+
+
+
+
Making the DOM order match the visual order
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to ensure that the order of content in the source
+ code is the same as the visual presentation of the content. The order of content in
+ the source code can be changed by the author to any number of visual presentations
+ with CSS. Each order may be meaningful in itself but may cause confusion for assistive
+ technology users. This could be due to the user switching off the author-specified
+ presentation, by accessing the content directly from the source code (such as with
+ a screen reader), or by interacting with the content with a keyboard. If a blind user,
+ who reads the page with a screen reader that follows the source order, is working
+ with a sighted user who reads the page in visual order, they may be confused when
+ they encounter information in different orders. A user with low vision who uses a
+ screen magnifier in combination with a screen reader may be confused when the reading
+ order appears to skip around on the screen. A keyboard user may have trouble predicting
+ where focus will go next when the source order does not match the visual order.
+
+
There may also be situations where the visually presented order is necessary to the
+ overall understanding of the page, and if the source order is presented differently,
+ it may be much more difficult to understand.
+
+
When the source order matches the visual order, everyone will read the content and
+ interact with it in the same (correct) order.
+
+
+
Note
+
+
+
The tabindex attribute in HTML has two functions. One is to make an element focusable and the
+ other is to assign the element a position in the focus order. A tabindex of 0 makes an element focusable, but adds it to the focus order in the order of source
+ elements. The focus order will follow positive values of tabindex in ascending order.
+ Setting tabindex values that result in an order different from the order of elements in the Document
+ Object Model (DOM) can mean the order is incorrect for users of assistive technologies.
+ This is largely because the tabindex property is specified in the HTML or XHTML and
+ not the CSS. This may change in future specifications. It may also differ from the
+ visual presentation order.
+
+
+
+
+
+
+
Examples
+
+
+
An online newspaper has placed a navigation bar visually in the top left corner of
+ the page directly below its initial logo. In the source code, the navigation elements
+ appear after the elements encoding the logo.
+
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Visually examine the order of the content in the Web page as it is presented to the
+ end user.
+
+
+
Examine the elements in the DOM using a tool that allows you to see the DOM.
+
+
Ensure that the order of the content in the source code sections match the visual
+ presentation of the content in the Web page. (e.g., for an English language page the
+ order is from top to bottom and from left to right.) "
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Step #3 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C28.html b/wcag21/techniques/css/C28.html
new file mode 100644
index 0000000..e248350
--- /dev/null
+++ b/wcag21/techniques/css/C28.html
@@ -0,0 +1,151 @@
+
+
+
+
+ C28: Specifying the size of text containers using em units
+
+
+
+
+
+
+
+
Specifying the size of text containers using em units
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to specify the width and/or height of containers,
+ that contain text or that will accept text input, in em units. This will allow user
+ agents that support text resizing to resize the text containers in line with changes
+ in text size settings.
+
+
The width and/or height of text containers that have been specified using other units
+ risk text cropping because it falls outside the container boundaries when the text
+ size has been increased.
+
+
The containers generally control the placement of text within the Web page and can
+ include layout elements, structural elements and form controls.
+
+
+
+
Examples
+
+
Example 1: Em units for sizes for layout container containing text
+
In this example, a div element, with id value of "nav_menu", is used to position the navigation menu along the left-hand
+ side of the main content area of the Web page. The navigation menu consists of a list
+ of text links, with id value of "nav_list." The text size for the navigation links and the width of the
+ container are specified in em units.
+
In this example, input elements that contain text or accept text input by the user have been given the class
+ name "form1." CSS rules are used to define the font size in percent units and width
+ for these elements in em units. This will allow the text within the form control to
+ resize in response to changes in text size settings without being cropped (because
+ the width of the form control itself also resizes according to the font size).
+
+input.form1 { font-size: 100%; width: 15em; }
+
+
+
Example 3: Em units in dropdown boxes
+
In this example, select elements have been given the class name "pick." CSS rules are used to define the
+ font size in percent units and width in em units. This will allow the text within
+ the form control to resize in response to changes in text size settings without being
+ cropped.
+
+input.pick { font-size: 100%; width: 10em; }
+
+
+
Example 4: Em units for non-text-based form controls
+
In this example, input elements that define checkboxes or radio buttons have been given the class name "choose."
+ CSS rules are used to define the width and height for these elements in em units.
+ This will allow the form control to resize in response to changes in text size settings.
+
+
Identify containers that contain text or allow text input.
+
+
Check the container's width and/or height are specified in em units.
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C29.html b/wcag21/techniques/css/C29.html
new file mode 100644
index 0000000..288207f
--- /dev/null
+++ b/wcag21/techniques/css/C29.html
@@ -0,0 +1,746 @@
+
+
+
+
+ C29: Using a style switcher to provide a conforming alternate version
+
+
+
+
+
+
+
+
Using a style switcher to provide a conforming alternate version
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
CSS used with client-side or server-side scripting.
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
When some aspect of the default presentation of a Web page does not meet a Success
+ Criterion, it is possible to meet that requirement using the "Alternate Version" clause
+ in the conformance requirements (Conformance Requirement 1). For some requirements,
+ invoking a style switcher via a link or control on the page that can adjust the presentation
+ so that all aspects of the page conform at the level claimed allows authors to avoid
+ having to provide multiple versions of the same information.
+
+
The objective of this technique is to demonstrate how CSS can be used in combination
+ with scripting to provide conforming alternate versions of a Web page. In this technique,
+ an author provides alternative views of the content by providing controls that adjust
+ the CSS that is used to control the visual presentation of content. Controls provided
+ within the Web page allow users to select or modify the presentation in a way that
+ meets the success criterion at the level claimed. This makes it possible for different
+ visual presentations to be selected by users in situations such as the following:
+
+
+
+
the user may not be able to adjust browser or operating system settings, due to a
+ lack of familiarity or rights
+
+
+
the text is provided in a manner that does not respond to browser or operating system
+ settings (such as text within an image)
+
+
+
the default presentation of the content does not include sufficient contrast for some
+ users
+
+
+
+
For this technique to be used successfully, three things must be true.
+
+
+
The link or control on the original page must itself meet the success criteria to
+ be met via the alternate presentation. For example, if a style switcher is used to
+ provide increased font sizes and the control is presented using a small font, users
+ may not be able to activate the control and view the alternate presentation.
+
+
+
The new page must contain all the same information and functionality as the original
+ page.
+
+
+
The new page must conform to all of the Success Criteria for the desired level of
+ conformance. For example, an alternate stylesheet can not be used to meet one requirement
+ if it causes a different requirement to no longer conform.
+
+
+
+
When using a style switcher, it is important to consider the following challenges
+ and limitations:
+
+
+
+
The number and type of changes that a user can make is limited to the scope of the
+ controls provided by the author of the Web page. A variety of presentation and preferences
+ should be provided in order to address the needs of as wide an audience as possible.
+ However, it is also important for authors to consider interactions between preferences
+ and the complexity for users that might result from providing large numbers of options
+ to users.
+
+
+
Maintaining the user's preference from one page to the next may be achieved by storing
+ a cookie on the user's machine (see Resources section for more information) or by
+ including their preferences in a profile saved on the Web server by passing a query
+ string parameter, or by other means.
+
+
+
The technical method used to implement a style switcher may be subject to the support
+ and availability of one or more technologies on the user's machine (for example, many
+ client-side solutions require support for both JavaScript and CSS). Unless these technologies
+ are relied upon for conformance, authors should consider using server-side technologies
+ where client-side support and availability of technologies can not be assured. Alternatively,
+ the use of techniques which ensure that content will transform gracefully when one
+ or more of the technologies used are not available can be an effective way to enhance
+ pages when support for these technologies is not relied upon for conformance.
+
+
+
+
+
+
Examples
+
+
Example 1: Using a JavaScript control to apply a different external CSS file
+
This example is of a page that provides links to change text and background colors
+ for the page via JavaScript. The links should only be inserted if JavaScript is supported
+ by and available on the user's system. Otherwise, selecting the links will not result
+ in the desired changes. This can be achieved by using script to insert the links themselves
+ (which means that the links would only be present when scripting is supported and
+ available).
+
+
The following code shows the JavaScript-dependent color-change links and a snippet
+ of other content in the Web page, the associated style sheet rules, and the JavaScript
+ that changes the style sheet in use when a color-change link is selected.
+
+
The example applies only to the current page view. In a production environment, it
+ would be advisable to save this preference in a cookie or server-side user profile,
+ so that users would only have to make the selection once per site.
+
Example 2: Using a client-side JavaScript to change a CSS property
+
This example can be used for simple changes to a section of content and may be less
+ practical for complex sites or pages. The example uses a client-side JavaScript to
+ change the class name to visually present the user's color selection (from a defined
+ set of options) as a background for highlighting specific content.
+
+
+
Note
+
+
+
The following code includes JavaScript calls within the XHTML code to aid understanding
+ of the technique. However, the author is encouraged to use current best practice for
+ including JavaScript (see resources for more information about Unobtrusive JavaScript
+ and progressive enhancement).
+
+function changeColor(hghltColor)
+{
+ // collects table data cells into an array
+
+ var els = document.getElementsByTagName('td');
+
+ // for each item in the array, look for a class name starting with "hghlt"
+ // if found, change the class value to the current selection
+ // note that this script assumes the 'td' class attribute is only used for highlighting
+
+ for (var i=0; i<els.length; i++)
+ {
+ if (els[i].className.indexOf("hghlt") == 0) { els[i].className = hghltColor; }
+ }
+}
+
+
Example 3: Using PHP $_GET to apply a different external CSS file
+
This simple example uses PHP $_GET to assign one of two available external style sheets.
+ Similar functionality could be achieved using a variety of PHP features. The example
+ applies only to the current page view. In a production environment, it would be advisable
+ to save this preference in a cookie or server-side user profile, so that users would
+ only have to make the selection once per site.
+
+
The following code is PHP, but a similar approach would work with a variety of server-side
+ technologies.
+
Example 4: Using JSP to provide an alternative style sheet
+
The example below uses two files
+
+
+
a Java Server Page (JSP) with the form and the form processing code, and
+
+
an include file with functions used by the previous page and in other pages use the
+ same style.
+
+
+
+
The server-side code outputs a normal link element for the stylesheet that the user
+ chooses and link elements with "alternate stylesheet" for the other styles. The code
+ can thus be used as a fallback for the client-side code in the second example.
+
+
The JSP page with the form:
+ <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"
+ %><%@include file="_jsp/styleswitch.jsp"%><?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+ <head>
+ <meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
+ <title>Change Style</title>
+ <%
+ String fStyle = "";
+ String styleName = "style";
+ String defaultStyle = "default";
+ Cookie[] cookies = request.getCookies();
+
+ // get style from post request parameters
+ if (request.getMethod().equals("POST") && request.getParameter("styleSelect") != null) {
+ fStyle = request.getParameter("styleSelect");
+ // code that validates user input (security) not shown
+
+ if (fStyle.equals("nostyle")) { // user prefers no author style
+ } else { // user requests author style
+ out.println(createStyleLinks(fStyle).toString());
+ }
+
+ storeStylePreferenceCookie(request, response, fStyle);
+ } else if (request.getMethod().equals("GET")) {
+ // GET request; get style from cookie; else default style links
+ // get style from cookie
+ if (cookies != null) {
+ // get style from cookies
+ fStyle = getStyleFromCookies(cookies);
+
+ if ( !fStyle.equals("NULL_STYLE") ) { // user requests author style
+ out.println(createStyleLinks(fStyle).toString());
+ } else { // no cookie for style; process request for style preference
+ // default style links
+ out.println(createStyleLinks(defaultStyle).toString());
+ }
+ } else { // GET request without cookies: default styles
+ out.println(createStyleLinks(defaultStyle).toString());
+ }//end else cookies
+ }
+ %>
+ </head>
+ <body id="home">
+ <form action="_styleSwitch.jsp" method="post" id="styleswitchform" name="styleswitchform">
+ <p><label for="styleSelect">Select style: </label>
+ <select id="styleSelect" name="styleSelect">
+ <option value="default">Default (shades of green)</option>
+ <option value="wonb">White on black</option>
+ <option value="bonw">Black on white</option>
+ </select>
+ <input type="submit" value="Change Style" />
+ </p>
+ </form>
+ </body>
+ </html>
+
The styleswitcher.jsp file included in the previous file:
+ <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
+ <%!
+ /**
+ * Get the links (link elements) to the CSS files based on cookies, ...
+ */
+ private String getStyleLinks(HttpServletRequest request) {
+ String styleLinks = "";
+ Cookie[] cookies = request.getCookies();
+ String defaultStyle = "default";
+ String tempStyle = "";
+ // GET request; get style from cookie; else default style links
+ // get style from cookie
+ if (cookies != null) {
+ // get style from cookies
+ tempStyle = getStyleFromCookies(cookies);
+
+ if ( tempStyle.equals("NULL_STYLE") ) {
+ // no cookie for style; process request for style preference
+ // default style links
+ styleLinks = createStyleLinks(defaultStyle).toString();
+ } else { // user requests author style
+ styleLinks = createStyleLinks(tempStyle).toString();
+ }
+ } else { // GET request without cookies: default styles
+ styleLinks = createStyleLinks(defaultStyle).toString();
+ }//end else cookies
+
+ return styleLinks;
+ }
+
+ /**
+ * Get style cookie from request
+ */
+ private String getStyleFromCookies( Cookie[] cookies ) {
+ String fStyle = "NULL_STYLE";
+ for (int i = 0; i < cookies.length; i++) {
+ Cookie cookie = cookies[i];
+ String name = cookie.getName();
+
+ if ( name.equals("style") ) {
+ fStyle = cookie.getValue();
+ // code that validates cookie value (security) not shown
+ }
+ }
+ return fStyle;
+ }
+
+ /**
+ * Store the style preference in a persistent cookie
+ */
+ private void storeStylePreferenceCookie(HttpServletRequest request,
+ HttpServletResponse response, String theStyle) {
+ final int ONE_YEAR = 60 * 60 * 24 * 365;
+ Cookie styleCookie = new Cookie("style", theStyle);
+ styleCookie.setMaxAge(ONE_YEAR);
+ response.addCookie(styleCookie);
+ }
+
+ /**
+ * Create the link elements for the stylesheets
+ */
+ private StringBuffer createStyleLinks(String prefStyle) {
+ StringBuffer theStyleLinks = new StringBuffer();
+ //two-dimensional array with identifiers (adding '.css' gives the name of the CSS file)
+ // and strings for the title attribute of the link element
+ // the identifiers must correspond to the in the "value" attributes in the "option"
+ // elements in the style switcher form
+ String [] [] styles = {
+ { "default", "Default style"},
+ { "wonb", "White on black"},
+ { "bonw", "Black on white"}
+ };
+
+ // loop over 2dim array: if styles[i][1] matches prefStyle,
+ // output as normal, else as alternate stylesheet
+ for (int i = 0; i < styles.length; i++) {
+ if ( styles[i][0].equals(prefStyle) ) { // output pref stylesheet as normal stylesheet
+ theStyleLinks.append("<link rel=\"stylesheet\" href=\"_css/").append(styles[i][0])
+ .append(".css\" title=\"").append(styles[i][1]).append("\" type=\"text/css\" />").append("\n");
+ } else { // output other stylesheets as alternate stylesheets
+ theStyleLinks.append("<link rel=\"alternate stylesheet\" href=\"_css/")
+ .append(styles[i][0]).append(".css\" title=\"").append(styles[i][1])
+ .append("\" type=\"text/css\" />").append("\n");
+ }
+ } // end for loop
+
+ return theStyleLinks;
+ }
+ %>
+
Other JSP pages can use this code by means of the following include and scriptlet
+ code:
+
A user's selection can be made persistent across pages, and from one visit to another,
+ by storing information on the user's computer via a cookie. This functionality requires
+ cookies to be supported by and allowed on the user's computer. Cookies can be created,
+ read, modified and erased by using client-side scripts, such as Javascript, or by
+ server-side scripts, such as CGI scripts. Reliance on client-side technologies will
+ require the support and availability of the technology on the user's computer in addition
+ to supporting and allowing cookies.
+
+
+
Information on creating and using cookies can be found on the web. Here are some suggestions:
+
+
It is recommended that authors test for cookie support and provide an extra control
+ if cookies are not supported. This extra control should include information about
+ the persistence of the selection, such as "Apply selection to all pages". The message
+ or page presented to the user in response to selecting the extra control provides
+ information about the cookie requirement and their options for solving it. In the
+ event that the user is unable to turn cookie support on, include a statement about
+ what this will mean for them if they choose to continue to browse the site and provide
+ information about how they can adjust their user agent to achieve similar results.
+
+
+
+
For example, "Your browser is not configured to accept cookies. On this site, cookies
+ are required in order to apply your selected changes across all of the pages of the
+ site. To find out how to enable cookies on your computer, visit How to Enable Cookies. Note that this may require administrative rights for the computer you are using.
+ Without cookie support, your settings will not persist to include other pages on this
+ site. We are endeavoring to provide this functionality without relying on your computer's
+ capability. In the meantime, you will be able to select the change for each page that
+ you visit."
+
+
+
+
+
+
Progressive Enhancement and Unobtrusive Javascript
+
+
Current best practice for implementing JavaScript in an HTML or XHTML page is to use
+ it in a way that separates the behavior of content from its structure and presentation.
+ The terms 'Progressive Enhancement' and 'Unobtrusive JavaScript' are often used to
+ describe scripts that enhance or improve the functionality of a page, yet transform
+ gracefully so that content continues to function even when JavaScript is not supported.
+
+
+
Here are some suggested starting points for more information:
Check that the Web page contains controls that allow users to select alternate presentations.
+
+
+
+
Check that the control changes the presentation by modifying individual CSS style
+ properties or by activating an alternate style sheet.
+
+
+
Verify that the resulting page is a conforming alternate version for the original
+ page.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
All of the above checks are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C30.html b/wcag21/techniques/css/C30.html
new file mode 100644
index 0000000..ef12a88
--- /dev/null
+++ b/wcag21/techniques/css/C30.html
@@ -0,0 +1,232 @@
+
+
+
+
+ C30: Using CSS to replace text with images of text and providing user interface controls
+ to switch
+
+
+
+
+
+
+
+
+
Using CSS to replace text with images of text and providing user interface controls
+ to switch
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how CSS can be used to replace structured
+ HTML text with images of text in a way that makes it possible for users to view content
+ according to their preferences. To use this technique, an author starts by creating
+ an HTML page that uses semantic elements to mark up the structure of the page. The
+ author then designs two or more stylesheets for that page. One stylesheet presents
+ the HTML text as text and the second uses CSS features to replace some of the HTML
+ text with images of text. Finally, through the use of server-side or client-side scripting,
+ the author provides a control that allows the user to switch between the available
+ views.
+
+
This technique can be used to meet Success Criterion 1.4.5 or 1.4.9 if a presentation
+ that does not include images of text is available and as long as the user interface
+ control that is provided to allow users to switch to an alternate presentation meets
+ the relevant criteria. Where possible, authors should deliver the presentation that
+ does not include images of text as the default presentation. In addition, the control
+ used to switch should be located near the beginning of the page.
+
+
A variety of "image replacement" techniques have been developed to address a variety
+ of user agent, configuration and compatibility with assistive technology issues (See
+ resources for more information). While there are a variety of approaches authors may
+ use to replace text, it is important to consider compatibility with assistive technology,
+ whether the technique will work correctly if scripting, CSS, images (or combinations
+ of these) are turned off. Since it can be difficult to find a single solution that
+ works in all cases, this technique recommends the use of a control that allows users
+ to switch to a presentation that does not include an image replacement technique.
+
+
A design studio site uses a style switcher to allow users to view two presentations
+ of their home page. For the default version, the heading text is replaced with images
+ of text. A control on the page allows users to switch to a version that presents the
+ headings as text.
+
The CSS for the presentation that includes images of text follows. Note that the CSS
+ uses positioning to place the contents of the heading elements offscreen so that the
+ text remains available to screen reader users.
+
Check that the Web page includes a control that allows users to select an alternate
+ presentation.
+
+
+
Check that when the control is activated the resulting page includes text (programmatically
+ determined text) wherever images of text had been used.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
All of the above checks are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C31.html b/wcag21/techniques/css/C31.html
new file mode 100644
index 0000000..be77e61
--- /dev/null
+++ b/wcag21/techniques/css/C31.html
@@ -0,0 +1,230 @@
+
+
+
+
+ C31: Using CSS Flexbox to reflow content
+
+
+
+
+
+
+
+
Using CSS Flexbox to reflow content
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to be able to present content without introducing
+ a horizontal scroll bar at a width equivalent to 320 CSS pixels, or a vertical scroll
+ bar at a height equivalent to 256 CSS pixels for text intended to scroll horizontally.
+ This is done by using layout techniques that adapt to the available viewport space.
+
+
Flexbox layouts define layout regions that reflow as needed to display the region on the screen.
+ Although the exact layout therefore varies, the relationship of elements and the reading
+ order remains the same when done right. This is an effective way to create designs
+ that present well on different devices and for users with different zoom preferences.
+
+
The basic principles of flexbox layouts are to:
+
+
+
Define the size of layout regions using flexbox properties and media queries for specific
+ viewport sizes, so they enlarge, shrink or wrap in the available space and respond
+ to zoom levels;
+
+
+
Position the layout regions in the flexbox container as a row of adjacent flexbox
+ items, which may wrap to new rows as needed in much the same way as words in a paragraph
+ wrap.
+
+
+
+
+
Note
+
Flexbox has the possibility to cause a keyboard navigation disconnect by using the
+ order and reverse properties. The CSS Flexible Box Layout module warns against resequencing content logic as they cause incorrect source ordering and are
+ non-conforming.
+
+
+
+
+
Examples
+
+
Example 1: Example 1: Medium complex flexbox layout in HTML and CSS
+
The following medium complex example uses HTML and CSS to create a flexbox layout.
+ The layout regions adjust their size as the viewport is adjusted. When the total viewport
+ width matches the width defined via media queries, columns wrap to be positioned below,
+ rather than beside each other or vice versa.
+
+
The zoom level can be increased to 400% without requiring scrolling in more than one
+ direction. This particular example uses percent sizes for the flex items by using
+ the "flex-basis" property and are laid out in source order.
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For content read horizontally, check that all content and functionality is available
+ without horizontal scrolling.
+
+
+
For content read vertically, check that all content and functionality is available
+ without vertical scrolling.
+
+
+
+
+
Note
+
If the browser is not capable of zooming to 400%, you can reduce the width of the
+ browser proportionally. For example, at 300% zoom the viewport should be sized to
+ 960px wide.
+
+
+
+
+
Expected Results
+
#3 and #4 are true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C32.html b/wcag21/techniques/css/C32.html
new file mode 100644
index 0000000..cc4fbcb
--- /dev/null
+++ b/wcag21/techniques/css/C32.html
@@ -0,0 +1,248 @@
+
+
+
+
+ C32: Using media queries and grid CSS to reflow columns
+
+
+
+
+
+
+
+
Using media queries and grid CSS to reflow columns
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to be able to present content without introducing
+ a horizontal scroll bar at a width equivalent to 320 CSS pixels, or a vertical scroll
+ bar at a height equivalent to 256 CSS pixels for text intended to scroll horizontally.
+ This is done by using layout techniques that adapt to the available viewport space.
+
+
Grid layouts define layout regions that reflow as needed to display the region on the screen.
+ Although the exact layout therefore varies, the relationship of elements and the reading
+ order remains the same when done right. This is an effective way to create designs
+ that present well on different devices and for users with different content-size preferences.
+
+
The basic principles of grid layouts are to:
+
+
+
Define the size of layout regions using grid properties and media queries for specific
+ viewport sizes, so they enlarge, shrink or wrap in the available space and respond
+ to zoom levels;
+
+
+
Position the layout regions in the grid container as a row of adjacent grid items,
+ which may wrap to new rows as needed in much the same way as words in a paragraph
+ wrap.
+
+
+
+
+
Note
+
Use of grid layout CSS can cause a keyboard navigation disconnect by making the visual
+ layout and source-code order different. The CSS Grid Layout Module Level 1 warns against re-ordering content by grid item placement as they cause an incorrect focus
+ order for keyboard users and others.
+
+
+
+
+
Examples
+
+
Example 1: Example 1: Grid layout in HTML and CSS - Medium complexity
+
The following medium complexity example uses HTML and CSS to create a grid layout.
+ The layout regions adjust their size as the viewport is adjusted. When the total viewport
+ width matches the width defined via media queries, columns wrap to be positioned below,
+ rather than beside each other or vice versa.
+
+
The zoom level can be increased to 400% without requiring scrolling in more than one
+ direction. This particular example uses fr units as a fraction of the free space of
+ the grid container for the grid items by using the "grid-template-columns" property
+ and are laid out in source order.
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For content read horizontally, check that all content and functionality is available
+ without horizontal scrolling.
+
+
+
For content read vertically, check that all content and functionality is available
+ without vertical scrolling.
+
+
+
+
+
Note
+
If the browser is not capable of zooming to 400%, you can reduce the width or height
+ of the browser proportionally. For example, at 300% zoom the viewport should be sized
+ to 960px wide.
+
+
+
+
+
Expected Results
+
Check that #3 and #4 are true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C33.html b/wcag21/techniques/css/C33.html
new file mode 100644
index 0000000..ff52f70
--- /dev/null
+++ b/wcag21/techniques/css/C33.html
@@ -0,0 +1,128 @@
+
+
+
+
+ C33: Allowing for Reflow with Long URLs and Strings of Text
+
+
+
+
+
+
+
+
Allowing for Reflow with Long URLs and Strings of Text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique is applicable to Cascading Style Sheet / HTML technologies.
Long sets of characters without a space, such as URLs shown as content, can break
+ reflow when the page is zoomed. The objective of this technique is to present URLs
+ without introducing a horizontal scroll bar at a width equivalent to 320 CSS pixels
+ or a vertical scroll bar at a height equivalent to 256 CSS pixels. This is done by
+ using CSS techniques that adapt to the available viewport space. Note: Using a human
+ readable text link, rather than a long URL, is better for usability and accessibility.
+
+
By default most browsers will wrap long URLs at the following characters:
+
+
+
"-" Hyphen
+
+
" " Space
+
+
"?" Question (IE, Chrome, Safari)
+
+
"&" Ampersand (Firefox only)
+
+
+
Sometimes these are not enough to ensure that long URLs will not overflow the viewport.
+
+
+
Examples
+
+
Example 1: Breaking long URLs
+
Using the following CSS will cause long URLs to break at appropriate places (hyphens,
+ spaces, etc.) and within words without causing reflow.
+
+
List of CSS declarations used and why they are used:
+
+
+
overflow-wrap: break-word: Allows words to be broken and wrapped within words.
+
+
+
word-wrap: break-word: Allows words to be broken and wrapped within. (Microsoft only)
+
+
+
a {overflow-wrap: break-word;}
+
Note
+
IE and Edge only support this declaration when used with the * (wildcard) selector
For strings of text that are wider than 320px check:
+
+
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For content read horizontally, check that all content and functionality is available
+ without horizontal scrolling.
+
+
+
For content read vertically, check that all content and functionality is available
+ without vertical scrolling.
+
+
+
+
+
Note
+
If the browser is not capable of zooming to 400%, you can reduce the width of the
+ browser proportionally. For example, at 300% zoom the viewport should be sized to
+ 960px wide.
+
+
+
+
+
Expected Results
+
#3 and #4 are true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C34.html b/wcag21/techniques/css/C34.html
new file mode 100644
index 0000000..3d37f94
--- /dev/null
+++ b/wcag21/techniques/css/C34.html
@@ -0,0 +1,214 @@
+
+
+
+
+ C34: Using media queries to un-fixing sticky headers / footers
+
+
+
+
+
+
+
+
Using media queries to un-fixing sticky headers / footers
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique is applicable to Cascading Style Sheet / HTML technologies.
The objective of this technique is to be able to present content with sticky headers
+ and footers when there is enough space. This is done by using min-height, max-height and min-width media queries techniques that adapt to the available space of the viewport.
+
+
Sticky regions always stay visible in the viewport while the other content will disappear
+ underneath when scrolling. In terms of content visibility, this is often not a problem
+ on the desktop and on mobile devices in portrait orientation. However, when using
+ mobile devices in landscape orientation or when zooming in on the desktop, sticky
+ regions may block a big portion of the screen: the height of the sticky region may
+ leave only a small part of the screen for the display of page content.
+
+
Disabling, or un-fixing sticky regions, is an effective way to allow for enough available
+ space when users prefer different reading and zoom preferences or when using landscape
+ mode.
+
+
+
Note
+
Be aware that sticky regions can create disadvantages for keyboard users and should
+ therefore be used judiciously. The problem for keyboard users tabbing through a page
+ with a fixed header is that once the page has started to scroll, tabbing backwards
+ to reach interactive elements higher up on the page will often mean that the focus
+ becomes invisible once it moves behind the sticky header. Users must then scroll up
+ to be able to see the focus, something they may not necessarily be aware of. In the
+ same way the visible focus can disappear behind a sticky footer, so users would need
+ to scroll down to be able to see their focus position, which is a major inconvenience.
+
+
+
The basic approach for un-fixing sticky headers / footers is to:
+
+
+
Define the first sticky regions using media query min-height properties, so they get fixed or un-fixed depending on the available space;
+
+
+
+
Define other sticky regions using media query min-width and max-height properties for specific viewport sizes, so they get fixed or un-fixed depending on
+ the available space, e.g. for tablets depending on the portrait or landscape position
+ of the device;
+
+
+
+
+
+
Examples
+
+
Example 1: Un-fix sticky headers / footers in HTML and CSS
+
The following example uses HTML and CSS to un-fix sticky headers / footers.
+
+ The sticky regions get un-fixed as the height of the viewport is limited or the orientation
+ is changed.
+
+ When the min-height property matches the viewport space defined via media queries, regions which are
+ not sticky get fixed or vice versa. This particular example uses the CSS min-height, max-height and min-width media query properties.
+
Depending on the environment to be tested the actual modes or sizes can differ.
+
+
+
+
Display content on a device / user agent in portrait mode.
+
+
Change the orientation to landscape.
+
+
Check whether the sticky header and footer will be un-fixed depending on the existing
+ media query settings.
+
+
+
Display content on a desktop / user agent at a starting viewport width of 1280x1024
+ CSS pixels.
+
+
+
Change the viewport size in width and height or use the zoom function of the browser.
+
+
Check whether the sticky header and footer will be un-fixed at specific sizes depending
+ on the existing media query settings.
+
+
+
+
+
+
Expected Results
+
+
+
#3 and #6 are true.
+
+
+
If this is a sufficient technique for a success criterion, failing this test procedure
+ does not necessarily mean that the success criterion has not been satisfied in some
+ other way, only that this technique has not been successfully implemented and can
+ not be used to claim conformance.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C35.html b/wcag21/techniques/css/C35.html
new file mode 100644
index 0000000..50f16c3
--- /dev/null
+++ b/wcag21/techniques/css/C35.html
@@ -0,0 +1,164 @@
+
+
+
+
+ C35: Allowing for text spacing without wrapping
+
+
+
+
+
+
+
+
Allowing for text spacing without wrapping
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to allow a user to override text spacing via user
+ stylesheet, bookmarklet, extension, or application. Increased spacing between paragraphs,
+ lines, words, and characters benefits people with low vision or some cognitive disabilities.
+ Content needs to allow spacing changes without loss of content or functionality by
+ allowing the elements containing the text to expand as needed.
+
+
Where text is not intended to wrap, authors should either:
+
+
+
+
size containers to a have a value greater than the default width of the text, or
+
+
allow the containers to expand in the direction of text.
+
+
+
There is some variability in the width that words or phrases will grow to when setting
+ the letter and word spacing. If elements must use a fixed width, a safe value is 20%
+ wider than the default maximum width. For example, if a small text-container allows
+ for 20 characters, allowing enough width for 24 characters should allow enough space
+ for text-spacing to be applied.
+
+
For boxes which can expand with the text, authors can take advantage of the inline-block
+ value of the CSS display property and not set negative margins to allow for text-spacing
+ overrides.
+
+
+
+
Examples
+
When a user adapts the page to increase the text spacing, text fits within the bounds
+ of its containing box.
+
+
+
Note
+
The ex unit has been used as as the closest available unit for character width, ex "Represents the x-height of the element's font." (MDN page for CSS units). It is not perfect, different characters have different default widths.
+
+
+
+
Example 1: A box sized with space to allow for expansion
+
The containers are sized to a value greater than the default width of the text.
/* Links are less than 8ex wide, so 10ex width of each li allows for expanded letter and word width*/
+ nav li { width: 10em; }
+
+<!-- HTML -->
+ <nav>
+ <ul>
+ <li><a href="/">Home</a></li>
+ <li><a href="/contact/">Contact</a></li>
+ <ul>
+ </nav>
+
If the navigation element used fix-width containers of the same size, the width would
+ need to allow for text 20% larger than the longest word.
+
+
+
+
Example 2: A box which expands with the text size
/* CSS containers are given a display of inline-block. No negative margins set. */
+ nav li { display: inline-block; }
+
+<!-- HTML -->
+ <nav>
+ <ul>
+ <li><a href="/">Home</a></li>
+ <li><a href="/contact/">Contact</a></li>
+ <ul>
+ </nav>
+
In the case of variable-width text containers for each item, the parent item may need
+ to allow for wrapping of the items.
+
For elements which contain text that is not intended to wrap:
+
+
+
Set zoom level to 100%.
+
+
Use a tool or another mechanism to apply the text spacing metrics (line height, and
+ paragraph, letter, and word spacing), such as the Text Spacing Bookmarklet or a user-style browser plugin.
+
+
+
Check that all content and functionality is available e.g., text in containers is
+ not truncated and does not overlap other content.
+
+
+
+
+
+
Expected Results
+
+
+
#3 is true.
+
+
+
+
Note
+
Where a page has multiple layouts (e.g. in a responsive design) text spacing should
+ be tested in each layout.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C36.html b/wcag21/techniques/css/C36.html
new file mode 100644
index 0000000..674dc16
--- /dev/null
+++ b/wcag21/techniques/css/C36.html
@@ -0,0 +1,128 @@
+
+
+
+
+ C36: Allowing for text spacing override
+
+
+
+
+
+
+
+
Allowing for text spacing override
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to allow a user to override text spacing via user
+ stylesheet, bookmarklet, extension, or application. Increased spacing between paragraphs,
+ lines, words, and characters benefits people with low vision or some cognitive disabilities.
+ Content needs to allow spacing changes without loss of content or functionality, so
+ text containers must either have room for the text to expand or the container must
+ be able to expand. This technique will typically apply to short strings of text such
+ as in a navigation bar, as longer strings of text are increasingly likely to require
+ wrapping to be readable when styles are changed.
+
+
In English languages, if authors do not set the CSS height property, it can help ensure paragraphs expand. Paragraphs need to allow text to
+ increase vertically for languages or scripts such as English which are read horizontally
+ or to increase horizontally for languages or scripts which are read vertically.
+
+
+
+
Examples
+
When a user adapts the page to increase the text spacing, text fits within the bounds
+ of its containing box.
+
+
+
Example 1: A paragraph expands vertically within container
/* CSS: No height property is set.*/
+
+<!-- HTML -->
+ <div class="card">
+ <img src="image.png" alt="proper alt text">
+ <h3>Heading</h3>
+ <p class="lede">Long lede paragraph…</p>
+ </div>
+
None of the paragraphs on this page have a height specified, so all are effectively
+ using this technique.
+
For elements which contain text that is intended to wrap:
+
+
+
Set zoom level to 100%.
+
+
Use a tool or another mechanism to apply the text spacing metrics (line height, and
+ paragraph, letter, and word spacing), such as the Text Spacing Bookmarklet or a
+ user-style browser plugin.
+
+
+
Check that all content and functionality is available e.g., text in containers is
+ not truncated and does not overlap other content.
+
+
+
+
+
+
Expected Results
+
+
+
#3 is true.
+
+
+
+
Note
+
Where a page has multiple layouts (e.g. in a responsive design) text spacing should
+ be tested in each layout.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C37.html b/wcag21/techniques/css/C37.html
new file mode 100644
index 0000000..d25f62c
--- /dev/null
+++ b/wcag21/techniques/css/C37.html
@@ -0,0 +1,142 @@
+
+
+
+
+ C37: Using CSS max-width and height to fit images
+
+
+
+
+
+
+
+
Using CSS max-width and height to fit images
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique is applicable to Cascading Style Sheet / HTML technologies.
The objective of this technique is to be able to present images without introducing
+ a horizontal scroll bar at a width equivalent to 320 CSS pixels, or a vertical scroll
+ bar at a height equivalent to 256 CSS pixels for content intended to scroll horizontally.
+ This is done by using CSS max-width and height property techniques that adapt to the available space and keep the original dimensions
+ of the image.
+
+
Responsive layouts can add or remove columns or layout blocks, and each part of the
+ layout can be wider or smaller at different points. This technique ensures images
+ do not break out of their layout area, including in one-column layouts where it would
+ cause scrolling.
+
+
The basic principles of fitting images are to:
+
+
+
Define the max-width property for images, and;
+
+
+
Define the height property for images, so they enlarge or shrink in the available space and respond
+ to zoom levels.
+
+
+
+
All images require design finesse by making sure the original size fits the biggest
+ size of the available spaces to achieve good-looking results at a wide range of viewport
+ sizes and zoom levels.
+
+
+
+
Examples
+
+
Example 1: Fitting images in HTML and CSS
+
The following simple example uses HTML and CSS to create a fitting image. The layout
+ regions adjust their size as the viewport is adjusted. The images subsequently adjust
+ their size to fit within the layout region containers.
+
+
The zoom level can be increased to 400% without requiring scrolling in more than one
+ direction. This particular example uses a percent size for the max-width and auto size for the height of the image to remain the original dimensions.
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For content read horizontally, check that all images fit in their available space
+ without horizontal scrolling.
+
+
+
For content read vertically, check that all images fit in their available space without
+ vertical scrolling.
+
+
+
+
+
Note
+
If the browser is not capable of zooming to 400%, you can reduce the width of the
+ browser proportionally. For example, at 300% zoom the viewport should be sized to
+ 960px wide.
+
+
+
+
+
Expected Results
+
#3 and #4 are true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C38.html b/wcag21/techniques/css/C38.html
new file mode 100644
index 0000000..1977971
--- /dev/null
+++ b/wcag21/techniques/css/C38.html
@@ -0,0 +1,213 @@
+
+
+
+
+ C38: Using CSS width, max-width and flexbox to fit labels and inputs
+
+
+
+
+
+
+
+
Using CSS width, max-width and flexbox to fit labels and inputs
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique is applicable to Cascading Style Sheet / HTML technologies.
The objective of this technique is to be able to present labels and inputs without
+ introducing a horizontal scroll bar at a width equivalent to 320 CSS pixels for content
+ intended to scroll vertically. When space is limited in the viewport for the label
+ and input to sit next to each other horizontally, they will be changed to a vertical
+ alignment. This is done by using CSS properties for width, max-width and flexbox that adapt to the available space.
+
+
Responsive layouts can add or remove columns or layout blocks, and each part of the
+ layout can be wider or smaller at different points. This technique ensures labels
+ and inputs do not break out of their layout area, including in one-column layouts
+ where it would cause horizontal scrolling.
+
+
The basic approach for fitting labels and inputs is to:
+
+
+
Define the size of layout regions using flexbox properties and media queries for specific
+ viewport sizes, so they enlarge, shrink or wrap in the available space and respond
+ to zoom levels;
+
+
+
Position the layout regions in the flexbox container as a row of adjacent flexbox
+ items, which may wrap to new rows as needed in much the same way as words in a paragraph
+ wrap.
+
+
+
Define the width and max-width property for labels and inputs so they enlarge or shrink
+ in the available space and respond to zoom levels.
+
+
+
+
All labels and inputs require design finesse by making sure the original size fits
+ the biggest size of the available spaces to achieve good-looking results at a wide
+ range of viewport sizes and zoom levels. For help on flexbox please see the MDN article on Flexbox.
+
+
+
+
Examples
+
+
Example 1: Fitting labels, inputs and flexbox layout with HTML and CSS.
+
The following example uses HTML and CSS to fit labels and inputs within various width
+ containers, including the viewport. The layout regions adjust their size as the viewport
+ is adjusted. The labels and inputs subsequently adjust their size to fit within the
+ layout region containers.
+
+
The zoom level can be increased to 400% without requiring horizontal scrolling. This
+ particular example uses a percent size for the width and max-width for the labels and inputs. The max-width is applied in order to fix elements spilling out of the grid in a cross-browser way,
+ as replaced elements such as the select have intrinsic sizing.
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For vertically scrolling content, all labels and inputs fit in their available space
+ without horizontal scrolling.
+
+
+
+
NB: If the browser is not capable of zooming to 400%, you can reduce the width of
+ the browser proportionally. For example, at 300% zoom the viewport should be sized
+ to 960px wide.
+
+
+
+
Expected Results
+
Check #3 is true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C39.html b/wcag21/techniques/css/C39.html
new file mode 100644
index 0000000..91ed8cd
--- /dev/null
+++ b/wcag21/techniques/css/C39.html
@@ -0,0 +1,106 @@
+
+
+
+
+ C39: Using the CSS reduce-motion query to prevent motion
+
+
+
+
+
+
+
+
Using the CSS reduce-motion query to prevent motion
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to allow users to prevent animation from being
+ displayed on Web pages, via the use of of the 'prefers-reduced-motion' CSS Media Query.
+
+
Some users experience distraction or nausea from animated content. For example, if
+ scrolling a page causes elements to move (other than the essential movement associated
+ with scrolling) it can trigger vestibular disorders. Enclosing the CSS that creates
+ the animations in a media query allows people to prevent those symptoms.
+
+
A typical example is 'parallax scrolling', where backgrounds move at different rates.
+ The movement due to scrolling the page is essential (and under the users control),
+ but additional movement triggered by the scrolling can also trigger vestibular symptoms.
+
+
The understanding document for Motion Actuation includes links for changing the reduce motion setting.
+
+
+
+
Examples
+
+
Example 1: 'prefers-reduced-motion' CSS Media Query
+
Users can indicate their motion preference for interfaces in their system and the
+ 'prefers-reduced-motion' CSS Media Query will respect that choice. CSS can then be
+ applied to disable that motion for users that request it.
+
+@media (prefers-reduced-motion: reduce) {
+ /* CSS to disable motion goes here */
+}
For each interactive element that moves due to a user interaction:
+
+
+
Enable the 'Reduce Motion' setting in your system;
+
+
Check that the motion is not essential;
+
+
Check that the element does not move.
+
+
+
+
+
Expected Results
+
+
+
#2 and #3 are true.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C40.html b/wcag21/techniques/css/C40.html
new file mode 100644
index 0000000..6b907aa
--- /dev/null
+++ b/wcag21/techniques/css/C40.html
@@ -0,0 +1,152 @@
+
+
+
+
+ C40: Creating a two-color focus indicator to ensure sufficient contrast with all components
+
+
+
+
+
+
+
+
Creating a two-color focus indicator to ensure sufficient contrast with all components
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to create a two-color focus indicator that has
+ sufficient contrast against any background color. This technique eliminates the need
+ for multiple classes to ensure sufficient contrast of the focus indicator when viewed
+ against different backgrounds.
+
+
The default focus indicators provided by browsers are typically one color, so they
+ are highly visible when some components have focus and not well seen on other components.
+ For instance, if a focus indicator is dark blue and a button is on a white background
+ then it will be easily seen, but if the background is also blue it will not be easily
+ seen.
+
+
Although it is possible to create individual CSS classes to address the different
+ buttons across a site, this can be time consuming and easy to miss some types of interactive
+ content. However, if the focus indicator is two colors - a light color and a dark
+ color - then it will always have sufficient contrast against any background color.
+ Currently, this can be done by combining the text-shadow property with the outline property on the focus indicator.
+
+
Developers may apply this technique to parts of the site where its hard to keep track
+ of the focus indicator (such as when there are lots of different component colors).
+ Developers can also provide a single-color focus indicator for components such as
+ a navigation menus that are used across a site, have specific design requirements,
+ and are easy to test and maintain.
+
+
+
Note
+
If it can be determined that the two-color focus indicator CSS takes precedence then
+ the test can be applied programmatically rather than by manually focusing on each
+ interface component.
+
+
+
+
+
Examples
+
The examples demonstrate a simple implementation where focus styles are applied to
+ all links and inputs. In use on a more complex website care would need to be taken
+ that these styles are not overridden by more specific styles.
+
Check that the two-colors in the focus indicator are adjacent and have a contrast
+ ratio that is 3:1 or greater with each other.
+
+
+
+
+
+
Expected Results
+
+
+
#1 is true.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C6.html b/wcag21/techniques/css/C6.html
new file mode 100644
index 0000000..40e787d
--- /dev/null
+++ b/wcag21/techniques/css/C6.html
@@ -0,0 +1,193 @@
+
+
+
+
+ C6: Positioning content based on structural markup
+
+
+
+
+
+
+
+
Positioning content based on structural markup
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how visual appearance may be enhanced
+ via style sheets while still maintaining a meaningful presentation when style sheets
+ are not applied. Using the positioning properties of CSS2, content may be displayed
+ at any position on the user's viewport. Using structural elements ensures that the
+ meaning of the content can still be determined when styling is not available.
+
+
+
+
Examples
+
+
Example 1
+
In this example structural markup (definition lists) have been applied to the content.
+ CSS has been used to style the content into columnar form. Each class absolutely positions
+ the content into columns and the margins have been set to 0 to override the default
+ behavior of user agents to display HTML definition lists with the DD element indented.
+
+
When style sheets are applied, the data are displayed in two columns of "Products"
+ and "Locations." When the style sheets are not applied, the text appears in a definition
+ list which maintains the structure and reading order.
+
Remove the style information from the document or turn off use of style sheets in
+ the user agent.
+
+
+
Check that the structural relations and the meaning of the content are preserved.
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C7.html b/wcag21/techniques/css/C7.html
new file mode 100644
index 0000000..fc035be
--- /dev/null
+++ b/wcag21/techniques/css/C7.html
@@ -0,0 +1,182 @@
+
+
+
+
+ C7: Using CSS to hide a portion of the link text
+
+
+
+
+
+
+
+
Using CSS to hide a portion of the link text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to supplement the link text by adding additional
+ text that describes the unique function of the link and styling the additional text
+ so that it is not rendered on the screen by user agents that support CSS. When information
+ in the surrounding context is needed to interpret the displayed link text, this technique
+ provides a complete description of the link's input function while permitting the
+ less complete text to be displayed.
+
+
This technique works by creating a CSS selector to target text that is to be hidden.
+ The rule set for the selector places the text to be hidden in a 1-pixel box with overflow
+ hidden. This ensures the text does not display on screen but remains accessible to
+ assistive technologies such as screen readers and braille displays. Note that the
+ technique does not use visibility:hidden or display:none properties, since these can
+ have the unintentional effect of hiding the text from assistive technology in addition
+ to preventing on-screen display.
+
+
This technique is not a method for hiding complete links, only a section of text within a link. The resources below include methods for hiding and showing links aimed at screenreader users.
+
+
+
Note
+
+
+
This technique to hide link text has been advocated by some screen reader users and
+ corporate Web authors. It has proved effective on some Web sites. Other screen reader
+ users and accessibility experts don't recommend this as a general technique because
+ the results can be overly chatty and constrain the ability of the experienced screen
+ reader user to control the verbosity. The working group believes the technique can
+ be useful for Web pages that do not have repetitive content in the hidden text areas.
+
This example describes a news site that has a series of short synopsis of stories
+ followed by a link that says "full story". Hidden link text describes the purpose
+ of the link.
+
+<p>Washington has announced plans to stimulate economic growth.
+ <a href="#"><span class="visually-hidden">Washington stimulates economic growth </span>
+ Full Story</a></p>
+
+
Example 2
+
This example describes a resource that has electronic books in different formats.
+ The title of each book is followed by links that say "HTML" and "PDF." Hidden text
+ describes the purpose of each link.
+
<dl>
+<dt>Winnie the Pooh </dt>
+ <dd><a href="winnie_the_pooh.html">
+ <span class="visually-hidden">Winnie the Pooh </span>HTML</a></dd>
+ <dd><a href="winnie_the_pooh.pdf">
+ <span class="visually-hidden">Winnie the Pooh </span>PDF</a></dd>
+<dt>War and Peace</dt>
+ <dd><a href="war_and_peace.html">
+ <span class="visually-hidden">War and Peace </span>HTML</a></dd>
+ <dd><a href="war_and_peace.pdf">
+ <span class="visually-hidden">War and Peace </span>PDF</a></dd>
+</dl>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that an element has been defined that confines its display to a pixel and hides
+ the text
+
+
+
Check that the element of that class is included in the content of the anchor
+
+
Check that the combined content of the anchor describes the purpose of the link
+
+
+
+
+
+
Expected Results
+
+
+
+
All checks above are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C8.html b/wcag21/techniques/css/C8.html
new file mode 100644
index 0000000..b55596e
--- /dev/null
+++ b/wcag21/techniques/css/C8.html
@@ -0,0 +1,132 @@
+
+
+
+
+ C8: Using CSS letter-spacing to control spacing within a word
+
+
+
+
+
+
+
+
Using CSS letter-spacing to control spacing within a word
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to demonstrate how the visual appearance of spacing
+ in text may be enhanced via style sheets while still maintaining meaningful text sequencing.
+ The CSS letter-spacing property helps developers control the amount of white space
+ between characters. This is recommended over adding blank characters to control the
+ spacing, since the blank characters can change the meaning and pronunciation of the
+ word.
+
+
+
+
Examples
+
+
Example 1: Separating characters in a word
+
The following CSS would add the equivalent of a space between each character in a
+ level-2 heading:
+
h2 { letter-spacing: 1em; }
So for the markup:
+<h2>Museum</h2>
+
the rendered result might look something like:
+M u s e u m
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
For each word that appears to have non-standard spacing between characters:
+
+
+
+
+
+
Check whether the CSS letter-spacing property was used to control spacing.
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/C9.html b/wcag21/techniques/css/C9.html
new file mode 100644
index 0000000..e87d2b9
--- /dev/null
+++ b/wcag21/techniques/css/C9.html
@@ -0,0 +1,194 @@
+
+
+
+
+ C9: Using CSS to include decorative images
+
+
+
+
+
+
+
+
Using CSS to include decorative images
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Any technology that can use CSS to include images.
The objective of this technique is to provide a mechanism to add purely
+ decorative images and images used for visual formatting to Web content
+ without requiring additional markup within the content. This makes it
+ possible for assistive technologies to ignore the non-text content. Some
+ user agents can ignore or turn off CSS at the user's request, so that
+ background images included with CSS simply "disappear" and do not interfere
+ with display settings such as enlarged fonts or high contrast settings.
+
+
Background images can be included with the following CSS properties:
+
+
+
+ background,
+
+
+
+ background-image,
+
+
+
+ content, combined with the :before and
+ :after pseudo-elements,
+
+
+
+ list-style-image.
+
+
+
+
Note: This technique is not appropriate for any image that conveys
+ information or provides functionality, or for any image primarily intended
+ to create a specific sensory experience.
+
+
+
+
Examples
+
+
Example 1: Background image for an HTML page
+
The stylesheet for a Web page specifies a background image for the
+ whole page.
+
Example 2: Background image with CSS for image rollovers
+
The stylesheet for a Web page uses the CSS background
+ property to create a decorative rollover effects when a user hovers
+ the mouse pointer over a link.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/css/reflow-url.html b/wcag21/techniques/css/reflow-url.html
new file mode 100644
index 0000000..2d7a4f4
--- /dev/null
+++ b/wcag21/techniques/css/reflow-url.html
@@ -0,0 +1,128 @@
+
+
+
+
+
+ reflow-url: Allowing for Reflow with Long URLs and Strings of Text
+
+
+
+
+
+
+
+
Allowing for Reflow with Long URLs and Strings of Text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
Long sets of characters without a space, such as URLs shown as content, can break
+ reflow when the page is zoomed. The objective of this technique is to present URLs
+ without introducing a horizontal scroll bar at a width equivalent to 320 CSS pixels
+ or a vertical scroll bar at a height equivalent to 256 CSS pixels. This is done by
+ using CSS techniques that adapt to the available viewport space. Note: Using a human
+ readable text link, rather than a long URL, is better for usability and accessibility.
+
+
By default most browsers will wrap long URLs at the following characters:
+
+
+
"-" Hyphen
+
+
" " Space
+
+
"?" Question (IE, Chrome, Safari)
+
+
"&" Ampersand (Firefox only)
+
+
+
Sometimes these are not enough to ensure that long URLs will not overflow the viewport.
+
+
+
Examples
+
+
Example 1: Example: Breaking long URLs
+
Using the following CSS will cause long URLs to break at appropriate places (hyphens,
+ spaces, etc.) and within words without causing reflow.
+
+
List of CSS declarations used and why they are used:
+
+
+
overflow-wrap: break-word: Allows words to be broken and wrapped within words.
+
+
+
word-wrap: break-word: Allows words to be broken and wrapped within. (Microsoft only)
+
+
+
a {overflow-wrap: break-word;}
Note: IE and Edge only support this declaration when used with the * (wildcard)
+ selector
+
For strings of text that are wider than 320px check:
+
+
+
Display the web page in a user agent capable of 400% zoom and set the viewport dimensions
+ (in CSS pixels) to 1280 wide and 1024 high.
+
+
+
Zoom in by 400%.
+
+
For content read horizontally, check that all content and functionality is available
+ without horizontal scrolling.
+
+
+
For content read vertically, check that all content and functionality is available
+ without vertical scrolling.
+
+
+
+
+
Note
+
If the browser is not capable of zooming to 400%, you can reduce the width of the
+ browser proportionally. For example, at 300% zoom the viewport should be sized to
+ 960px wide.
+
+
+
+
+
Expected Results
+
Checks #3 and #4 are true.
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/413 Failure.html b/wcag21/techniques/failures/413 Failure.html
new file mode 100644
index 0000000..5b49d93
--- /dev/null
+++ b/wcag21/techniques/failures/413 Failure.html
@@ -0,0 +1,158 @@
+
+
+
+
+ 413 Failure: Failure of Success Criterion 4.1.3 due to providing status messages that cannot be
+ programmatically determined through role or properties
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.3 due to providing status messages that cannot be
+ programmatically determined through role or properties
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
The objective of this technique is to describe a failure where status messages are
+ used in content but are not communicated to the user due to a lack of appropriate
+ roles or properties.
+
+
The initial step in confirming a failure of Status Messages is to check that new dynamic
+ content meets the definition of a status message. There are two criteria that determine
+ if changed content on a page represents a status message:
+
+
+
+
the new content does not take focus (does not change context);
+
+
the new content provides information to the user on the outcome of an action, the
+ state of an application, the progress of a process, or the existence of errors.
+
+
+
+ Where updated content does not conform to the definition of status message, a failure of 4.1.3 has not taken place.
+
+
The second step in this failure technique involves examining code. Where dynamic
+ content meets the definition of a status message, its container can be examined for
+ an appropriate WAI-ARIA role or property which allows it to be programmatically determinable
+ as a status message. Currently there are only a small number of techniques available
+ to indicate status messages to assistive technologies. They are:
+
+
+
+
role="status"
+
+
role="alert"
+
+
the use of an aria-live attribute on an element, set to either "polite" or "assertive"
+
+
+
role="log"
+
+
role="progressbar"
+
+
+ The absence of all of these techniques predicts a failure for the status message
+ be announced to the user. Additionally, if the role or property is not set before the dynamic content is added, this also predicts a failure.
+
+
Since additional techniques may exist to alert an assistive technology, the final
+ step of this failure technique is confirming whether an assistive technology (such
+ as a screen reader) detects the dynamic content and exposes the information to users.
+ Where a status message exists but is not surfaced by assistive technology, it is confirmation
+ that a failure has taken place.
+
+
+
+
Examples
+
+
Example 1: Including a search results message without a status role
+
When a user carries out a search by pressing a Search button, the page content is
+ updated with the results of the search, displayed in a section below the Search button.
+ Since the search has no results, the change to content conveys the status message
+ "0 results returned". This text is not given an appropriate role for a status message,
+ and so a screen reader will not announce "Zero results returned" unless the user repositions
+ to that text. Since the status message is not automatically presented to the user
+ (i.e., instead, it must be manually discovered by the individual), it fails 4.1.3.
+
For content that is dynamically added to the page:
+
+
+
Check that the element containing the updated content does not take focus
+
+
Check that the new content provides information to the user on one of the following:
+
+
+
+
the success or result of an action
+
+
the waiting state of an application
+
+
the progress of a process
+
+
the existence of errors
+
+
+
+
Check that the element containing the new content does not have a pre-existing aria
+ role of status, alert, log, or progressbar, or an aria-live attribute
+
+
+
Check that the status message is not surfaced (i.e., announced) by assistive technology
+
+
+
+
+
Expected Results
+
+
+
If #1 through #4 are all true, then content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F1.html b/wcag21/techniques/failures/F1.html
new file mode 100644
index 0000000..232a326
--- /dev/null
+++ b/wcag21/techniques/failures/F1.html
@@ -0,0 +1,216 @@
+
+
+
+
+ F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by
+ positioning information with CSS
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.2 due to changing the meaning of content by
+ positioning information with CSS
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes the failure condition that results when CSS, rather than
+ structural markup, is used to modify the visual layout of the content, and
+ the modified layout changes the meaning of the content. Using the
+ positioning properties of CSS2, content may be displayed at any position on
+ the user's viewport. The order in which items appear on a screen may be
+ different than the order they are found in the source document. Assistive
+ technologies rely on the source code or other programmatically determined
+ order to render the content in the correct sequence. Thus, it is important
+ not to rely on CSS to visually position content in a specific sequence if this sequence
+ results in a meaning that is different from the programmatically determined reading
+ order.
+
+
+
+
+
Examples
+
+
Example 1
+
The following example demonstrates how CSS has been improperly used
+ to create a set of columns. In addition, the text appears visually
+ in the browser in a different order than in the markup.
+
+
In this example a class is defined for each object that is being
+ positioned. When style sheets are applied, the text appears in two
+ columns. Elements of class "menu1" (Products) and "menu2"
+ (Locations) appear as column headings. "Telephones, Computers, and
+ Portable MP3 Players" are listed under Products and "Idaho" and
+ "Wisconsin" are listed under Locations (note the different order for
+ Idaho and Wisconsin in the source code order).
+
+
Since appropriate structural elements have not been used, when style
+ sheets are not applied, all of the text appears in one line in the
+ source order, "Products Locations Telephones Computers Portable MP3
+ Players Wisconsin Idaho."
+
Remove the style information from the document or turn off use of
+ style sheets in the user agent.
+
+
+
Check that the reading order of the content is correct and the
+ meaning of the content is preserved.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is false, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F10.html b/wcag21/techniques/failures/F10.html
new file mode 100644
index 0000000..d24e84f
--- /dev/null
+++ b/wcag21/techniques/failures/F10.html
@@ -0,0 +1,124 @@
+
+
+
+
+ F10: Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining
+ multiple content formats in a way
+ that traps users inside one format type
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining
+ multiple content formats in a way
+ that traps users inside one format type
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Applies when content creates a situation where the user can enter the content
+ using the keyboard, but cannot exit the content using the keyboard.
+
When content includes multiple formats, one or more user agents or plug-ins
+ are often needed in order to successfully present the content to users. For
+ example, a page that includes XHTML, SVG, SMIL and XForms may require a
+ browser to load as many as three different plug-ins in order for a user to
+ successfully interact with the content. Some plug-ins create a common
+ situation in which the keyboard focus can become "stuck" in a
+ plug-in, leaving a keyboard-only user with no way to return to the
+ other content.
+
+
+
+
Examples
+
+
+
+ A plug-in traps the user A user tabs into a
+ plug-in and is unable to return to content outside the plug-in
+ content with the keyboard. The user has to restart their browser in
+ order to regain control and navigate to a new page and is unable to
+ access any content that appears beyond the plug-in content.
+
Check to see that the keyboard focus is not "trapped" and it is
+ possible to move keyboard focus out of the plug-in content
+ without closing the user agent or restarting the system.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If the keyboard focus becomes "trapped," then this failure
+ condition applies and content fails the Success Criterion and conformance requirement
+ 5.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F100.html b/wcag21/techniques/failures/F100.html
new file mode 100644
index 0000000..43ef8d9
--- /dev/null
+++ b/wcag21/techniques/failures/F100.html
@@ -0,0 +1,141 @@
+
+
+
+
+ F100: Failure of Success Criterion 1.3.4 due to showing a message asking to reorient device
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.4 due to showing a message asking to reorient device
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique is applicable to Cascading Style Sheet / HTML technologies.
This describes the failure condition that results when an author, having detected
+ a device orientation that is considered undesirable, displays a message telling the
+ user to reorient the device -- instead of the author reorienting all the content.
+
+
Detecting and responding to a user's device orientation is not itself a problem. The
+ author decision to only offer one orientation of content is what fails the requirements
+ of Success Criterion (SC) 1.3.4 Orientation. It is inadequate to display only a message
+ in the detected orientation, telling users to rotate their devices (when not essential
+ to the underlying activity). The entirety of the author-controlled content needs to
+ be re-oriented in order to meet the SC.
+
+
There are various methods for devices to determine if the content is in landscape
+ or portrait orientation. One of these methods involves looking at the width-to-height
+ aspect ratio of the viewport. In other words, checking if the width is smaller or
+ larger than the height. The CSS orientation media feature is portrait when the value of the height media feature is greater than or equal to the value of the width media feature. Otherwise, orientation is landscape.
+
+
+
+
Examples
+
+
Example 1: Block an orientation ("door slam") by using HTML and CSS
+
The following example uses HTML and CSS to show a message asking to reorient the device
+ if in landscape.
+
+
The message will disappear if the orientation is changed to portrait.
+
+ When the portrait property matches the viewport space defined via media queries, the message will disappear
+ or vice versa. This particular example uses the CSS landscape, portrait media query properties.
+
Open the content in landscape view. Check if a message appears asking to reorient
+ the device.
+
+
+
Open the content in portrait view. Check if a message appears asking to reorient the
+ device.
+
+
+
Check if portrait or landscape view is essential for the viewing and operation of
+ the content.
+
+
+
+
+
+
Expected Results
+
If check #1 or #2 is true, and check #3 is false, then this failure condition applies
+ and content fails the Success Criterion.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F101.html b/wcag21/techniques/failures/F101.html
new file mode 100644
index 0000000..de7d7cf
--- /dev/null
+++ b/wcag21/techniques/failures/F101.html
@@ -0,0 +1,145 @@
+
+
+
+
+ F101: Failure of Success Criterion 2.5.2 due to activating a control on the down-event
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.5.2 due to activating a control on the down-event
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that include interactive controls that can be triggered using a pointer.
The objective of this Failure is to describe situations where:
+
+
+
Controls are set to activate functionality on the down-event of a pointer;
+
+
No further mechanism to abort or undo is available;
+
+
The up-event does not reverse the outcome of the activation;
+
+
It is not essential for the functionality to execute and complete on the down-event.
+
+
+
Rather than taking advantage of the click event, authors may use down-events such as mousedown, touchstart or pointerdown. As a result, functionality will be executed as soon as a mouse button is pressed
+ (but not released yet), or a finger or stylus makes contact with a touchscreen.
+
+
It is possible to use the down event and mitigate potential issues to avoid failing
+ the Success Criterion. For example, provide a method to easily undo or abort the functionality,
+ or reverse the outcome on the up-event (when the mouse button is released, or when
+ the finger or stylus are lifted from the touchscreen). And note that some uses of
+ the down-event are essential for the functionality (e.g., where the control simulates
+ the operation of a musical instrument like a set of piano keys, or when the control
+ is used as an on-screen control for a game where a fast and immediate response is
+ required), in which case they would not fail this Success Criterion.
+
+
+
Note
+
The test procedure outlined below could be supplemented with automated or semi-automated
+ tests to scan for JavaScript that registers event listeners such as mousedown, touchstart, or pointerdown. The automated test would not be sufficient to make a pass/fail determination, but
+ it can help narrow down the number of potentially problematic controls.
+
+
+
+
+
Examples
+
+
Example 1: A close button that triggers on down-events
+
A modal dialog contains a lengthy form that a user needs to complete. The modal provides
+ a simple "Close" control that closes the dialog and loses all information the user
+ may already have entered in the form. However, instead of simply listening to the
+ click event - which in most user agents is triggered on the up-event - the author decided
+ to close the dialog on the down-event. This may lead to the user accidentally closing
+ the dialog and losing all the data they entered into the form up to that point.
+
Open the content on a device with pointer inputs (mouse, touchscreen, stylus) and
+ for all available controls (buttons, links, complex widgets):
+
+
+
+
Trigger down-events (e.g. by pressing but not releasing the mouse button, or placing
+ a finger or stylus on the touchscreen) and check if functionality is executed prior
+ to the up-event (e.g. releasing the mouse button or lifting the finger/stylus)
+
+
+
If functionality was executed on the down-event, check if triggering the up-event
+ (releasing the pressed mouse button, or lifing the finger or stylus from the touchscreen)
+ reverses the outcome
+
+
+
Evaluate if it could be deemed essential for the controls to execute and complete
+ functionality on the down-event
+
+
+
+
+
+
Expected Results
+
+
+
If #1 is true, and #2 and #3 are false then the content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F102.html b/wcag21/techniques/failures/F102.html
new file mode 100644
index 0000000..4cb8761
--- /dev/null
+++ b/wcag21/techniques/failures/F102.html
@@ -0,0 +1,130 @@
+
+
+
+
+ F102: Failure of Success Criterion 1.4.10 due to content disappearing and not being available
+ when content has reflowed
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.10 due to content disappearing and not being available
+ when content has reflowed
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when a change of the viewport width
+ to 320px makes content disappear that was available at wider viewport widths. Some
+ content available at wider widths may not be shown in the same way or at the same
+ position at the viewport width of 320px, simply because there is less space (screen
+ 'real estate') to display it. This content, however, should still be available after
+ reflow to 320px viewport width, either by being repositioned in a single column view,
+ or through some interaction offering the information in some other way, for example,
+ in a disclosure area, a dialog, or via a link to another view.
+
+
+
+
Examples
+
The following examples demonstrate the failure to make content visible at a wider
+ viewport width also available after a reflow to 320px:
+
+
+
+
A block of blog entry links in a side column disappears entirely after reflow (i.e.,
+ it is not available further down in the single column view).
+
+
+
Labels above text inputs are hidden and replaced by placeholder text after reflow,
+ without a technique showing dedicated labels when focusing the fields.
+
+
+
Sections of content text disappear after reflow, without being available via some
+ disclosure widget.
+
+
+
Information-carrying images disappear after reflow, without link or the availability
+ of an equivalent alternative.
+
+
+
A global search field disappears after reflow, without an icon or menu option to reveal
+ a search function or reach an equivalent search page.
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
Check visible content elements at a desktop viewport width such as 1280px
+
+
Set the viewport width to 320px by narrowing the browser window, or by zooming in
+ so that the viewport width is now 320px (when starting with a 1280px viewport width
+ at 100% browser zoom, this can be done by zooming in to 400%)
+
+
+
For each content element that is not provided at the viewport width of 320px, check
+ that there is a way to reach the same or equivalent content via discolure widgets,
+ pop-ups, or links to other views
+
+
+
+
+
+
Expected Results
+
+
+
If #3 is false, then this failure condition applies and the content fails this Success
+ Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F103.html b/wcag21/techniques/failures/F103.html
new file mode 100644
index 0000000..3c5a1e2
--- /dev/null
+++ b/wcag21/techniques/failures/F103.html
@@ -0,0 +1,159 @@
+
+
+
+
+ F103: Failure of Success Criterion 4.1.3 due to providing status messages that cannot be
+ programmatically determined through role or properties
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.3 due to providing status messages that cannot be
+ programmatically determined through role or properties
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe a failure where status messages are
+ used in content but are not communicated to the user due to a lack of appropriate
+ roles or properties.
+
+
The initial step in confirming a failure of Status Messages is to check that new dynamic
+ content meets the definition of a status message. There are two criteria that determine
+ if changed content on a page represents a status message:
+
+
+
+
the new content does not take focus (does not change context);
+
+
the new content provides information to the user on the outcome of an action, the
+ state of an application, the progress of a process, or the existence of errors.
+
+
+
+ Where updated content does not conform to the definition of status message, a failure of 4.1.3 has not taken place.
+
+
The second step in this failure technique involves examining code. Where dynamic
+ content meets the definition of a status message, its container can be examined for
+ an appropriate WAI-ARIA role or property which allows it to be programmatically determinable
+ as a status message. Currently there are only a small number of techniques available
+ to indicate status messages to assistive technologies. They are:
+
+
+
+
role="status"
+
+
role="alert"
+
+
the use of an aria-live attribute on an element, set to either "polite" or "assertive"
+
+
+
role="log"
+
+
role="progressbar"
+
+
+ The absence of all of these techniques predicts a failure for the status message
+ be announced to the user. Additionally, if the role or property is not set before the dynamic content is added, this also predicts a failure.
+
+
Since additional techniques may exist to alert an assistive technology, the final
+ step of this failure technique is confirming whether an assistive technology (such
+ as a screen reader) detects the dynamic content and exposes the information to users.
+ Where a status message exists but is not surfaced by assistive technology, it is confirmation
+ that a failure has taken place.
+
+
+
+
Examples
+
+
Example 1: Including a search results message without a status role
+
When a user carries out a search by pressing a Search button, the page content is
+ updated with the results of the search, displayed in a section below the Search button.
+ Since the search has no results, the change to content conveys the status message
+ "0 results returned". This text is not given an appropriate role for a status message,
+ and so a screen reader will not announce "Zero results returned" unless the user repositions
+ to that text. Since the status message is not automatically presented to the user
+ (i.e., instead, it must be manually discovered by the individual), it fails 4.1.3.
+
For content that is dynamically added to the page:
+
+
+
Check that the element containing the updated content does not take focus
+
+
Check that the new content provides information to the user on one of the following:
+
+
+
+
the success or result of an action
+
+
the waiting state of an application
+
+
the progress of a process
+
+
the existence of errors
+
+
+
+
Check that the element containing the new content does not have a pre-existing aria
+ role of status, alert, log, or progressbar, or an aria-live attribute
+
+
+
Check that the status message is not surfaced (i.e., announced) by assistive technology
+
+
+
+
+
Expected Results
+
+
+
If #1 through #4 are all true, then content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F104.html b/wcag21/techniques/failures/F104.html
new file mode 100644
index 0000000..59b8c3a
--- /dev/null
+++ b/wcag21/techniques/failures/F104.html
@@ -0,0 +1,206 @@
+
+
+
+
+ F104: Failure of Success Criterion 1.4.12 due to clipped or overlapped content when text
+ spacing is adjusted
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.12 due to clipped or overlapped content when text
+ spacing is adjusted
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This techniques applies to text content created in markup languages that support text
+ style properties.
+
The purpose of this technique is to identify and test a failure condition where part
+ of the content clips and is unreadable when the user overrides the spacing of the
+ text within the boundaries set out in the Text Spacing success criterion. In general,
+ this failure occurs when text is presented in a size-constrained block which does
+ not expand if the size of the content increases. Some of the ways in which this can
+ occur include:
+
+
+
+
+ Setting the overflow property of the enclosing element to hidden
+
+
+
+
+ Using absolutely positioned content
+
+
+
+
+ Creating borders that are not large enough for the content when using the new
+ font spacing
+
+
+
+
+
+
+
Examples
+
+
Example 1: Text inside a box overflows and overlaps text below it when text spacing
+ is implemented.
+
+
The code below is what is implemented in the DOM before the user implements any CSS test spacing overrides. The text renders correctly in
+ the box and doesn't interfere with the next paragraph.
+
+
<div style="font-size:100%; width:130px; height:95px; border: thin solid gray;">
+ Now is the time for all good men to come to the aid of their country.
+ </div>
+ <p>Now is the time for all good men to come to the aid of their country.</p>
+
+
+ Now is the time for all good men to come to the aid of their country.
+
+
+
+
Now is the time for all good men to come to the aid of their country.
+
Here is the view AFTER the text spacing has been overridden by the user with the
+ text spacing in the success criteria. The text overlaps the paragraph below it.
+
+
+
+ Now is the time for all good men to come to the aid of their country.
+
+
+
+
Now is the time for all good men to come to the aid of their country.
+
+
+
Example 2: Text inside a box is clipped when text spacing is implemented.
+
The code below is what is implemented in the DOM before the user implements any CSS test spacing overrides. The text renders correctly in
+ the box and doesn't interfere with the next paragraph.
+
+
<div style="font-size:100%; width:130px; height:95px; overflow: hidden; border: thin
+ solid gray;"> Now is the time for all good men to come to the aid of their country.
+ </div> <p>Now is the time for all good men to come to the aid of their country.</p>
+
Here is the default view before the text spacing has been overridden by the user,
+ The text renders properly in the box
+
+
+
+ Now is the time for all good men to come to the aid of their country.
+
+
+
+
Now is the time for all good men to come to the aid of their country.
+
Here is the view AFTER the text spacing has been overridden by the user with the
+ maximum text spacing in the success criteria, the text is clipped.
+
+
+
+ Now is the time for all good men to come to the aid of their country.
+
+
+
+
Now is the time for all good men to come to the aid of their country.
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Override the CSS on the page using a user stylesheet, bookmarklet, extension, or application
+ with the values listed in the success criteria:
+
+
+
+
Line height to at least 1.5 times the font size;
+
+
Spacing following paragraphs to at least 2 times the font size;
+
+
Letter spacing (tracking) to at least 0.12 times the font size;
+
+
Word spacing to 0.16 times the font size.
+
+
+
+
+
+
Check if any content is clipped, obscured, or lost due to the new text spacing.
+
+
+
+
+
Expected Results
+
+
+
If check #3 is true, then the failure condition applies and the content fails the
+ Success Criterion
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F105.html b/wcag21/techniques/failures/F105.html
new file mode 100644
index 0000000..0cda0d6
--- /dev/null
+++ b/wcag21/techniques/failures/F105.html
@@ -0,0 +1,135 @@
+
+
+
+
+ F105: Failure of Success Criterion 2.5.1 due to providing functionality via a path-based
+ gesture without simple pointer alternative
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.5.1 due to providing functionality via a path-based
+ gesture without simple pointer alternative
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that include interactive controls that can be triggered using a pointer.
+ This technique relates to Success Criterion 2.5.1: Pointer Gestures.
+
The objective of this Failure is to describe situations where authors have implemented
+ a function that is operated via a path-based gesture, and no alternative ways of operating
+ this function via simple pointer gestures exist.
+
+
If you did not create the content and functionality you can find path-based gestures
+ by exploring the content on a touch screen, or checking the page code for the existence
+ of specific event handlers such as touchstart or touchend. See the Understanding document for Pointer Gestures for more on the path-based gestures.
+
+
Note: For functionality implemented with a path-based gesture, the possibility of also
+ operating it via the keyboard is beneficial (and may serve to meet Success Criterion
+ 2.1.1 Keyboard). The point of Success Crtierion 2.5.1, however, is to ensure that
+ pointer users who on many devices will have no keyboard available, have alternative
+ ways of operating the function via simple pointer input.
+
+
+
+
Examples
+
+
Example 1
+
+
+
A web application implements an interface where drawing a "Z" on the screen undoes
+ the last action. There is no other way to undo the action.
+
+
+
A swipe-to-reveal control displays a set of options when swiping an item to the left,
+ and another set of options when swiping an item to the right. One or more of these
+ options are not available after the item is first opened with a single tap or click.
+
+
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
For each part of the content that implements a function that can be activated by a
+ path-based gesture:
+
+
+
+
Check that controls are available through which the same function can be carried out
+ via simple taps or clicks.
+
+
+
+
+
+
Expected Results
+
+
+
If check #1 is false then the content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F106.html b/wcag21/techniques/failures/F106.html
new file mode 100644
index 0000000..88854c5
--- /dev/null
+++ b/wcag21/techniques/failures/F106.html
@@ -0,0 +1,109 @@
+
+
+
+
+ F106: Failure due to inability to deactivate motion actuation
+
+
+
+
+
+
+
+
Failure due to inability to deactivate motion actuation
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Content using technologies that can support the detection of device or user motion
+ such as shaking or tilting and use these motions as a means of input.
+
This describes the failure condition that results when motion actuation can not be
+ deactivated. People who may accidentally activate sensors due to tremors or other
+ motor impairments need the ability to turn off motion actuation to prevent such accidental
+ triggering of functions.
+
+
+
Note
+
The type of motion covered by the Motion Actuation Success Criterion does not relate to the movement of users through space as registered by geolocation
+ sensors or beacons, or events observed by the device other than intentional gesturing
+ by the user. It also does not cover indirect motion associated with operating a keyboard,
+ pointer, or assistive technology.
+
+
+
+
+
Examples
+
+
Example 1: Motion Activated Slider
+
A slider which uses tilting motion to increase or decrease the value of an input,
+ with no mechanism to deactivate the motion detection.
+
For each function that is triggered by a motion sensor:
+
+
+
Check if the use of a motion sensor is essential or required to make the function
+ accessibility supported.
+
+
+
Check if there is a user setting which disables the motion detection.
+
+
+
+
+
Expected Results
+
+
+
If #1 and 2 are false then the control fails this success criteria.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F107.html b/wcag21/techniques/failures/F107.html
new file mode 100644
index 0000000..5a52be8
--- /dev/null
+++ b/wcag21/techniques/failures/F107.html
@@ -0,0 +1,129 @@
+
+
+
+
+ F107: Failure of Success Criterion 1.3.5 due to incorrect autocomplete attribute values
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.5 due to incorrect autocomplete attribute values
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This technique applies to form inputs created in HTML which collect information about the user of the form.
+
The purpose of this technique is to identify a failure condition where form inputs
+ do not have the correct autocomplete attribute values for inputs that request information
+ about the user of the form.
+
+
Success Criteria 1.3.5 uses a fixed list of tokens in Input Purposes for User Interface Components (based on the HTML 5.2 autocomplete attribute’s fixed list of token values) because the programmatic association of specified
+ token values (metadata) allows for other machine processing, such as expressing the
+ input label in different modalities.
+
+
Another important part of this Success Criterion is that the token values are associated
+ with inputs that are scoped directly to the primary end user.
+
+
+
+
Examples
+
+
Example 1: Incorrect attribute
+
An online form used to collect the user's name and birthday which uses incorrect autocomplete
+ attributes. The correct attribute value for the first control is name and for the second control the made-up attribute value birthday was used instead of bday for this example.
+
For each form field which collects information about the user of the form:
+
+
+
Check that the form field has an autocomplete attribute and value pair that does not
+ match the purpose of the input.
+
+
+
Check that the input purpose is not communicated programmatically through any other
+ method.
+
+
+
+
+
+
Expected Results
+
+
+
If checks #1-2 are true, then the failure condition applies, and the content fails
+ the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F12.html b/wcag21/techniques/failures/F12.html
new file mode 100644
index 0000000..2755d7a
--- /dev/null
+++ b/wcag21/techniques/failures/F12.html
@@ -0,0 +1,137 @@
+
+
+
+
+ F12: Failure of Success Criterion 2.2.5 due to having a session time limit without a mechanism
+ for saving user's input and re-establishing that information upon
+ re-authentication
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.5 due to having a session time limit without a mechanism
+ for saving user's input and re-establishing that information upon
+ re-authentication
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Sites that require user login to submit input and that terminate the session
+ after a some period of inactivity.
+
Web servers that require user authentication usually have a session mechanism
+ in which a session times out after a period of inactivity from the user.
+ This is sometimes done for security reasons, to protect users who are
+ assumed to have left their computer exposed in a state where someone could
+ do something harmful to them such as transfer bank funds or make an
+ unauthorized purchase. A user with a disability may actually still be
+ working to complete the form as it may take him or her longer to complete
+ the form than would normally be expected. Upon re-authentication, if the
+ state of the user's session is not restored, including all data that had
+ been previously entered into the form, he or she will have to start over.
+ And for these users, it is likely that the session will time out again
+ before they can complete the form. This sets up a situation where a user who
+ needs more time to complete the form can never complete it.
+
+
+
+
Examples
+
+
+
A user submits a form on an authenticated site after their login has
+ expired. On submitting the form, they are prompted to log in again,
+ and then taken to a general welcome page. The data is not processed
+ and they must try again.
+
+
+
A user submits a form on an authenticated site after their login has
+ expired. On submitting the form, they are prompted to log in again,
+ and then taken back to the page they were on just before the login,
+ which in this case contains the form they attempted to submit.
+ However, the form is not populated with the data they just entered,
+ and they must re-enter it.
+
On a site where authentication is required, user input is collected, and
+ which ends the user's session after a known period of inactivity:
+
+
+
+
+
Provide user input as required but allow the session to time out,
+ then submit the form.
+
+
+
When requested, re-authenticate with the server.
+
+
Determine if the function is performed using the previously
+ submitted data.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #3 is false, the site fails the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F13.html b/wcag21/techniques/failures/F13.html
new file mode 100644
index 0000000..caf455d
--- /dev/null
+++ b/wcag21/techniques/failures/F13.html
@@ -0,0 +1,128 @@
+
+
+
+
+ F13: Failure of Success Criterion 1.1.1 and 1.4.1 due to having a text alternative that
+ does not
+ include information that is conveyed by color differences in the image
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 and 1.4.1 due to having a text alternative that
+ does not
+ include information that is conveyed by color differences in the image
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe the failure that occurs when
+ an image uses color differences to convey information, but the text alternative for
+ the
+ image does not convey that information. This can cause problems for people
+ who are blind or colorblind because they will not be able to perceive the
+ information conveyed by the color differences.
+
+
+
+
Examples
+
+
+
A bar chart of sales data is provided as an image. The chart includes
+ yearly sales figures for four employees in the Sales Department. The
+ text alternative for the image says, "The following bar chart
+ displays the yearly sales figures for the Sales Department. Mary
+ sold 3.1 Million; Fred, 2.6 Million; Bob, 2.2 Million; and Andrew,
+ 3.4 Million. The red bars indicate sales that were below the yearly
+ quota". This text alternative fails to provide the information which
+ is conveyed by the color red in the image. The alternative should
+ indicate which people did not meet the sales quota rather than
+ relying on color.
+
For all images in the content that convey information by way of color differences:
+
+
+
+
+
+
Check that the information conveyed by color differences is not included in
+ the text alternative for the image.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true, then this failure condition applies and
+ content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F14.html b/wcag21/techniques/failures/F14.html
new file mode 100644
index 0000000..27bdc1b
--- /dev/null
+++ b/wcag21/techniques/failures/F14.html
@@ -0,0 +1,138 @@
+
+
+
+
+ F14: Failure of Success Criterion 1.3.3 due to identifying content only by its shape or
+ location
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.3 due to identifying content only by its shape or
+ location
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to show how identifying content only by
+ its visual shape or location makes content difficult to understand and operate.
+ When only visual identification or location is used, users with visual
+ disabilities may find it difficult to locate content since they cannot see
+ the screen or may perceive only a small portion of the screen at one time.
+ Also, location of content can vary if page layout varies due to variations
+ in font, window, or screen size.
+
+
+
+
Examples
+
+
+
The navigation instructions for a site state, "To go to next page,
+ press the button to the right. To go back to previous page, press
+ the button to the left."
+
+
+
A user is reading a news article in an on-line newspaper. The article
+ contains an illustration and additional links for more information.
+ Within the text of the article is a statement, "Please see sidebar
+ to the left of the illustration for links to additional
+ information." An assistive technology user would have difficulty
+ finding the illustration and the sidebar. Some alternatives would be
+ to include the list of links within the text; to provide an in-page
+ link within the text which links to the sidebar; to provide a
+ heading for the sidebar which can be used for navigation and refer
+ to the heading in the instructions.
+
+
+
A user is completing an on-line survey. There are three buttons at
+ the bottom of the survey form. The instructions state, "Press the
+ square button to exit the survey without saving, Press the triangle
+ button to save in-progress survey results. You may return later to
+ complete the survey. Press the round button to submit the survey
+ results." A screen reader user or a user unable to distinguish shapes cannot determine
+ which button is
+ square, triangular, or round. The buttons must have additional
+ information to indicate their functions or their shapes.
+
Examine the Web page for textual references to content within the
+ Web page.
+
+
+
Check that the references do not rely on only the visual shape or
+ location of the content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is false, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F15.html b/wcag21/techniques/failures/F15.html
new file mode 100644
index 0000000..207bf05
--- /dev/null
+++ b/wcag21/techniques/failures/F15.html
@@ -0,0 +1,141 @@
+
+
+
+
+ F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not
+ use an accessibility API for the technology, or do so incompletely
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.2 due to implementing custom controls that do not
+ use an accessibility API for the technology, or do so incompletely
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Applies to all technologies that support an accessibility API.
When standard controls from accessible technologies are used, they usually are programmed
+ in a way that uses and supports the accessibility API. If custom controls are created,
+ however, then it is up to the programmer to be sure that the newly created control
+ supports the accessibility API. If this is not done, then assistive technologies will
+ not be able to understand what the control is or how to operate it or may not even
+ know of its existence.
+
+
+
Note
+
+
+
For technologies that support it, WAI-ARIA can be used to expose a custom control's
+ role, name, value, states, and properties via the accessibility API for the technology.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
A music player is designed with custom controls that look like
+ musical notes that are stretched for volume, tone etc. The
+ programmer does not make the new control support the Accessibility
+ API. As a result - the controls cannot be identified or controlled
+ from AT.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Using the accessibility checker for the technology (or if
+ that is not available, inspect the code or test with an
+ assistive technology), check the controls to see if they support
+ the accessibility API.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is false, then this failure condition applies and the
+ content fails this Success Criterion
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F16.html b/wcag21/techniques/failures/F16.html
new file mode 100644
index 0000000..c90e48d
--- /dev/null
+++ b/wcag21/techniques/failures/F16.html
@@ -0,0 +1,129 @@
+
+
+
+
+ F16: Failure of Success Criterion 2.2.2 due to including scrolling content where movement
+ is not essential to the activity without also including a mechanism to pause and restart
+ the content
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.2 due to including scrolling content where movement
+ is not essential to the activity without also including a mechanism to pause and restart
+ the content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that support visual movement or scrolling.
In this failure technique, there is moving or scrolling content that cannot
+ be paused and resumed by users. In this case, some users with low vision or
+ cognitive disabilities will not be able to perceive the content.
+
+
+
+
Examples
+
+
+
A page has a scrolling news ticker without a mechanism to pause it.
+ Some users are unable to read the scrolling content.
+
Check that a mechanism is provided in the Web page or user agent
+ to pause moving or scrolling content.
+
+
+
Use the pause mechanism to pause the moving or scrolling
+ content.
+
+
+
Check that the moving or scrolling has stopped and does not
+ restart by itself.
+
+
+
Check that a mechanism is provided in the Web page or user agent
+ to restart the paused content.
+
+
+
Use the restart mechanism provided to restart the moving
+ content.
+
+
+
Check that the movement or scrolling has resumed from the point
+ where it was stopped.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1, step #3, step #4, or step #6 are false, then the content fails the success
+ criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F19.html b/wcag21/techniques/failures/F19.html
new file mode 100644
index 0000000..a79f6f5
--- /dev/null
+++ b/wcag21/techniques/failures/F19.html
@@ -0,0 +1,124 @@
+
+
+
+
+ F19: Failure of Conformance Requirement 1 due to not providing a method for the user to
+ find the alternative conforming version of a non-conforming Web page
+
+
+
+
+
+
+
+
+
Failure of Conformance Requirement 1 due to not providing a method for the user to
+ find the alternative conforming version of a non-conforming Web page
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Sites that provide alternative, WCAG-conforming versions of nonconforming
+ primary content.
+
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
This failure technique describes the situation in which an alternate, conforming
+ version of the content is provided, but there is no direct way for a user to tell
+ that it is available or where to find it. Such content fails the Success Criterion
+ because the user cannot find the conforming version.
+
+
+
+
Examples
+
+
+
A link or a search takes a user directly to one of the nonconforming
+ pages in the Web site. There is neither an indication that an
+ alternate page is available, nor a path to the alternate page from
+ the nonconforming page.
+
+
+
Nonconforming pages on the Web site inform the user that a
+ conforming version is available and provide a link to the home page.
+ However, the user must search the site for the conforming version of
+ the page, so the functionality does not meet the requirements of the
+ Success Criterion.
+
+
+
A user is able to use the nonconforming Web site for most pages. But
+ when the user is not able to access a particular page, there is no
+ way to find the conforming version of the page.
+
Identify a nonconforming page that has an alternative conforming
+ version.
+
+
+
Determine if the nonconforming page provides a link to the
+ conforming version.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is false, the content fails the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F2.html b/wcag21/techniques/failures/F2.html
new file mode 100644
index 0000000..a85f7aa
--- /dev/null
+++ b/wcag21/techniques/failures/F2.html
@@ -0,0 +1,197 @@
+
+
+
+
+ F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey
+ information without using the appropriate markup or text
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey
+ information without using the appropriate markup or text
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that support images or presentation markup.
This document describes a failure that occurs when a change in the appearance of text
+ conveys meaning without using appropriate semantic markup. This failure also applies
+ to images of text that are not enclosed in the appropriate semantic markup.
+
+
+
+
Examples
+
+
Example 1: Using CSS to style the p element to look like a heading
+
+
The author intended to make a heading but didn't want the look of the default HTML
+ heading. So they used CSS to style the P element to look like a heading and they called
+ it a heading. But they failed to use the proper HTML heading element. Therefore, the
+ Assisitive Technology could not distinguish it as a heading.
+
+ <style type="text/css">
+ .heading1{
+ font-family: Times, serif;
+ font-size:200%;
+ font-weight:bold;
+ }
+ </style>
+
+ <p class="heading1">Introduction</p>
+ <p>This introduction provides detailed information about how to use this
+ ........
+ </p>
+
+
Note
+
+
+
In this case, the proper approach would be to use CSS to style the H1 element in HTML.
+
+
+
+
+
+
+
Example 2: Images of text used as headings where the images are not marked up with
+ heading tags
+
+
Chapter1.gif is an image of the words, "Chapter One" in a Garamond font sized at 20
+ pixels. This is a failure because at a minimum the img element should be enclosed
+ within a header element. A better solution would be to eliminate the image and to
+ enclose the text within a header element which has been styled using CSS.
+
+<img src="Chapter1.gif" alt="Chapter One">
+
+<p>Once upon a time in the land of the Web.....
+</p>
+
+
+
Example 3: Using CSS to visually emphasize a phrase or word without conveying that
+ emphasis semantically
+
+
The following example fails because the information conveyed by using the CSS font-weight
+ property to change to a bold font is not conveyed through semantic markup or stated
+ explicitly in the text.
+
+<p>
+ "I said, <span class="yell">no</span>, not before dinner!",
+ was the exasperated response when Timmy asked his mother for the
+ fourth time for an ice cream cone.
+ </p>
+
Check if any images of text are used to convey structural information of the document.
+
+
Check that the proper semantic structure (e.g., HTML headings) is used with the text
+ to convey the information.
+
+
+
+
+
+
+
+
+
For styled text that conveys information:
+
+
+
+
Check if there is any styled text that conveys structural information.
+
+
Check that in addition to styling, the proper semantic structure is used with the
+ text to convey the information.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1.1 is true, then #1.2 is true.
+
+
If check #2.1 is true, then #2.2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F20.html b/wcag21/techniques/failures/F20.html
new file mode 100644
index 0000000..5571795
--- /dev/null
+++ b/wcag21/techniques/failures/F20.html
@@ -0,0 +1,121 @@
+
+
+
+
+ F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives
+ when
+ changes to non-text content occur
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives
+ when
+ changes to non-text content occur
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure condition is to address situations where the
+ non-text content is updated, but the text alternative is not updated at the
+ same time. If the text in the text alternative cannot still be used in
+ place of the non-text content without losing information or function, then
+ it fails because it is no longer a text alternative for the non-text
+ content.
+
+
+
+
Examples
+
+
+
+ Failure Example 1: A Sales chart is updated
+ to October results, but the text alternative still describes
+ September results.
+
+
+
+ Failure Example 2: Pictures on a home page
+ change daily, but text alternatives are not updated at the same
+ time.
+
+
+
+ Failure Example 3: The source attribute of
+ images on a page is updated periodically using script, but the text
+ alternatives are not updated at the same time.
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check each text alternative to see if it is describing content
+ other than the currently-displayed non-text content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true then the text alternative is not up to date with
+ current item, this failure condition applies, and content fails
+ these Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F22.html b/wcag21/techniques/failures/F22.html
new file mode 100644
index 0000000..289bbbb
--- /dev/null
+++ b/wcag21/techniques/failures/F22.html
@@ -0,0 +1,146 @@
+
+
+
+
+ F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by
+ the
+ user
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.5 due to opening windows that are not requested by
+ the
+ user
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Failure due to opening new windows when the user does not expect them. New
+ windows take the focus away from what the user is reading or doing. This is
+ fine when the user has interacted with a piece of User Interface and expects
+ to get a new window, such as an options dialogue. The failure comes when
+ pop-ups appear unexpectedly.
+
+
+
+
Examples
+
+
Example 1
+
When a user navigates to a page, a new window appears over the
+ existing user agent window, and the focus is moved to the new
+ window.
+
+
+
+
Example 2
+
A user clicks on a link, and a new window appears. The original link
+ has no associated text saying that it will open a new window.
+
+
+
+
Example 3
+
A user clicks on the body of a page and a new window appears. No
+ indication that the area that was clicked has functionality is
+ present.
+
+
+
+
Example 4
+
A user clicks on undecorated text within the page and a new window
+ appears. The page has no visible indication that the area is functional.
+
Find every actionable element, such as links and buttons, in the
+ Web page.
+
+
+
Activate each element.
+
+
Check if activating the element opens a new window.
+
+
Check if elements that open new windows have associated text
+ saying that will happen. The text can be displayed in the link,
+ or available through a hidden association such as an HTML title
+ attribute.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is true, the failure condition applies and the content
+ fails the Success Criterion
+
+
+
If step #5 is true and step #6 is false, the failure condition applies and
+ the content fails the Success Criterion
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F23.html b/wcag21/techniques/failures/F23.html
new file mode 100644
index 0000000..f55c233
--- /dev/null
+++ b/wcag21/techniques/failures/F23.html
@@ -0,0 +1,110 @@
+
+
+
+
+ F23: Failure of 1.4.2 due to playing a sound longer than 3 seconds where
+ there is no mechanism to turn it off
+
+
+
+
+
+
+
+
+
Failure of 1.4.2 due to playing a sound longer than 3 seconds where
+ there is no mechanism to turn it off
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Applies to all technologies except those for voice interaction.
This describes a failure condition for Success Criteria involving sound. If sound
+ does not
+ turn off automatically within 3 seconds and there is no way to turn the
+ sound off then Success Criterion 1.4.2 would not be met. Sounds that play over 3 seconds
+ when there is no mechanism to turn off the sound included in the content
+ would fall within this failure condition.
+
+
+
+
Examples
+
+
Example 1
+
+
+
A site that plays continuous background music
+
+
+
+
+
Example 2
+
+
+
A site with a narrator that lasts more than 3 seconds before
+ stopping, and there is no mechanism to stop it.
+
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check that there is a way in a Web page to turn off any sound that
+ plays automatically for more than three seconds.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is not true then content fails Success Criterion 1.4.2
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F24.html b/wcag21/techniques/failures/F24.html
new file mode 100644
index 0000000..376f244
--- /dev/null
+++ b/wcag21/techniques/failures/F24.html
@@ -0,0 +1,289 @@
+
+
+
+
+ F24: Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors
+ without
+ specifying background colors or vice versa
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors
+ without
+ specifying background colors or vice versa
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that allow user agents to control foreground and background
+ colors through personal stylesheets or other means.
+
Users with vision loss or cognitive, language and learning challenges often prefer
+ specific foreground and background color combinations. In some cases, individuals
+ with low vision will find it much easier to see a Web page that has white text on
+ a black background, and they may have set their user agent to present this contrast.
+ Many user agents make it possible for users to choose a preference about the foreground
+ or background colors they would like to see without overriding all author-specified
+ styles. This makes it possible for users to view pages where colors have not been
+ specified by the author in their preferred color combination.
+
+
Unless an author specifies both foreground and background colors, then they (the author)
+ can no longer guarantee that the user will get a contrast that meets the contrast
+ requirements. If, for example, the author specifies, that text should be grey, then
+ it may override the settings of the user agent and render a page that has grey text
+ (specified by the author) on a light grey background (that was set by the user in
+ their user agent). This principle also works in reverse. If the author forces the
+ background to be white, then the white background specified by the author could be
+ similar in color to the text color preference expressed by the user in their user
+ agent settings, thus rendering the page unusable to the user. Because an author can
+ not predict how a user may have configured their preferences, if the author specifies
+ a foreground text color then they should also specify a background color which has
+ sufficient contrast with the foreground and vice versa.
+
+
It is not necessary that the foreground and background colors both be defined on the
+ same CSS rule. Since CSS color properties inherit from ancestor elements, it is sufficient
+ if both foreground and background colors are defined either directly or through inheritance
+ by the time that color is applied to a given element.
+
+
+
Note
+
+
+
+ Best practice is to include all states of the text. For example, text, link text,
+ visited link text, link text with hover and keyboard focus, etc.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Specifying only background color with CSS
+
In the example below the background color is defined on the CSS
+ stylesheet, however the foreground color is not defined. Therefore,
+ the example fails the Success Criterion.
+
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
+<head>
+ <title>Setting the canvas background</title>
+ <style type="text/css">
+
+ body {background-color:white}
+ </style>
+ </head>
+ <body>
+ <p>My background is white.</p>
+ </body>
+</html>
+
+
Example 2: Specifying only foreground color with CSS
+
In the example below the foreground color is defined on the CSS
+ stylesheet, however the background color is not defined. Therefore,
+ the example fails the Success Criterion.
+
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
+<head>
+ <title>Setting the canvas foreground</title>
+ <style type="text/css">
+ body {color:white}
+ </style>
+ </head>
+
+ <body>
+ <p>My foreground is white.</p>
+ </body>
+</html>
+
+
Example 3: Specifying foreground color of link text with CSS
+
In the example below the link text (foreground) color is defined on
+ the body element. However, the background color is not defined.
+ Therefore, the example fails the Success Criterion.
+
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "https://www.w3.org/TR/html4/strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
+<head>
+ <title>A study of population dynamics</TITLE>
+ <style type="text/css">
+ a:link { color: red }
+ a:visited { color: maroon }
+ a:active { color: fuchsia }
+ </style>
+
+</head>
+<body>
+ <p>... document body... <a href="foo.htm">Foo</a></p>
+</body>
+</html>
+
+
Example 4: Specifying only background color with bgcolor in HTML
+
+
In the example below the background color is defined on the body
+ element, however the foreground color is not defined. Therefore, the
+ example fails the Success Criterion.
+
+
Note that the use of the bgcolor attribute is deprecated as of HTML 4, but this failure example is included as this
+ usage is still found on some web sites.
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml">
+ <html>
+ <head>
+ <title>A study of population dynamics</title>
+ </head>
+ <body bgcolor="white">
+ <p> ... document body...</p>
+ </body>
+ </html>
+
+
Example 5: Specifying only foreground color with the text attribute in HTML
+
+
In the example below the foreground color is defined on the body
+ element, however the background color is not defined. Therefore, the
+ example fails the Success Criterion.
+
+
Note that the use of the text attribute is deprecated as of HTML 4, but this failure example is included as this
+ usage is still found on some web sites.
+
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
+<head>
+ <title>A study of population dynamics</title>
+
+</head>
+<body text="white">
+ <p>... document body...</p>
+</body>
+</html>
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check to see if an author-specified foreground color is present
+
+
Check to see if an author-specified background color is present
+
+
+
+
+
Note
+
+
+
+ Color and background color may be specified at any level in the cascade of preceding
+ selectors, by external stylesheets or through inheritance rules.
+
+
+
+
+ Background color may also be specified using a background image with the CSS property
+ 'background-image' or with the CSS property 'background' (with the URI of the image,
+ e.g., 'background: url("images/bg.gif")'). With background images, it is still necessary
+ to specify a background color, because users may have images turned off in their browser.
+ But the background image and the background color need to be checked.
+
+
+
+
+
+
+
+
Expected Results
+
+
If step #2 is true but step #3 is false, OR if step #3 is true but step #2 is false
+ then this
+ failure condition applies and content fails these Success Criteria.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F25.html b/wcag21/techniques/failures/F25.html
new file mode 100644
index 0000000..d62e28c
--- /dev/null
+++ b/wcag21/techniques/failures/F25.html
@@ -0,0 +1,141 @@
+
+
+
+
+ F25: Failure of Success Criterion 2.4.2 due to the title of a Web page not identifying
+ the
+ contents
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.2 due to the title of a Web page not identifying
+ the
+ contents
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Check whether the title of each Web page identifies the contents
+ or purpose of the Web page .
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is false, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F26.html b/wcag21/techniques/failures/F26.html
new file mode 100644
index 0000000..52ac63b
--- /dev/null
+++ b/wcag21/techniques/failures/F26.html
@@ -0,0 +1,122 @@
+
+
+
+
+ F26:
+ Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey
+ information
+
+
+
+
+
+
+
+
+
+ Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey
+ information
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to show how using a graphical symbol to convey
+ information can make content difficult to comprehend. A graphical symbol may be an
+ image, an image of text or a pictorial or decorative character symbol (glyph) which
+ imparts information nonverbally. Examples of graphical symbols include an image of
+ a red circle with a line through it, a "smiley" face, or a glyph which represents
+ a check mark, arrow, or other symbol but is not the character with that meaning.
+
+
Assistive technology users may have difficulty determining the meaning of the graphical
+ symbol. If a graphical symbol is used to convey information, provide an alternative
+ using features of the technology or use a different mechanism that can be marked with
+ an alternative to represent the graphical symbol. For example, an image with a text
+ alternative can be used instead of the glyph.
+
+
+
+
Examples
+
+
Example 1: Glyphs Used to Indicate Status
+
A shopping cart uses two simple glyphs to indicate whether an item is available for
+ immediate shipment. A circle indicates that the item is in stock and ready to ship.
+ An square indicates that the item is currently on back order and not available for
+ immediate shipment. The instructions above items refer to the circle and square as
+ the sole means to differentiating whether an item is available.
+
For each instuction that refers to non-text marks that convey information:
+
+
+
+
Check whether there are other means to determine the information conveyed by the non-text
+ marks.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If #1 is false, then this failure condition applies and the content fails this Success
+ Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F3.html b/wcag21/techniques/failures/F3.html
new file mode 100644
index 0000000..43b6ba8
--- /dev/null
+++ b/wcag21/techniques/failures/F3.html
@@ -0,0 +1,184 @@
+
+
+
+
+ F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey
+ important information
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to using CSS to include images that convey
+ important information
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The CSS background-image property provides a way to include images in the
+ document with CSS without any reference in the HTML code. The CSS
+ background-image property was designed for decorative purposes and it is not
+ possible to associate text alternatives with images that are included via
+ CSS. Text alternatives are necessary for people who cannot see images that
+ convey important information. Therefore, it is a failure to use this
+ property to add images to convey important information. This failure would apply equally
+ in a case where the background image was declared in the HTML style attribute, as
+ well as in a case where the background image declaration was created dynamically in
+ a client script (see example 3 below).
+
+
+
Note
+
+
+
Embedding information into a background image can also cause problems for people who
+ use alternate backgrounds in order to increase legibility and for users of high contrast
+ mode in some operating systems. These users, would lose the information in the background
+ image due to lack of any alternative text.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
In the following example, part of the content is contained in an
+ image that is presented by CSS alone. In this example, the image
+ TopRate.png is a 180 by 200 pixel image that contains the text,
+ "19.3% APR Typical Variable."
+
The CSS contains:
+p#bestinterest {
+ padding-left: 200px;
+ background: transparent url(/images/TopRate.png) no-repeat top left;
+}
It is used in this excerpt:
+<p id="bestinterest">
+ Where else would you find a better interest rate?
+</p>
+
+
Example 2
+
A book distributor uses background images to provide icons against a
+ list of book titles to indicate whether they are new, limited,
+ in-stock, or out of stock.
+
+<ul id="booklist">
+ <li class="new">Some book</li>
+ <li class="instock">Some other book</li>
+ <li class="limited">A book we desperately want to get rid of</li>
+ ...
+ <li class="outstock">A book you actually want </li>
+</ul>
+
+
Example 3
+
Using the code from example 1, the same background image is declared in the HTML style
+ attribute:
+
<p id="bestinterest" style="background: transparent url(/images/TopRate.png) no-repeat top left;" >
+Where else would you find a better interest rate?
+<p>
In the following code, the background image declaration is created in a client script:
<script type="text/javascript">
+var newP = document.createElement('p');
+var newPText = document.createTextNode('Where else would you find a better interest rate?');
+newP.appendChild(newPText);
+newP.style.background = 'transparent url(/images/TopRate.png) no-repeat top left';
+document.body.appendChild(newP);
+</script>
Examine all images added to the content via CSS, HTML style attributes, or dynamically
+ in script as background images.
+
+
+
Check that the images do not convey important information.
+
+
If an image does convey important information, the information is
+ provided to assistive technologies and is also available when the CSS image is
+ not displayed.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 and step #3 are both false, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F30.html b/wcag21/techniques/failures/F30.html
new file mode 100644
index 0000000..f07b6eb
--- /dev/null
+++ b/wcag21/techniques/failures/F30.html
@@ -0,0 +1,119 @@
+
+
+
+
+ F30: Failure of Success Criterion 1.1.1 and 1.2.1 due to using text alternatives that are
+ not
+ alternatives (e.g., filenames or placeholder text)
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 and 1.2.1 due to using text alternatives that are
+ not
+ alternatives (e.g., filenames or placeholder text)
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition for all techniques involving text
+ alternatives. If the text in the "text alternative" cannot be used in place
+ of the non-text content without losing information or function then it fails
+ because it is not, in fact, an alternative to the non-text content.
+
+
+
+
Examples
+
+
Example 1
+
Examples of text that are not text alternatives include:
+
+
+
placeholder text such as " " or "spacer" or "image" or
+ "picture" etc that are put into the 'text alternative'
+ location on images or pictures.
+
+
+
programming references that do not convey the information or
+ function of the non-text content such as "picture 1",
+ "picture 2" or "0001", "0002" or "Intro#1", "Intro#2".
+
+
+
filenames that are not valid text alternatives in their own
+ right such as "Oct.jpg" or "Chart.jpg" or
+ "sales\\oct\\top3.jpg"
+
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check each text alternative to see if it is not actually a text
+ alternative for the non-text content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true then this failure condition applies and content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F31.html b/wcag21/techniques/failures/F31.html
new file mode 100644
index 0000000..b6f0d44
--- /dev/null
+++ b/wcag21/techniques/failures/F31.html
@@ -0,0 +1,120 @@
+
+
+
+
+ F31: Failure of Success Criterion 3.2.4 due to using two different labels for the same
+ function on different Web pages within a set of Web pages
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.4 due to using two different labels for the same
+ function on different Web pages within a set of Web pages
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Components that have the same function in different Web pages are more
+ easily recognized if they are labeled consistently. If the naming is not
+ consistent, some users may get confused.
+
+
+
Note
+
+
+
Text alternatives that are "consistent" are not always "identical." For
+ instance, you may have an graphical arrow at the bottom of a Web page
+ that links to the next Web page. The text alternative may say "Go to
+ page 4." Naturally, it would not be appropriate to repeat this exact
+ text alternative on the next Web page. It would be more appropriate to
+ say "Go to page 5". Although these text alternatives would not be
+ identical, they would be consistent, and therefore would not be failures
+ for this Success Criterion.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
One of the most common examples of using inconsistent labels for
+ components with the same function is to use a button that says
+ "search" in one page and to use a button that says "find" on another
+ page when they both serve the identical function.
+
+
+
+
Example 2
+
An online authoring tool that uses a button with "Save page" on one
+ page and "Save" on another page, in both cases for the same
+ function.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
In a set of Web pages, find components with the same function
+ that are repeated in multiple Web pages.
+
+
+
For each component with the same function found in step #1, check
+ that the naming is consistent.
+
+
+
+
+
+
+
Expected Results
+
+
If step #2 is false then this failure condition applies and content fails
+ the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F32.html b/wcag21/techniques/failures/F32.html
new file mode 100644
index 0000000..52e1839
--- /dev/null
+++ b/wcag21/techniques/failures/F32.html
@@ -0,0 +1,159 @@
+
+
+
+
+ F32: Failure of Success Criterion 1.3.2 due to using white space characters to control
+ spacing within a word
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.2 due to using white space characters to control
+ spacing within a word
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe how using white space characters, such
+ as space, tab, line break, or carriage return, to format individual words visually
+ can be a failure to present meaningful sequences properly. When blank characters are
+ inserted to control letter spacing within a word, they may change the interpretation
+ of the word or cause it not to be programmatically recognized as a single word.
+
+
+
Inserting white space characters into an initialism is not an example of this
+ failure, since the white space does not change the interpretation of the
+ initialism and may make it easier to understand.
+
+
The use of white space between words for visual formatting is not a failure,
+ since it does not change the interpretation of the words.
+
+
+
+
Examples
+
+
Example 1: Failure due to adding white space in the middle of a word
+
This example has white spaces within a word to space out the letters
+ in a heading. Screen readers may read each letter individually
+ instead of the word "Welcome."
+
+<h1>W e l c o m e</h1>
+
can also be used to add white space, producing similar
+ failures:
+
+<h1>H E L L O</h1>
+
+
+
Example 2: White space in the middle of a word changing its meaning
+
In Japanese, Han characters (Kanji) may have multiple readings that
+ mean very different things. In this example, the word is read
+ incorrectly because screen readers may not recognize these
+ characters as a word because of the white space between the
+ characters. The characters mean "Tokyo," but screen readers say
+ "Higashi Kyo".
+
+<h1>東 京</h1>
+
+
+
Example 3: Using line break characters to format vertical text
+
In the row header cell of a data table containing Japanese text,
+ authors often create vertical text by using line break characters.
+ However screen readers are not able to read the words in vertical
+ text correctly because the line breaks occur within the word. In the
+ following example, "東京都"(Tokyo-to) will be read "Higashi Kyo
+ Miyako".
+
For each word that appears to have non-standard spacing between
+ characters:
+
+
+
+
+
Check whether any words in the text of the content contain white
+ space characters .
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F33.html b/wcag21/techniques/failures/F33.html
new file mode 100644
index 0000000..1497750
--- /dev/null
+++ b/wcag21/techniques/failures/F33.html
@@ -0,0 +1,154 @@
+
+
+
+
+ F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to
+ create multiple columns in plain text content
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to
+ create multiple columns in plain text content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe how using white space
+ characters, such as space, tab, line break, or carriage return, to format columns
+ of
+ data in text content is a failure to use structure properly. Assistive
+ technologies will interpret content in the reading order of the current
+ language. Using white space characters to create multiple columns does not
+ provide the information in a natural reading order. Thus, the assistive
+ technology user will not be presented with the information in an
+ understandable manner.
+
+
Plain text is not suitable for displaying multiple columns of text. Modify
+ the content to present the data in a different layout. Alternatively, use a
+ technology that provides structural elements to represent columnar data.
+
+
+
+
Examples
+
+
Example 1
+
The following example incorrectly uses white space characters to
+ format a paragraph into a two column format.
+
+Web Content Accessibility Guidelines including blindness and low vision,
+2.0 (WCAG 2.0) covers a wide range of deafness and hearing loss, learning
+issues and recommendations for making difficulties, cognitive limitations, limited
+Web content more accessible. This movement, speech difficulties, and
+document contains principles, others. Following these guidelines will
+guidelines, Success Criteria, benefits, also make your Web content more
+and examples that define and explain accessible to the vast majority of users,
+the requirements for making Web-based including older users. It will also enable
+information and applications accessible. people to access Web content using
+"Accessible" means usable to a wide many different devices - including a
+range of people with disabilities, wide variety of assistive technologies.
+
If this table was to be interpreted and spoken by a screen reader it
+ would speak the following lines:
+
+
+
+
Web Content Accessibility Guidelines including blindness and
+ low vision,
+
+
+
2.0 (WCAG 2.0) covers a wide range of deafness and hearing
+ loss, learning
+
+
+
issues and recommendations for making difficulties, cognitive
+ limitations, limited
+
+
+
Web content more accessible. This movement, speech
+ difficulties, and
+
+
+
(additional lines eliminated for brevity)
+
+
+
If the text were reflowed, or changed from a fixed to a variable
+ font, or increased in size until lines no longer fit on the page,
+ similar interpretation issues would arise in the visual
+ presentation.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Examine the document for data or information presented in
+ columnar format.
+
+
+
Check whether the columns are created using white space
+ characters to lay out the information.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is true, then this failure condition applies and the
+ content fails these Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F34.html b/wcag21/techniques/failures/F34.html
new file mode 100644
index 0000000..c396df2
--- /dev/null
+++ b/wcag21/techniques/failures/F34.html
@@ -0,0 +1,163 @@
+
+
+
+
+ F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to
+ format tables in plain text content
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to
+ format tables in plain text content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe how using white space
+ characters, such as space, tab, line break, or carriage return, to format tables in
+ text
+ content is a failure to use structure properly. When tables are created in
+ this manner there is no way to indicate that a cell is intended to be a
+ header cell, no way to associate the table header cells with the table data
+ cells, or to navigate directly to a particular cell in a table.
+
+
In addition, assistive technologies will interpret content in the reading
+ order of the current language. Using white space to organize data in a
+ visual table does not provide the information in a natural reading order in
+ the source of the document. Thus, the assistive technology user will not be
+ presented with the information in a logical reading order.
+
+
Plain text is not suitable for displaying complex information like tables
+ because the structure of the table cannot be perceived. Rather than using
+ visual formatting to represent tabular relations,
+ tabular information would need to be presented using a different technology or presented
+ linearly. (See Presenting tabular information in plain text)
+
+
+
+
Examples
+
+
Example 1
+
The following example incorrectly uses white space to format a Menu
+ as a visual table.
+
+Menu
+ Breakfast Lunch Dinner
+
+Monday 2 fried eggs tomato soup garden salad
+ bacon hamburger Fried Chicken
+ toast onion rings green beans
+ Oatmeal cookie mashed potatoes
+
+Tuesday Pancakes vegetable soup Caesar salad
+ sausage hot dogs Spaghetti with meatballs
+ orange juice potato salad Italian bread
+ brownie ice cream
+
If this table was to be interpreted and spoken by a screen reader it
+ would speak the following lines:
+
+
+
+
Menu
+
+
Breakfast Lunch Dinner
+
+
Monday 2 fried eggs tomato soup garden salad
+
+
bacon hamburger Fried Chicken
+
+
toast onion rings green beans
+
+
Oatmeal cookie mashed potatoes
+
+
+
This reading order does not make sense since there is no structure in
+ the table for the assistive technology to identify it as a table. If
+ the text were reflowed, or changed from a fixed to a variable font,
+ or increased in size until lines no longer fit on the page, similar
+ issues would arise in the visual presentation.
+
Examine the document for visually formatted tables.
+
+
Check whether the tables are created using white space characters
+ to layout the tabular data.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is true, then this failure condition applies and the
+ content fails these Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F36.html b/wcag21/techniques/failures/F36.html
new file mode 100644
index 0000000..68b8af6
--- /dev/null
+++ b/wcag21/techniques/failures/F36.html
@@ -0,0 +1,135 @@
+
+
+
+
+ F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and
+ presenting new content without prior warning when the last field in the form is
+ given a value
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.2 due to automatically submitting a form and
+ presenting new content without prior warning when the last field in the form is
+ given a value
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Forms are frequently designed so that they submit automatically when the user
+ has filled in all the fields, or when focus leaves the last field. There are
+ two problems with this approach. First is that a disabled user who needs
+ more context may move focus away from the field to the directions on how to
+ fill in the form, or to other text, accidentally submitting the form. The
+ other is that, with some form elements, the value of the field changes as
+ each item is navigated with the keyboard, again accidentally submitting the
+ form. It is better to rely on the standard form behavior of the submit
+ button and enter key.
+
+
+
+
Examples
+
+
Example 1
+
This failure example submits a form when the user leaves the last
+ field of a three-field telephone number form. The form will submit
+ if the user leaves the field after editing it, even navigating
+ backwards in the tab order. Developers should not use this method to
+ submit a form, and should instead use a submit button, or rely on
+ the form's default behavior of submitting when the user hits enter
+ in a text field.
+
This is a example that submits a form when the user
+ selects an option from the menu when there is no warning of this behavior in advance.
+ The form will submit as soon as an item from the menu is selected. A user using a
+ keyboard will not be able to navigate past the first item in the menu. Blind users
+ and users with hand tremors can easily make a mistake on which item on the dropdown
+ menu to choose and they are taken to the wrong destination before they can correct
+ it.
+
Enter data in last field and exit from it (tab out of it).
+
+
Check whether leaving the last field causes change of
+ context.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #3 is true, then this failure condition applies and content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F37.html b/wcag21/techniques/failures/F37.html
new file mode 100644
index 0000000..9dcf53e
--- /dev/null
+++ b/wcag21/techniques/failures/F37.html
@@ -0,0 +1,126 @@
+
+
+
+
+ F37: Failure of Success Criterion 3.2.2 due to launching a new window without prior warning
+ when the selection of a radio button, check box or select list is changed
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.2 due to launching a new window without prior warning
+ when the selection of a radio button, check box or select list is changed
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when changing the selection of a
+ radio button, a check box or an item in a select list causes a new window to
+ open. It is possible to use scripting to create an input
+ element that causes a change of context (submit the form, open a new page, a
+ new window) when the element is selected. Developers can instead use a
+ submit button (see G80: Providing a submit button to initiate a change of context) or clearly indicate the
+ expected action.
+
+
+
+
Examples
+
+
Example 1
+
The example below fails the Success Criterion because it processes
+ the form when a radio button is selected instead of using a submit
+ button.
+
For each form control that is a radio button, check box or an
+ item in a select list, check if changing the selection of the
+ control launches a new window.
+
+
+
For each new window resulting from step 2, check if the user is
+ warned in advance.
+
+
+
+
+
+
+
Expected Results
+
+
If step #3 is false, then this failure condition applies and content
+ fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F38.html b/wcag21/techniques/failures/F38.html
new file mode 100644
index 0000000..19287c2
--- /dev/null
+++ b/wcag21/techniques/failures/F38.html
@@ -0,0 +1,112 @@
+
+
+
+
+ F38: Failure of Success Criterion 1.1.1 due to not marking up decorative images in HTML
+ in a way that allows assistive technology to ignore them
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to not marking up decorative images in HTML
+ in a way that allows assistive technology to ignore them
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition for text alternatives for images that
+ should be ignored by AT. If there is no alt attribute at all assistive
+ technologies are not able to ignore the non-text content. The alt attribute
+ must be provided and have a null value (i.e., alt="" ) to avoid a failure of this
+ Success Criterion.
+
+
This describes a failure condition for text alternatives for images that should be
+ ignored by assistive technology (AT). If an image has the attribute role="presentation",
+ it will be ignored by AT. However, if it does not have role="presentation", and if
+ there is no alt attribute at all assistive technologies are not able to ignore the image. For decorative
+ images which need to be ignored by AT, either role="presentation" must be used or
+ the alt attribute must be provided and have a null value (i.e., alt="") to avoid a
+ failure of this Success Criterion.
+
+
+
+
Examples
+
+
+
Decorative images that have no alt
+ attribute and no role attribute
+
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
For any img element that is used for purely decorative content:
+
+
+
+
+
Check whether the element has no role attribute or has a role attribute value that is not presentation.
+
+
+
Check whether the element has no alt attribute or has an alt attribute with a value that is not null.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true and if step #2 is true, this failure condition applies and content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F39.html b/wcag21/techniques/failures/F39.html
new file mode 100644
index 0000000..49a59dc
--- /dev/null
+++ b/wcag21/techniques/failures/F39.html
@@ -0,0 +1,126 @@
+
+
+
+
+ F39: Failure of Success Criterion 1.1.1 due to providing a text alternative that is not
+ null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive
+ technology
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to providing a text alternative that is not
+ null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive
+ technology
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This technique describes a failure condition for images that should
+ be ignored by assistive technologies. A text alternative for an image
+ should convey the meaning of the image. When an image is used for decoration,
+ spacing or other purpose that is not part of the meaningful content
+ in the page then the image has no meaning and should be ignored by
+ assistive technologies.
+
+
Providing a null text alternative (i.e., alt="" )
+ will allow assistive technology to ignore the image and avoid a failure
+ of this Success Criterion.
+
+
+
+
Examples
+
+
Example 1: Decorative images that have no alt attribute
+
+
An image is used to create a blank space between content, where the
+ spacing itself is not meaningful to the content. The image has an alt
+ text value of "spacer". This image fails the Success Criterion
+ because the text alternative does not serve an equivalent purpose.
+ The image is meant to be ignored but its alternative text "spacer" is
+ announced by screen readers and displayed in some alternate color schemes.
+
Identify any img elements that are used for decoration, spacing
+ or other purpose that is not part of the meaningful content in the
+ page
+
+
+
Check that the alt attribute for these elements is null.
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is false, this failure condition applies and the content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F4.html b/wcag21/techniques/failures/F4.html
new file mode 100644
index 0000000..0325627
--- /dev/null
+++ b/wcag21/techniques/failures/F4.html
@@ -0,0 +1,129 @@
+
+
+
+
+ F4: Failure of Success Criterion 2.2.2 due to using text-decoration:blink without a
+ mechanism to stop it in less than five seconds
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.2 due to using text-decoration:blink without a
+ mechanism to stop it in less than five seconds
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
CSS defines the blink value for the text-decoration
+ property. When used, it causes any text in elements with this property to
+ blink at a predetermined rate. This cannot be interrupted by the user, nor
+ can it be disabled as a user agent preference. The blinking continues as
+ long as the page is displayed. Therefore, content that uses
+ text-decoration:blink fails the Success Criterion because
+ blinking can continue for more than three seconds.
+
+
+
+
Examples
+
+
Example 1
+
A product list page uses the text-decoration:blink style
+ on an element to draw attention to sale prices. This fails the
+ Success Criterion because users cannot control the blink.
+
+<p>My Great Product <span style="text-decoration:blink">Sale! $44,995!</span></p>
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine inline styles, internal stylesheets, and external
+ stylesheets for the text-decoration property with a
+ value of "blink".
+
+
+
If the property is used, determine if the ID, class, or element
+ identified by selectors on which this property is defined are
+ used in the document.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 and step #2 are true, the content fails the success
+ criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F40.html b/wcag21/techniques/failures/F40.html
new file mode 100644
index 0000000..e40e091
--- /dev/null
+++ b/wcag21/techniques/failures/F40.html
@@ -0,0 +1,174 @@
+
+
+
+
+ F40: Failure due to using meta redirect with a time limit
+
+
+
+
+
+
+
+
+
+
Failure due to using meta redirect with a time limit
+
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+ meta
+ http-equiv of {time-out}; url=... is often used to
+ automatically redirect users. When this occurs after a time delay, it is an
+ unexpected change of context that may interrupt the user.
+
+
It is acceptable to use the meta element to create a redirect
+ when the time-out is set to zero, since the redirect is instant and will not
+ be perceived as a change of context. However, it is preferable to use
+ server-side methods to accomplish this. See SVR1: Implementing automatic redirects on the server side instead of on the client side.
+
+
+
+
Examples
+
+
Example 1
+
The page below is a failure because it will redirect to the URI
+ http://www.example.com/newpage after a time limit of 5 seconds.
+
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
+ <head>
+ <title>Do not use this!</title>
+ <meta http-equiv="refresh"
+ content="5; url=http://www.example.com/newpage" />
+ </head>
+ <body>
+ <p>
+ If your browser supports Refresh, you'll be
+ transported to our
+ <a href="http://www.example.com/newpage">new site</a>
+ in 5 seconds, otherwise, select the link manually.
+ </p>
+ </body>
+</html>
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check if the user is provided an opportunity to turn off, extend, or adjust the timing
+ of the page refresh.
+
+
+
Check if the page does not redirect after the duration specified in the
+ content attribute.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If checks #1-5 are false, this failure condition applies and the content fails Success
+ Criterion 2.2.1.
+
+
+
If checks #1, #2, #4, and #5 are false, this failure condition applies and the content
+ fails Success Criterion 2.2.4.
+
+
+
If checks #1, #4, and #5 are false, this failure condition applies and the content
+ fails Success Criterion 3.2.5.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F41.html b/wcag21/techniques/failures/F41.html
new file mode 100644
index 0000000..9ceef02
--- /dev/null
+++ b/wcag21/techniques/failures/F41.html
@@ -0,0 +1,149 @@
+
+
+
+
+ F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh to
+ reload the page
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh to
+ reload the page
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+ meta
+ http-equiv of refresh is often used to periodically refresh
+ pages or to redirect users to another page. If the time interval is too
+ short, and there is no way to turn auto-refresh off, people who are blind will not
+ have enough time to make their screen
+ readers read the page before the page refreshes unexpectedly and causes the
+ screen reader to begin reading at the top. Sighted users may also be
+ disoriented by the unexpected refresh.
+
+
+
+
Examples
+
+
Example 1
+
This is a deprecated example that changes the user's page at regular
+ intervals. Content developers should not use this technique to
+ simulate "push" technology. Developers cannot predict how much time
+ a user will require to read a page; premature refresh can disorient
+ users. Content developers should avoid periodic refresh and allow
+ users to choose when they want the latest information. (The number
+ in the content attribute is the refresh interval in
+ seconds.)
+
Check if the user is provided an opportunity to turn off, extend, or adjust the timing
+ of the page refresh.
+
+
+
Check if the page does not refresh after the duration specified in the
+ content attribute.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If checks #1-5 are false then this failure condition applies and content fails Success
+ Criteria 2.2.1.
+
+
+
If checks #1, #2, #4, and #5 are false, this failure condition applies and the content
+ fails Success Criterion 2.2.4.
+
+
+
If checks #1 and #4 are false then this failure condition applies and content fails
+ Success Criterion 3.2.5.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F42.html b/wcag21/techniques/failures/F42.html
new file mode 100644
index 0000000..777a85c
--- /dev/null
+++ b/wcag21/techniques/failures/F42.html
@@ -0,0 +1,237 @@
+
+
+
+
+ F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
+
+
+
+
+
+
+
+
Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure occurs when JavaScript event handlers are attached to elements
+ to emulate links. A link created in this manner cannot be tabbed to from the keyboard
+ and does not gain keyboard focus like other controls and/or links.
+ If scripting events are used to emulate links, user
+ agents including assistive technology may not be able to identify the links
+ in the content as links. They may be recognized as interactive controls but still
+ not recognized as links. Such elements do not appear in the links
+ list generated by user agents or assistive technology.
+
+
+
+
Note
+
It is possible to use the ARIA role attribute to identify an anonymous element as link control for assistive technologies.
+ However, best practice for ARIA calls for making use of native elements whenever possible, so the use of the role attribute to identify anonymous elements as links is not recommended.
+
+
+
+
The a and area
+ elements are intended to mark up links.
+
+
+
+
Examples
+
+
Example 1: Scripting a span element
+
+
Scripted event handling is added to a span element so
+ that it functions as a link when clicked with a mouse. Assistive
+ technology does not recognize this element as a link.
+
+<span onclick="location.href='newpage.html'">
+ Fake link
+</span>
+
+
+
Example 2: Scripting an img element
+
+
Scripted event handling is added to an img element so
+ that it functions as a link when clicked with a mouse. Assistive
+ technology does not recognize this element as a link.
+
+ <img src="go.gif"
+ alt="go to the new page"
+ onclick="location.href='newpage.html'">
+
+
+
Example 3: Scripting an img element, with keyboard
+ support
+
+
Scripted event handling is added to an img element so
+ that it functions as a link. In this example, the link functionality
+ can be invoked with the mouse or via the Enter key if the user agent
+ includes the element in the tab chain. Nevertheless, the element
+ will not be recognized as a link.
+
+function doNav(url)
+{
+ window.location.href = url;
+}
+
+function doKeyPress(url)
+{
+ //if the enter key was pressed
+ if (window.event.type == "keypress" &&
+ window.event.keyCode == 13)
+ {
+ doNav(url);
+ }
+}
+
This example uses script to make a div element behave
+ like a link. Although the author has provided complete keyboard
+ access and separated the event handlers from the markup to enable
+ repurposing of the content, the div element will not be
+ recognized as a link by assistive technology.
+
For all elements presented as links which use JavaScript event handlers to make the
+ element emulate a link:
+
+
+
+
+
Check if the programmatically determined role of the element is link.
+
+
+
Check if the emulated link can be activated using the keyboard.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false then this failure condition applies and the content fails Success
+ Criteria 1.3.1 and 4.1.2.
+ If check #2 is false then this failure condition applies and the content fails Success
+ Criteria 2.1.1 and 2.1.3.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F43.html b/wcag21/techniques/failures/F43.html
new file mode 100644
index 0000000..4f7c0a3
--- /dev/null
+++ b/wcag21/techniques/failures/F43.html
@@ -0,0 +1,179 @@
+
+
+
+
+ F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does
+ not represent relationships in the content
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to using structural markup in a way that does
+ not represent relationships in the content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe a failure that occurs when
+ structural markup is used to achieve a presentational effect, but indicates
+ relationships that do not exist in the content. This is disorienting to
+ users who are depending on those relationships to navigate the content or to
+ understand the relationship of one piece of the content to another. Note
+ that the use of HTML tables for layout is not an example of this failure as
+ long as the layout table does not include improper structural markup such as
+ <th> or <caption>
+ elements.
+
+
+
Note
+
+
+
Though an element's semantic meaning is generally exposed to AT, the WAI-ARIA presentation
+ role can be used to suppress the native semantics of an element so that they are not
+ mapped to the accessibility API. Setting an element's role to presentation may avoid this failure by hiding that element's semantics from the
+ user.
+
+
+
+
+
+
+
Examples
+
+
Example 1: A heading used only for visual effect
+
In this example, a heading element is used to display an address in a
+ large, bold font. The address does not identify a new section of the
+ document, however, so it should not be marked as a heading.
+
+<p>Interested in learning more? Write to us at</p>
+<h4>3333 Third Avenue, Suite 300 · New York City</h4>
+
+<p>And we'll send you the complete informational packet absolutely Free!</p>
+
+
+
Example 2: Using heading elements for presentational effect
+
In this example, heading markup is used in two different ways: to
+ convey document structure and to create visual effects. The
+ h1 and h2 elements are used appropriately
+ to mark the beginning of the document as a whole and the beginning
+ of the abstract. However, the h3 and h4
+ elements between the title and the abstract are used only for visual
+ effect — to control the fonts used to display the authors' names and
+ the date.
+
+<h1>Study on the Use of Heading Elements in Web Pages</h1>
+<h3>Joe Jones and Mary Smith<h3>
+<h4>March 14, 2006</h4>
+<h2>Abstract</h2>
+<p>A study was conducted in early 2006 ...
+</p>
+
+
+
Example 3: Using blockquote elements to provide additional
+ indentation
+
+
The following example uses blockquote for text that is
+ not a quotation to give it prominence by indenting it when displayed
+ in graphical browsers.
+
+<p>After extensive study of the company Web site, the task force
+identified the following common problem.</p>
+
+<blockquote>
+<p>The use of markup for presentational effects made Web
+pages confusing to screen reader users.</p>
+</blockquote>
+
+<p>The committee lists particular examples of the problems
+introduced by this practice below.</p>
+
+
+
Example 4: Using the fieldset and legend elements to
+ give a border to text
+
+<fieldset>
+<legend>Bargain Corner</legend>
+<p>Buy today, and save 20%</p>
+</fieldset>
+
Check that the element's semantic meaning is exposed to assistive technology and appropriate
+ for the content of the element.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false then this failure condition applies.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F44.html b/wcag21/techniques/failures/F44.html
new file mode 100644
index 0000000..dfe8294
--- /dev/null
+++ b/wcag21/techniques/failures/F44.html
@@ -0,0 +1,149 @@
+
+
+
+
+ F44: Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that
+ does not preserve meaning and operability
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that
+ does not preserve meaning and operability
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when the tab order does not
+ follow logical relationships and sequences in the content.
+
+
Focusable elements like links and form elements have a tabindex
+ attribute. The elements receive focus in ascending order of the value of the
+ tabindex attribute. When the values of the
+ tabindex attribute are assigned in a different order than the
+ relationships and sequences in the content, the tab order no longer follows
+ the relationships and sequences in the content.
+
+
One of the most common causes of this failure occurs when editing a page
+ where tabindex has been used. It is easy for the tab order and
+ the content order to fall out of correspondence when the content is edited
+ but the tabindex attributes are not updated to reflect the
+ changes to the content.
+
+
+
+
Examples
+
+
Example 1
+
The following example incorrectly uses tabindex to specify an
+ alternative tab order:
+
If this list is navigated by the tab key, the list is navigated in
+ the order Homepage, chapter 3, chapter 2, chapter 1, which does not
+ follow the sequence in the content.
+
+
+
+
Example 2
+
The tab order has been set explicitly in a Web page by providing
+ tabindex attributes for all fields. Later, the page
+ is modified to add a new field in the middle of the page, but the
+ author forgets to add a tabindex attribute to the new
+ field. As a result, the new field is at the end of the tab
+ order.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
If tabindex is used, check that the tab order
+ specified by the tabindex attributes follows
+ relationships in the content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false, then this failure condition applies and
+ content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F46.html b/wcag21/techniques/failures/F46.html
new file mode 100644
index 0000000..d1872a9
--- /dev/null
+++ b/wcag21/techniques/failures/F46.html
@@ -0,0 +1,196 @@
+
+
+
+
+ F46: Failure of Success Criterion 1.3.1 due to using th elements,
+ caption elements, or non-empty summary attributes in
+ layout tables
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to using th elements,
+ caption elements, or non-empty summary attributes in
+ layout tables
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe a failure that occurs when a
+ table used only for layout includes either th elements, a
+ summary attribute, or a caption element. This
+ is a failure because it uses structural (or semantic) markup only for
+ presentation. The intent of the HTML and XHTML table elements is to present data.
+
+
+
Although not commonly used in a layout table, the following structural markup would
+ also be failures of Success Criterion 1.3.1 if used in a layout table:
+
+
+
+
+ headers attributes
+
+
+
+ scope attributes
+
+
+
+
+
Assistive technologies use the structure of an HTML or XHTML table to present data
+ to
+ the user in a logical manner. The th element is used to mark
+ the column and row headers of the table. A screen reader uses the
+ information in th elements to speak the header information that
+ changes as the user navigates the table. The summary attribute on the
+ table element provides a textual description of the table
+ that describes its purpose and function. Assistive technologies make the
+ summary attribute information available to users. The
+ caption element is part of the table and identifies the
+ table.
+
+
+ Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are
+ recommended in order to retain the defined semantic meaning of the HTML table elements
+ and to conform to the coding practice of separating presentation from content.
+ When a table is used
+ for layout purposes the th element should not be used. Since
+ the table is not presenting data there is no need to mark any cells as
+ column or row headers. Likewise, there is no need for an additional
+ description of a table which is only used to layout content. Do not include
+ a summary attribute and do not use the summary
+ attribute to describe the table as, for instance, "layout table". When
+ spoken, this information does not provide value and will only distract users
+ navigating the content via a screen reader. Empty summary
+ attributes are acceptable on layout tables, but not recommended.
+
+
+
+
Examples
+
+
Example 1
+
Here is a simple example that uses a table to layout content in a
+ three column format. The navigation bar is in the left column, the
+ main content in the middle column, and an additional sidebar is on
+ the right. At the top is a page title. The example marks the page
+ title as <th>, and provides a summary
+ attribute indicating that the table is a layout table.
+
Examine the source code of the HTML or XHTML document for the
+ table element
+
+
+
+
+
If the table is used only to visually lay out elements within the
+ content
+
+
+
+
+
Check that the table does not contain any th
+ elements.
+
+
+
Check that the table element does not
+ contain a non-empty summary attribute.
+
+
+
Check that the table element does not
+ contain a caption element.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If any check above is false, then this failure condition applies
+ and the content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F47.html b/wcag21/techniques/failures/F47.html
new file mode 100644
index 0000000..6bd9284
--- /dev/null
+++ b/wcag21/techniques/failures/F47.html
@@ -0,0 +1,113 @@
+
+
+
+
+ F47: Failure of Success Criterion 2.2.2 due to using the blink element
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.2 due to using the blink element
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The blink element, while not part of the official HTML or XHTML
+ specification, is supported by many user agents. It causes any text inside
+ the element to blink at a predetermined rate. This cannot be interrupted by
+ the user, nor can it be disabled as a preference. The blinking continues as
+ long as the page is displayed. Therefore, content that uses
+ blink fails the Success Criterion because blinking can continue
+ for more than three seconds.
+
+
+
+
Examples
+
+
Example 1
+
A product list page uses the blink element to draw
+ attention to sale prices. This fails the Success Criterion because
+ users cannot control the blink.
+
+<p>My Great Product <blink>Sale! $44,995!</blink></p>
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine code for the presence of the blink
+ element.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If #1 is true, the content fails the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F48.html b/wcag21/techniques/failures/F48.html
new file mode 100644
index 0000000..9f666b2
--- /dev/null
+++ b/wcag21/techniques/failures/F48.html
@@ -0,0 +1,142 @@
+
+
+
+
+ F48: Failure of Success Criterion 1.3.1 due to using the pre element to markup
+ tabular information
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to using the pre element to markup
+ tabular information
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure caused by use of the HTML pre
+ element to markup tabular information. The pre element
+ preserves only visual formatting. If the pre element is used to
+ markup tabular information, the visually implied logical relationships
+ between the table cells and the headers are lost if the user cannot see the
+ screen or if the visual presentation changes significantly.
+
+
Instead, the HTML table element is intended to present tabular
+ data. Assistive technologies use the structure of an HTML table to present
+ data to the user in a logical manner. This structure is not available when
+ using the pre element.
+
+
+
+
Examples
+
+
Example 1: A schedule formatted with tabs between columns
+ <pre>
+ Monday Tuesday Wednesday Thursday Friday
+ 8:00-
+ 9:00 Meet with Sam
+ 9:00-
+ 10:00 Dr. Williams Sam again Leave for San Antonio
+ </pre>
+
+
+
Example 2: Election results displayed using preformatted text
+ <pre>
+ CIRCUIT COURT JUDGE BRANCH 3
+ W
+ R
+ M R E I
+ A . L T
+ M L R B E
+ I A Y E -
+ K N R I
+ E G T N
+ ----- ----- -----
+0001 TOWN OF ALBION WDS 1-2 22 99 0
+0002 TOWN OF BERRY WDS 1-2 52 178 0
+0003 TOWN OF BLACK EARTH 16 49 0
+0004 TOWN OF BLOOMING GROVE WDS 1-3 44 125 0
+0005 TOWN OF BLUE MOUNDS 33 117 0
+0006 TOWN OF BRISTOL WDS 1-3 139 639 1
+0007 TOWN OF BURKE WDS 1-4 80 300 0
+0008 TOWN OF CHRISTIANA WDS 1-2 22 50 0
+
+ </pre>
+
For each occurrence of the pre element, check
+ whether the enclosed information is tabular.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is true, then this failure condition applies and the
+ content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F49.html b/wcag21/techniques/failures/F49.html
new file mode 100644
index 0000000..75e480b
--- /dev/null
+++ b/wcag21/techniques/failures/F49.html
@@ -0,0 +1,257 @@
+
+
+
+
+ F49:
+ Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not
+ make sense when linearized
+
+
+
+
+
+
+
+
+
+ Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not
+ make sense when linearized
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are
+ recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content.
+ If a layout table is used, however, it is important that the content make sense when
+ linearized.
+
+
+
This failure occurs when a meaningful sequence of content conveyed through
+ presentation is lost because HTML tables used to control the visual
+ placement of the content do not “linearize" correctly. Tables present
+ content in two visual dimensions, horizontal and vertical. However, screen
+ readers present this two-dimensional content 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. The screen reader reads the table from
+ top to bottom, reading the entire contents of each row before moving to the
+ next row. The complete content of each cell in each row is spoken—including
+ the complete content of any table nested within a cell. This is called
+ linearization.
+
+
Suppose that a Web page is laid out using a table with 9 columns and 22 rows.
+ The screen reader speaks the content of the cell at Column 1, Row 1 followed
+ by the cells in columns 2, 3, 4 and so on to column 9. However, if any cell
+ contains a nested table, the screen reader will read the entire nested table
+ before it reads the next cell in the original (outer) table. For example, if
+ the cell at column 3, row 6 contains a table with 6 columns and 5 rows, all
+ of those cells will be read before Column 4, Row 6 of the original (outer)
+ table. As a result, the meaningful sequence conveyed through visual
+ presentation may not be perceivable when the content is spoken by a screen
+ reader.
+
+
+
+
Examples
+
+
Example 1: A layout table that does not linearize correctly
+
An advertisement makes clever use of visual positioning, but changes
+ meaning when linearized.
+
Example 2: A layout table that separates a meaningful sequence when linearized
+
A Web page from a museum exhibition positions a navigation bar
+ containing a long list of links on the left side of the page. To the
+ right of the navigation bar is an image of one of the pictures from
+ the exhibition. To the right of the image is the kind of "placard"
+ text you'd see on the wall next to the object if you were at the
+ museum. Below that text is a heading that says "Description," and
+ below that heading is a description of the image. The image, placard
+ text, Description heading, and text of the description form a
+ meaningful sequence.
+
+
A layout table is used to position the elements of the page. The
+ links in the navigation bar are split into different cells in the
+ leftmost column.
+
Because the navigation bar links are interleaved with the content
+ describing the image, screen readers cannot present the content in a
+ meaningful sequence corresponding to the sequence presented
+ visually.
+
Linearize the content in either of the following ways:
+
+
+
+
Present the content in source code order
+
+
Remove the table markup from around the content
+
+
+
+
+
+
Check that the linear reading order matches any meaningful
+ sequence conveyed through presentation.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is false, then this failure condition applies and the
+ content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F50.html b/wcag21/techniques/failures/F50.html
new file mode 100644
index 0000000..def54d8
--- /dev/null
+++ b/wcag21/techniques/failures/F50.html
@@ -0,0 +1,123 @@
+
+
+
+
+ F50: Failure of Success Criterion 2.2.2 due to a script that causes a blink effect without
+ a
+ mechanism to stop the blinking at 5 seconds or less
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.2 due to a script that causes a blink effect without
+ a
+ mechanism to stop the blinking at 5 seconds or less
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Technologies that support script-controlled blinking of content.
Scripts can be used to blink content by toggling the content's visibility on and off
+ at regular intervals. It is a failure for the script not to include a mechanism to
+ stop the blinking at 5 seconds or earlier. See SCR22: Using scripts to control blinking and stop it in five seconds or less for information about how to modify the technique to stop the blinking.
+
+
+
+
Examples
+
+
Example 1
+
The following example uses script to blink content, but the blink
+ continues indefinitely rather than stopping after five seconds.
+
+...
+<script type="text/javascript">
+<!--
+// blink "on" state
+function show()
+{
+ if (document.getElementById)
+ document.getElementById("blink1").style.visibility = "visible";
+ settime-out("hide()", 450);
+}
+// blink "off" state
+function hide()
+{
+ if (document.getElementById)
+ document.getElementById("blink1").style.visibility = "hidden";
+ settime-out("show()", 450);
+}
+// kick it off
+show();
+//-->
+</script>
+...
+<span id="blink1">This content will blink</span>
+
Determine if the blinking stops in 5 seconds or less.
+
+
+
+
+
+
Expected Results
+
+
If #1 is false, then the content fails the Success Criterion.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F52.html b/wcag21/techniques/failures/F52.html
new file mode 100644
index 0000000..76fb519
--- /dev/null
+++ b/wcag21/techniques/failures/F52.html
@@ -0,0 +1,140 @@
+
+
+
+
+ F52: Failure of Success Criterion 3.2.1 and 3.2.5 due to opening a new window as soon as
+ a new page is loaded
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.1 and 3.2.5 due to opening a new window as soon as
+ a new page is loaded
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Applies when scripting is used to open new windows.
Some Web sites open a new window when a page is loaded, to advertise a
+ product or service. The objective of this technique is to ensure that pages
+ do not disorient users by opening up one or more new windows that automatically attain
+ focus as soon as a
+ page is loaded.
+
+
+
+
Examples
+
+
Note
+
+
+
There are multiple methods by which this failure may be triggered. Two
+ common examples that are supported differently in various versions of
+ user agents are listed as examples below.
+
+
+
+
+
+
Example 1
+
The following example is commonly used in HTML 4.01 to open new
+ windows when pages are loaded.
+
check to see whether a new window has been opened as a result of
+ loading the new page
+
+
+
Check to see whether the new window is automatically given focus
+
+
+
+
+
+
Expected Results
+
+
+
+
If step 2 and step 3 are true, then this failure condition applies and
+ content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F54.html b/wcag21/techniques/failures/F54.html
new file mode 100644
index 0000000..f2327bc
--- /dev/null
+++ b/wcag21/techniques/failures/F54.html
@@ -0,0 +1,128 @@
+
+
+
+
+ F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event
+ handlers (including gesture) for a function
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event
+ handlers (including gesture) for a function
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Technologies that have event handlers specific to pointing devices.
When pointing device-specific event handlers are the only mechanism available
+ to invoke a function of the content, users with no vision (who cannot use
+ devices such as mice that require eye-hand coordination) as well as users
+ who must use alternate keyboards or input devices that act as keyboard
+ emulators will be unable to access the function of the content.
+
+
For Success Criterion 2.1.1 there is an exception for functions that require a path-dependant
+ pointer movement.
+
+
+
+
Examples
+
+
Example 1
+
The following example is of an image that responds to a mouse click
+ to go to another page. This is a failure because the keyboard cannot
+ be used to move to the next page.
+ <p><img onmousedown="nextPage();" src="nextarrow.gif"
+ alt="Go to next page"></p>
+
+
Check to see whether pointing-device-specific event handlers are the only means to
+ invoke scripting functions.
+
+
+
Check if the function being invoked requires input information about a specific path
+ for a pointing device
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is true, then this failure condition applies and content fails Success
+ Criterion 2.1.3.
+
+
+
If check #1 is true and check #2 is false, then this failure condition applies and
+ content fails Success Criteria 2.1.1 and 2.1.3.
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F55.html b/wcag21/techniques/failures/F55.html
new file mode 100644
index 0000000..98b9f14
--- /dev/null
+++ b/wcag21/techniques/failures/F55.html
@@ -0,0 +1,117 @@
+
+
+
+
+ F55:
+ Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove
+ focus when focus is received
+
+
+
+
+
+
+
+
+
+ Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove
+ focus when focus is received
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Content that normally receives focus when the content is accessed by keyboard may
+ have this focus removed by scripting. This is sometimes done when designer considers
+ the system focus indicator to be unsightly. However, the system focus indicator is
+ an important part of accessibility for keyboard users. In addition, this practice
+ removes focus from the content entirely, which means that the content can only be
+ operated by a pointing device such as a mouse.
+
Use the keyboard to verify that you can get to all interactive
+ elements using the keyboard.
+
+
+
Check that when focus is placed on each element, focus remains
+ there until user moves it.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If #2 is false then this failure condition applies and content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F58.html b/wcag21/techniques/failures/F58.html
new file mode 100644
index 0000000..48afb04
--- /dev/null
+++ b/wcag21/techniques/failures/F58.html
@@ -0,0 +1,179 @@
+
+
+
+
+ F58: Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically
+ redirect pages after a time-out
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically
+ redirect pages after a time-out
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Any server-side scripting language
+
+
Content does not meet the exceptions in the Success Criterion for
+ permitted time limits.
+
Server-side scripting languages allow developers to set the non-standard
+ HTTP header "Refresh" with a time-out (in seconds) and a URI to which the
+ browser is redirected after the specified time-out. If the time interval is
+ too short, people who are blind will not have enough time to make their
+ screen readers read the page before the page refreshes unexpectedly and
+ causes the screen reader to begin reading at the top. Sighted users may also
+ be disoriented by the unexpected refresh.
+
+
The HTTP header that is set is Refresh: {time in seconds}; url={URI of
+ new location}. It is also possible to omit the URI and obtain a
+ periodically refreshing page, which causes the same problem. The HTTP header
+ that is set is Refresh: {time in seconds}.
+
+
+
+
Examples
+
+
Example 1
+
The following example is a failure because a timed server-side
+ redirect is implemented in Java Servlets or JavaServer Pages
+ (JSP).
+
+public void doGet (HttpServletRequest request, HttpServletResponse response)
+ throws IOException, ServletException {
+ response.setContentType("text/html");
+ PrintWriter out = response.getWriter();
+ response.setHeader("Refresh", "10; URL=TargetPage.html");
+ out.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
+ \"https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">");
+ out.println("<html><head><title>Redirect</title></head><body>");
+ out.println("<p>This page will redirect you in 10 seconds.</p>");
+ out.println("</body></html>");
+ }
+
+
+
Example 2
+
The following example is a failure because a timed server-side
+ redirect is implemented in Active Server Pages (ASP) with VBScript.
+
+ <% @Language = "VBScript" %>
+ <% option explicit
+ Response.Clear
+ Response.AddHeader "Refresh", "5; URL=TargetPage.htm"
+ %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+ …
+ <!--HTML code for content that is shown before the redirect is triggered-->
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check if the user is provided an opportunity to turn off, extend, or adjust the timing
+ of the page refresh.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is true and checks #2-3 are false then this failure condition applies
+ and content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F59.html b/wcag21/techniques/failures/F59.html
new file mode 100644
index 0000000..fe10327
--- /dev/null
+++ b/wcag21/techniques/failures/F59.html
@@ -0,0 +1,169 @@
+
+
+
+
+ F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user
+ interface control in HTML without providing a role for the control
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.2 due to using script to make div or span a user
+ interface control in HTML without providing a role for the control
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure demonstrates how using generic HTML elements to create user
+ interface controls can make the controls inaccessible to assistive
+ technology. Assistive technologies rely on knowledge of the role and current
+ state of a component in order to provide that information to the user. Many
+ HTML elements have well defined roles, such as links, buttons, text fields,
+ etc. Generic elements such as div and span do not
+ have any predefined roles. When these generic elements are used to create
+ user interface controls in HTML the assistive technology may not have the
+ necessary information to describe and interact with the control.
+
+
+
+
Note
+
Attaching event handlers to elements that are not normally interactive, such
+ as span and div, can be disorienting to
+ users. Even if care is taken to provide keyboard access to such elements,
+ users may have a difficult time discovering that there are interactive
+ controls in the content or understanding what type of behavior to expect
+ from them. For example, users may not know which keystrokes are supported by
+ the script to activate the element. Additionally, these elements do not
+ generate the same operating system events as interactive elements, so
+ assistive technology may not be notified when the user activates them.
+
+
+
+
The W3C Candidate Recommendation "Accessible Rich Internet Applications (WAI-ARIA) 1.0" describes mechanisms to provide the necessary role and state information to create
+ fully accessible user interface controls.
+
+
+
+
Examples
+
+
Example 1
+
The following example fails because it creates a checkbox using a span and an image.
Here is the scripting code which changes the image source when the span is clicked with the mouse.
+
+ var CHECKED = "check.gif";
+ var UNCHECKED = "unchecked.gif";
+ function toggleCheckbox(imgId) {
+ var theImg = document.getElementById(imgId);
+ if ( theImg.src.lastIndexOf(CHECKED)!= -1 ) {
+ theImg.src = UNCHECKED;
+ // additional code to implement unchecked action
+ }
+ else {
+ theImg.src = CHECKED;
+ // additional code to implement checked action
+ }
+ }
A checkbox created in this manner will not work with assistive technology since there
+ is no information that identifies it as a checkbox. In addition, this example is also
+ not operable from the keyboard and would fail guideline 2.1.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Examine the parsed source code for elements which have event handlers assigned within
+ the mark-up or via scripting (indicating that the element is a user interface control).
+
+
+
Check if the role of the control is already defined natively in the mark-up language.
+
+
Check if another valid method, such as the assignment of a fitting WAI-ARIA role,
+ has been used to define the role of the control.
+
+
+
+
+
+
+
Expected Results
+
+
If check #2 AND check #3 are false, the failure condition applies.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F60.html b/wcag21/techniques/failures/F60.html
new file mode 100644
index 0000000..8b81786
--- /dev/null
+++ b/wcag21/techniques/failures/F60.html
@@ -0,0 +1,122 @@
+
+
+
+
+ F60: Failure of Success Criterion 3.2.5 due to launching a new window when a user enters
+ text into an input field
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.5 due to launching a new window when a user enters
+ text into an input field
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when a new window is created in
+ response to a user filling in a text field for other than error reporting.
+
+
+
+
+
Examples
+
+
Example 1
+
This is a deprecated example showing a failure: A user is filling in
+ his mailing address. When he fills in his postal code, a new window
+ opens containing advertisements for services available in his city.
+
+
+
+
+
Example 2
+
This example is acceptable: A user is filling in his mailing address
+ in a form. When he fills in the postal code field, a script runs to
+ validate that it is a valid postal code. If the value is not valid,
+ a window opens with instructions on how to fill in the field.
+
For any new windows that open, check if they contain an error
+ message and a button that closes the window returning focus to
+ the initiating form element.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If #3 is true and #4 is false then failure condition applies and
+ the content fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F61.html b/wcag21/techniques/failures/F61.html
new file mode 100644
index 0000000..ae71b3a
--- /dev/null
+++ b/wcag21/techniques/failures/F61.html
@@ -0,0 +1,183 @@
+
+
+
+
+ F61: Failure of Success Criterion 3.2.5 due to complete change of main content through
+ an
+ automatic update that the user cannot disable from within the content
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.5 due to complete change of main content through
+ an
+ automatic update that the user cannot disable from within the content
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when the content in the main viewport viewport is automatically updated, and there is no option for a user to disable this
+ behavior.
+
+
Two procedures are presented below to test for the existence of a failure against
+ Success Criterion 3.2.5. Procedure 1 is the preferred procedure and assumes that content
+ authors have access to the code that generates the viewport content.
+
+
However there may be instances where this may not be possible (eg: in certain content
+ management systems, application environments such as django or ruby-on-rails, or content
+ generated through scripting languages such as AJAX or PHP that are generated by third
+ parties.) To that end, the second procedure is supplied to allow testing in these
+ instances. Note that timeframes are indicative only, and that any change after any
+ amount of time should be treated as a failure if the test otherwise does not pass
+ the other step evaluations.
+
+
+
+
Examples
+
+
Example 1
+
A news site automatically refreshes itself to ensure that it has the
+ newest headlines. There is no option to disable this behavior.
+
+
+
+
Example 2
+
A slideshow fills the entire viewport and advances to the next slide
+ automatically. There is no stop button.
+
+
+
+
Example 3
+
A search engine automatically generates results and dynamically updates content based
+ on user input. There is no option to disable this behavior.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Open the source code in an appropriate editing tool.
+
+
Examine the source code thoroughly.
+
+
Confirm that content is dynamically generated or the code will trigger a change of
+ context for the viewport on an event or after a time period.
+
+
+
Confirm that there does not exist an appropriate mechanism for users to disable this
+ behavior.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If both checks 3 and 4 are true, then this failure condition applies and the content
+ fails this Success Criterion
+
+
+
+
+
+
+
Procedure
+
+
+
+
Measure or estimate the amount of time that the average user spends on the page.
+
+
Go to the page
+
+
Wait for 10 times the length of time the average user stays on the page. (From Step
+ 1)
+
+
+
Check to see if there is a change in context during this time.
+
+
If there is no change of context STOP.
+
+
If there is a change in context, then check to see if there is any mechanism on the
+ page that would have prevented that change of context.
+
+
+
If there IS a mechanism for preventing that change of context, use that mechanism
+ to prevent that change of context and run the test over.
+
+
+
If there is a change of context and there are no mechanism to prevent that change
+ in context then you have a failure.
+
+
+
+
+
+
Note
+
+
+
One way to measure or estimate the amount of time in step 1 would be to check a web
+ site's analytics to see how long the average user looks at the page.
+
+
+
An example of step 6 would be a mechanism for turning off auto updates.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If you reach step 8 then the content fails this success criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F63.html b/wcag21/techniques/failures/F63.html
new file mode 100644
index 0000000..edf2f98
--- /dev/null
+++ b/wcag21/techniques/failures/F63.html
@@ -0,0 +1,168 @@
+
+
+
+
+ F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that
+ is not related to the link
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.4 due to providing link context only in content that
+ is not related to the link
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition when the context needed for understanding the purpose
+ of a link is located in content that is not programmatically determined link context.
+ If the context for the link is not provided in one of the following ways:
+
+
+
+
in the same sentence, paragraph, list item, or table cell as the link
+
+
via a suitable ARIA property such as aria-label or aria-labelledby
+
+
+
+
+
then the user will not be able to find out where the link is going with any ease.
+ If the user must leave the link to search for the context, the context is not programmatically
+ determined link context and this failure condition occurs.
+
+
+
+
Examples
+
+
Example 1: A Link in an Adjacent Paragraph
+
+ A news service lists the first few sentences of an article in a paragraph. The next
+ paragraph contains the link "Read More...". Because the link is not in the same paragraph
+ as the lead sentence, the user cannot easily discover what the link will let the user
+ read more about.
+
+<p>A British businessman has racked up 2 million flyer miles and plans to
+travel on the world's first commercial tourism flights to space.</p>
+
+<p><a href="ff.html">Read More...</a></p>
+
+
+
Example 2: A Link in an Adjacent Cell Within a Layout Table
+
An audio site provides links to where its player can be downloaded. The information
+ about what would be downloaded by the link is in the preceding row of the layout table,
+ which is not programmatically determined context for the link.
+
Locate links where some additional link context is needed to understand the purpose
+ of the link. For each link:
+
+
+
+
+
Check whether the context is contained in the same sentence, paragraph, list item,
+ table cell, or associated table headers.
+
+
+
Check whether the link context can be programmatically determined in some other way,
+ for example, by using a WAI-ARIA property such as aria-label, aria-labelledby or aria-describedby on the link to provide sufficient context
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 AND check #2 are false, the content fails the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F65.html b/wcag21/techniques/failures/F65.html
new file mode 100644
index 0000000..884f477
--- /dev/null
+++ b/wcag21/techniques/failures/F65.html
@@ -0,0 +1,162 @@
+
+
+
+
+ F65: Failure of Success Criterion 1.1.1 due to omitting the alt attribute or text alternative
+ on img elements, area elements, and input elements of type "image"
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to omitting the alt attribute or text alternative
+ on img elements, area elements, and input elements of type "image"
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition for text alternatives on images. If there is no
+ source of text to provide an alternative for the image then assistive technologies
+ are not able to identify the image or to convey its purpose to the user. The alt attribute continues to be the preferred way to provide alternative text for images.
+ Appropriate WAI-ARIA attributes may be used to provide alternative text, as long as
+ they are accessibility supported. For more information about accessibility support,
+ see Documenting Accessibility Support. The Accessible Name and Description Computation described the method of deriving text alternative from the HTML and WAI-ARIA attributes
+ of an element.
+
+
+ Some Assistive Technologies attempt to compensate for the missing text alternatives
+ by reading the file name of the image. But it is insufficient to rely simply on the
+ file name for many reasons. For example, file names may not be descriptive (e.g.,
+ images/nav01.gif), and technology specifications do not require descriptive file names.
+ And some Assistive Technologies do not read the file name if there is no text alternative
+ provided via HTML attributes.
+
+
+
+
+
Examples
+
+
Example 1: Missing text alternative
+
In the code example below, the person using a screen reader would not know the purpose
+ of the image.
+
+<img src="../images/animal.jpg" />
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Identify img, area and input elements of type image. For each of these elements:
+
+
+
+
+
+ Check if the alt attribute is present.
+
+
+
+
+
+ Check if aria-labelledby attribute is present AND references one or more id elements in the page AND check
+ if aria-labelledby is accessibility supported.
+
+
+
+
+ Check if the aria-label attribute is present AND check if aria-label is accessibility supported.
+
+
If all of #1, #2, #3 and #4 are false then this failure condition applies.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F66.html b/wcag21/techniques/failures/F66.html
new file mode 100644
index 0000000..3c3fcb9
--- /dev/null
+++ b/wcag21/techniques/failures/F66.html
@@ -0,0 +1,138 @@
+
+
+
+
+ F66: Failure of Success Criterion 3.2.3 due to presenting navigation links in a different
+ relative order on different pages
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.3 due to presenting navigation links in a different
+ relative order on different pages
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition for all techniques involving navigation mechanisms
+ that are repeated on multiple Web pages within a set of Web pages (Success Criterion
+ 3.2.3). If the mechanism presents the order of links in a different order on two or
+ more pages, then the failure is triggered.
+
+
+
+
+
Examples
+
+
Example 1: An XHTML menu presenting a series of links that are in a different relative
+ order on two different pages
+
+
Examples of a navigation mechanism that presents links in a different order.
+ Check to see if a navigation mechanism is being used on more than one Web page.
+
+
+
+
+ Check the default presentation of the navigation mechanism on each page to see if
+ the list of links are in the same relative order on each Web page.
+
+
+
+
+
+
+
Note
+
+
+
"Same relative order" means that secondary navigation items may be in between the
+ link items on some pages. They can be present without affecting the outcome of this
+ test.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
+ If #1 is true and #2 is false, then this failure condition applies and content fails
+ the Success Criterion.
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F67.html b/wcag21/techniques/failures/F67.html
new file mode 100644
index 0000000..f7ea0ca
--- /dev/null
+++ b/wcag21/techniques/failures/F67.html
@@ -0,0 +1,136 @@
+
+
+
+
+ F67: Failure of Success Criterion 1.1.1 and 1.2.1 due to providing long descriptions for
+ non-text content that does not serve the same purpose or does not present the same
+ information
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 and 1.2.1 due to providing long descriptions for
+ non-text content that does not serve the same purpose or does not present the same
+ information
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe the failure that occurs when the long
+ description for non-text content does not serve the same purpose or does not present
+ the same information as the non-text content. This can cause problems for people
+ who cannot interpret the non-text content because they rely on the long description
+ to provide the necessary information conveyed by the non-text content. Without a
+ long description that provides complete information, a person may not be able to comprehend
+ or interact with the Web page.
+
+
+
+
+
Examples
+
+
+
An image showing the locations of venues for events at the Olympic Games displayed
+ on a street map. The image also contains an icon for each type of sporting event held
+ at each venue. The long description states, "Map showing the location of each Olympic
+ venue. Skating, hockey and curling are held at the Winter Park Ice Arena, Downhill
+ skiing and jumping are held at Snow Mountain, Gymnastics is held at the JumpUp Arena,
+ Cross Country Skiing is held at the Kilometer Forest". While this description provides
+ useful information, it does not convey the same information as the image because it
+ provides no specific location information such as the address or the distance of each
+ location from some fixed point. Note that long descriptions do not always need to
+ be in prose form; sometimes the information may best be presented in a table or other
+ alternate format.
+
+
For all non-text content that requires a long description
+
+
+
+
Check that the long description serves the same purpose or presents the same information
+ as the non-text content.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is false, then this failure condition applies and the content fails this
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F68.html b/wcag21/techniques/failures/F68.html
new file mode 100644
index 0000000..f1c330f
--- /dev/null
+++ b/wcag21/techniques/failures/F68.html
@@ -0,0 +1,247 @@
+
+
+
+
+ F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically
+ determined name
+
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically
+ determined name
+
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure describes a problem that occurs when a form control does not have a name
+ exposed to assistive technologies. The result is that some users will not be able
+ to identify the purpose of the form control. The name can be provided in multiple
+ ways, including the label element. Other options include use of the title attribute and aria-label which are used to directly provide text that is used for the accessibility name or
+ aria-labelledby which indicates an association with other text on a page that is providing the name.
+ Button controls can have a name assigned in other ways, as indicated below, but in
+ certain situations may require use of label, title, aria-label, or aria-labelledby.
+
+
+
Note
+
+
+
Elements that can use an explicitly-associated label element are:
+
+
+
+
+
+ input
+
+
+
+
+ textarea
+
+
+
+
+ select
+
+
+
+
+
+
The label element is not used for the following because labels for these elements are provided
+ via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button):
+
+
+
+
+
Submit and Reset buttons (input type="submit" or input type="reset")
+
+
Image buttons (input type="image")
+
+
Hidden input fields (input type="hidden")
+
+
Buttons (button elements or <input type="button">)
+
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
The following example demonstrates a form that visually presents labels for form controls,
+ but does not use the label element to associate them with their controls. The code example below is a failure
+ because assistive technology may not be able to determine which label goes with which
+ control.
+
+<form>
+ First name:
+ <input type="text" name="firstname">
+ <br>
+ Last name:
+ <input type="text" name="lastname">
+ <br>
+ I have a dog <input type="checkbox" name="pet" value="dog">
+ I have a cat <input type="checkbox" name="pet" value="cat">
+</form>
+
+
+
Example 2
+
In the following code example, label elements are present, but they are not programmatically linked to the corresponding
+ input controls and may therefore not be properly determined by assistive technology.
+
The search text box in the following code example does not have a programmatically
+ determinable name. The name can be supplied with any of the approaches mentioned above.
+
+<input type="text" value="Type your search here"><input type="submit" type="submit" value="Search">
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
For all input, textarea and select elements in the Web page (except inputs of type hidden, submit, reset, or button:
+
+
+
+
+
+
+
Check that each element has a programmatically determined name using one of the following
+ ways:
+
+
+
+
+
the text label or labels are programmatically associated with the control element
+ via the aria-labelledby attribute (each id given as a value in the aria-labelledby attribute matches the id of the text label element).
+
+
+
the control is programmatically determined through the value of its aria-label attribute.
+
+
+
the text label is contained in a label element that is correctly associated to the respective input element via the label's for attribute (the id given as value in the for attribute matches the id of the input element).
+
+
+
the control is contained within a label element that also contains the label text.
+
+
+
the control is an input of typeimage and the alt attribute provides a text label.
+
+
+
the control is programmatically determined through the value of title attribute.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If all options of check #1 are false, then this failure condition applies and the
+ content fails the Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F69.html b/wcag21/techniques/failures/F69.html
new file mode 100644
index 0000000..318dace
--- /dev/null
+++ b/wcag21/techniques/failures/F69.html
@@ -0,0 +1,165 @@
+
+
+
+
+ F69: Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200
+ percent causes the text, image or controls to be clipped, truncated or obscured
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200
+ percent causes the text, image or controls to be clipped, truncated or obscured
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure condition is to describe a problem that occurs when
+ changing the size of text causes text to be clipped, truncated, or obscured, so that
+ it is no longer available to the user. In general, this failure occurs when there
+ is no way for a user agent's layout engine to honor all the layout hints in the HTML
+ at the new font size. Some of the ways in which this can occur include:
+
+
+
+
Setting the overflow property of the enclosing element to hidden
+
+
+
+
Using absolutely positioned content
+
+
Creating popups that aren't big enough for their content at the new font size
+
+
+
+
Note
+
+
+
The Working Group has discovered many misunderstandings about how to test this failure.
+ We are planning to revise this failure in a future update. Until then, if the content
+ passes the success criterion using any of the listed sufficient techniques, then it
+ does not meet this failure.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
The font size is set in a scalable way, but the container is set to a fixed pixel
+ size. A gray border shows the boundaries of the text container. When the text is resized,
+ it spills out of its container, and obsures the next paragraph.
+
+<div style="font-size:100%; width:120px; height:100px; border: thin solid gray;">
+ Now is the time for all good men to come to the aid of their country.
+</div>
+<p>Now is the time for all good men to come to the aid of their country.</p>
+
Illustration of example 1:
+
+
+
+
Example 2
+
This example is identical to the last one, except that the container is set to clip
+ the text. The text is no longer bleeding into the next paragraph, but now it is truncated.
+ This is also a failure.
+
+<div style="font-size:100%; width:120px; height:100px; overflow: hidden; border: thin solid gray;">
+ Now is the time for all good men to come to the aid of their country.
+</div>
+<p>Now is the time for all good men to come to the aid of their country.</p>
+
Illustration of example 2:
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
Note
+
+
+
The Working Group has discovered many misunderstandings about how to test this failure.
+ We are planning to revise this failure in a future update. Until then, if the content
+ passes the success criterion using any of the listed sufficient techniques, then it
+ does not meet this failure.
+
+
+
+
+
+
+
+
Increase the text size of the content by 200%.
+
+
Check that no text is clipped, truncated, or obscured.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is false, then the failure condition applies and the content fails these
+ Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F7.html b/wcag21/techniques/failures/F7.html
new file mode 100644
index 0000000..fad584e
--- /dev/null
+++ b/wcag21/techniques/failures/F7.html
@@ -0,0 +1,118 @@
+
+
+
+
+ F7: Failure of Success Criterion 2.2.2 due to an object or applet, such as Java or Flash,
+ that has blinking content without a mechanism to pause the content that blinks
+ for more than five seconds
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.2.2 due to an object or applet, such as Java or Flash,
+ that has blinking content without a mechanism to pause the content that blinks
+ for more than five seconds
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Technologies that support blinking content within an object, applet, or a
+ plug-in.
+
When content that is rendered by a plug-in or contained in an applet blinks,
+ there may be no way for the user agent to pause the blinking. If neither the
+ plug-in, applet, nor the content itself provides a mechanism to pause the
+ content, the user may not have sufficient time to read the content between
+ blinks or it may be so distracting that the user will not be able to read
+ other content on the page.
+
+
+
+
Examples
+
+
+
An applet displays an advertisement on a news site. The applet blinks
+ key words in the advertisement in order to call the user's attention
+ to it. The blinking cannot be paused through any user agent settings
+ and the applet does not provide a mechanism to stop it.
+
For each page that has blinking content in a plugin or applet:
+
+
+
+
Determine if the content continues to blink for longer than 5
+ seconds.
+
+
+
Determine if there is a means to pause the blinking content.
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is true and step #2 is false, the content fails the success
+ criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F70.html b/wcag21/techniques/failures/F70.html
new file mode 100644
index 0000000..e11fa2d
--- /dev/null
+++ b/wcag21/techniques/failures/F70.html
@@ -0,0 +1,155 @@
+
+
+
+
+ F70: Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute
+ markup
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute
+ markup
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Markup languages: HTML, XHTML, and other SGML or XML-based technologies.
The objective of this failure is to identify examples of markup errors in element
+ tags that could cause assistive technology to be unable to generate a satisfactory
+ model of the page. Different user agents may implement different heuristics to recover
+ from errors, resulting in inconsistent presentations of the page between user agents.
+
+
Some common types of problems with start and end tags that lead to this failure condition
+ (though this is not an exhaustive list):
+
+
+
+
Opening and closing tags that are missing the opening < and closing > brackets.
+
+
Closing tag missing the initial / to indicate it is a closing tag.
+
+
Attribute values that have an opening quote but not a closing quote. Attribute values
+ must be either fully quoted or, in some markup languages, may be unquoted.
+
+
+
Lack of whitespace between attributes.
+
+
Unquoted attribute values that have whitespace in the value.
+
+
Failure to provide a closing element tag for elements that do not accept empty-element
+ syntax.
+
+
+
+
+
+
Examples
+
+
Example 1: Missing angle brackets in XHTML
+
The following code fails because the opening tag is missing an angle bracket, and
+ the intended boundary of the tag is unclear.
+
+<p This is a paragraph</p>
+
+
+
Example 2: Missing slash on closing tag in XHTML
+
The following code fails because the closing tag is missing the slash, making it look
+ like it is in fact another opening tag.
+
+<p>This is a paragraph<p>
+
+
+
Example 3: Unbalanced attribute quoting
+
The following code fails because the attribute value is missing the closing quote,
+ which makes the boundary of the attribute-value pair unclear.
+
+<input title="name type="text">
+
+
+
Example 4: Lack of whitespace between attributes
+
The following code fails because the there is not whitespace between attributes, which
+ makes the boundary between attribute-value pairs unclear.
+
+<input title="name"type="text">
+
+
+
Example 5: Unquoted attribute with whitespace value
+
The following code fails because an attribute value is not quoted and contains whitespace,
+ which makes the boundary of the attribute-value pair unclear.
+
+<input title=Enter name here type=text>
+
+
+
Example 6: Missing end tags in XHTML
+
The following code fails because the closing tag of the first paragraph is missing,
+ making it unclear whether the second paragraph is a child or sibling of the first.
+
+<p>This is a paragraph
+<p>This is another paragraph</p>
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check the source code of pages implemented in markup languages.
+
+
Check whether any opening tags, closing tags or attributes are malformed.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is true, then the failure condition applies and the content does not meet
+ this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F71.html b/wcag21/techniques/failures/F71.html
new file mode 100644
index 0000000..a63e07a
--- /dev/null
+++ b/wcag21/techniques/failures/F71.html
@@ -0,0 +1,128 @@
+
+
+
+
+ F71: Failure of Success Criterion 1.1.1 due to using text look-alikes to represent text
+ without providing a text alternative
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to using text look-alikes to represent text
+ without providing a text alternative
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure condition is to avoid substituting characters whose
+ glyphs look similar to the intended character, for that intended character. The Unicode
+ character set defines thousands of characters, covering dozens of writing systems.
+ While the glyphs for some of these characters may look like the glyphs for other characters
+ in visual presentation, they are not processed the same by text-to-speech tools.
+
+
For example, the characters U+0063 and U+03F2 both look like the letter "c", yet the
+ first is from the Western alphabet and the second from the Greek alphabet and not
+ used in Western languages. The characters U+0033 and U+04E0 both look like the number
+ "3", yet the second is actually a letter from the Cyrillic alphabet.
+
+
+
Note
+
+
+
This failure also applies to the use of character entities. It is the incorrect character
+ used because of its glyph representation that comprises a failure, not the mechanism
+ by which that character is implemented.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Characters
+
The following word looks, in browsers with appropriate font support, like the English
+ word "cook", yet is composed of the string U+03f2 U+043E U+03BF U+006B, only one of
+ which is a letter from the Western alphabet. This word will not be processed meaningfully,
+ and a text alternative is not provided.
+
+ϲоοk
+
+
+
Example 2: Character entities
+
The following example, like the one above, will look like the English word "cook"
+ when rendered in browsers with appropriate font support. In this case, the characters
+ are implemented with character entities, but the word will still not be processed
+ meaningfully, and a text alternative is not provided.
+
+ϲоοk
+
Working Example: "ϲоοk"
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check the characters or character entities used to represent text.
+
+
If the characters used do not match the appropriate characters for the displayed glyphs
+ in the human language of the content, then look-alike glyphs are being used.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If look-alike glyphs are used, and there is not a text alternative for any range of
+ text that uses look-alike glyphs, then the content does not meet the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F72.html b/wcag21/techniques/failures/F72.html
new file mode 100644
index 0000000..f694129
--- /dev/null
+++ b/wcag21/techniques/failures/F72.html
@@ -0,0 +1,113 @@
+
+
+
+
+ F72: Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text
+ alternative
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text
+ alternative
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure condition is to avoid the use of ASCII art when a text alternative is not provided. Although ASCII art is implemented as a character
+ string, its meaning comes from the pattern of glyphs formed by a visual presentation
+ of that string, not from the text itself. Therefore ASCII art is non-text content
+ and requires a text alternative. Text alternatives, or links to them, should be placed
+ near the ASCII art in order to be associated with it.
+
+
+
+
Examples
+
+
Example 1: ASCII Art chart without a text alternative
+
The following ASCII art chart lacks a text alternative and therefore does not meet
+ Success Criterion 1.1.1. Note this failure example does in fact cause this page to
+ fail, but you may skip over the example.
+
For each instance of ASCII art, check that it has a text alternative.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is false, then this failure condition applies and the content fails this
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F73.html b/wcag21/techniques/failures/F73.html
new file mode 100644
index 0000000..86ee132
--- /dev/null
+++ b/wcag21/techniques/failures/F73.html
@@ -0,0 +1,177 @@
+
+
+
+
+ F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident
+ without color vision
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.1 due to creating links that are not visually evident
+ without color vision
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure is to avoid situations in which people who cannot perceive
+ color differences cannot identify links (when people with color vision can identify
+ links). Link underlines or some other non-color visual distinction are required (when
+ the links are discernible to those with color vision).
+
+
While some links may be visually evident from page design and context, such as navigational
+ links, links within text are often visually understood only from their own display
+ attributes. Removing the underline and leaving only the color difference for such
+ links would be a failure because there would be no other visual indication (besides
+ color) that it is a link.
+
+
+
Note
+
+
+
Red and Pink are the same color (hue) but they have different lightness (which is
+ not color ). So red and pink would pass the requirement for "not distinguished by
+ color (hue) alone" since they differ by lightness (which is not color) - as long as
+ the difference in lightness (contrast) is 3:1 or greater. For example, if surrounding
+ text is RED and the link is PINK it would pass. Similarly a light green and a dark
+ red differ BOTH by color AND by lightness so they would pass if the contrast (lightness)
+ difference is 3:1 or greater before focus or pointing.
+
+
+
There is no requirement that links be identifiable by people who cannot perceive color
+ if they are not perceivable for those with color vision. (e.g. if the links are hidden
+ for everyone – as in a game or test).
+
+
+
If the non-color cue only happens when the mouse hovers over the link or when the
+ link receives focus, it is still a failure.
+
+
+
If the link is a different color and bold it would not fail because the boldness is
+ not color dependent.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
A Web page includes a large number of links within the body text. The links are styled
+ so that they do not have underlines and are very similar in color to the body text.
+ This would be a failure because users would be unable to differentiate the links from
+ the body text.
+
+
+
+
Example 2
+
The following code is an example of removing the underline from a link in a sentence
+ or paragraph without providing another visual cue besides color.
+
+<head>
+<style type="text/css">
+p a:link {text-decoration: none}
+p a:visited {text-decoration: none}
+p a:active {text-decoration: none}
+p a:hover {text-decoration: underline; color: red;}
+</style>
+</head>
+
+<body>
+
+<p>To find out more about the <a href="rain_in_spain.htm">rain in spain</a>there are many resources.</p>
+
+</body>
+
+
Note
+
+
+
If the visual cue is only provided on hover (as in the example above), it would still
+ fail.
+
+
Check that each link in the page that is identifiable by color (hue) is visually identifiable
+ via some other means (e.g., underlined, bolded, italicized, sufficient difference
+ in lightness, etc).
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false, then this failure condition applies and the content fails this
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F74.html b/wcag21/techniques/failures/F74.html
new file mode 100644
index 0000000..93affed
--- /dev/null
+++ b/wcag21/techniques/failures/F74.html
@@ -0,0 +1,112 @@
+
+
+
+
+ F74: Failure of Success Criterion 1.2.2 and 1.2.8 due to not labeling a synchronized media
+ alternative to text as an alternative
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.2.2 and 1.2.8 due to not labeling a synchronized media
+ alternative to text as an alternative
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Pages that provide synchronized media alternatives to text.
The objective of this failure is to avoid situations in which synchronized media alternatives
+ are not labeled with the text for which they are alternatives. Synchronized media
+ alternatives provide enhanced access to users for whom synchronized media is a more
+ effective format than text. Since they are alternatives to text, they do not need
+ themselves to have redundant text alternatives. However, they need to be clearly labeled
+ with the text for which they substitute, so users can find them and so users who normally
+ expect text alternatives to synchronized media know not to look for them.
+
+
+
+
Examples
+
+
Example 1: Synchronized media alternatives provided elsewhere on page
+
A page with instructions to complete a tax form provides a prose description of the
+ fields to complete, data to provide, etc. Additionally, a synchronized media alternative
+ provides spoken instructions, with video of a person completing the section being
+ discussed in the audio. Although both versions are provided on the page, the synchronized
+ media version is provided elsewhere on the page and is not clearly labeled with the
+ part of the text for which it is a substitute. This makes it difficult for users encountering
+ the text to find it, and users encountering the video do not know where its text alternative
+ is.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check pages that provide synchronized media alternatives to text.
+
+
Check that synchronized media is clearly labeled with the text for which it is an
+ alternative.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is false, then this failure condition applies and the content fails these
+ Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F75.html b/wcag21/techniques/failures/F75.html
new file mode 100644
index 0000000..63d78f6
--- /dev/null
+++ b/wcag21/techniques/failures/F75.html
@@ -0,0 +1,109 @@
+
+
+
+
+ F75: Failure of Success Criterion 1.2.2 by providing synchronized media without captions
+ when the synchronized media presents more information than is presented on the page
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.2.2 by providing synchronized media without captions
+ when the synchronized media presents more information than is presented on the page
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure is to avoid situations in which synchronized media alternatives
+ provide more information than the text for which they are alternatives, but do not
+ provide their own text alternatives to provide access to the extra information. Synchronized
+ media alternatives provide enhanced access to users for whom synchronized media is
+ a more effective format than text. Since they are alternatives to text, they do not
+ need themselves to have redundant text alternatives in the form of captions, audio
+ descriptions or full text alternatives. However, if they provide more information
+ than the text for which they are an alternative, then they are not just alternatives
+ but are synchronized media content in their own right. In this case they are subject
+ to the full requirements of Success Criterion 1.2.2 to provide captions and to Success Criterion 1.2.3 and 1.2.5.
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
Check for captions on synchronized media alternatives.
+
+
+
+
Check that the synchronized media alternative does not provide more information than
+ is presented on the page in text.
+
+
+
+
Note
+
+
+
Synchronized media alternatives often use different words to present what is on the
+ page but it should not present new information on the topic of the page.
+
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is false, then this failure condition applies and the content fails these
+ Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F77.html b/wcag21/techniques/failures/F77.html
new file mode 100644
index 0000000..ea5f343
--- /dev/null
+++ b/wcag21/techniques/failures/F77.html
@@ -0,0 +1,155 @@
+
+
+
+
+ F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.1 due to duplicate values of type ID
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
HTML, and any XML-based markup languages including XHTML and SVG
This describes a failure condition where duplicate ID errors are known to cause problems
+ for assistive technologies when they are trying to interact with content. Duplicate
+ values of type ID can be problematic for user agents that rely on this attribute to
+ accurately convey relationships between different parts of content to users. For example,
+ a screen reader may use ID values to identify the applicable header content for a
+ data cell within a data table, or an input control to which a given label applies.
+ If these values are not unique, the screen reader will be unable to programmatically
+ determine which headers are associated with the data cell or which control is associated
+ with which label or name.
+
+
Checking that ID attribute values are unique within a document can be done by validating
+ the document against its specification, because the specification defines which attributes
+ contain document-wide unique identifiers.
+
+
+
Note
+
+
+
In most markup languages, ID values are attribute values, for example in HTML and
+ SVG.
+
+
+
XML documents that use only the xml:id attribute as an ID attribute, parsing the XML
+ document with a validating parser that supports the xml:id specification is sufficient.
+
+
+
+
+
+
+
Examples
+
+
Example 1
+
An author uses an online validation service to check that all id attribute values
+ are unique.
+
+
+
+
Example 2
+
A developer utilizes features in their authoring tool to ensure that id attribute
+ values are unique.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that all values of type ID are unique in the Web page
+
+
+
+
+
+
Expected Results
+
+
+
+
If Step #1 is false, then this failure condition applies and the content fails the
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F78.html b/wcag21/techniques/failures/F78.html
new file mode 100644
index 0000000..4b705ba
--- /dev/null
+++ b/wcag21/techniques/failures/F78.html
@@ -0,0 +1,114 @@
+
+
+
+
+ F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in
+ a way that removes or renders non-visible the visual focus indicator
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.7 due to styling element outlines and borders in
+ a way that removes or renders non-visible the visual focus indicator
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition that occurs when the user agent's default visual
+ indication of keyboard focus is turned off or rendered non-visible by other styling
+ on the page without providing an author-supplied visual focus indicator. Turning off
+ the focus indicator instructs the user agent not to present the focus indicator. Other
+ styling may make it difficult to see the focus indicator even though it is present,
+ such as outlines that look the same as the focus outline, or thick borders that are
+ the same color as the focus indicator so it cannot be seen against them.
+
+
+
+
Examples
+
+
Example 1: The focus indicator is turned off with CSS
+
The following CSS example will remove the default focus indicator, which fails the
+ requirement to provide a visible focus indicator.
+
:focus {outline: none}
+
+
Example 2: The outline of elements is visually similar to the focus indicator
+
The following CSS example will create an outline around links that looks the same
+ as the focus indicator. This makes it impossible for users to determine which one
+ in fact has the focus, even though the user agent does draw the focus indicator.
+
a {outline: thin dotted black}
+
+
Example 3: Elements have a border that occludes the focus indicator
+
The following CSS example creates a border around links that does not have enough
+ contrast for the focus indicator to be seen when drawn on top of it. In this case
+ the focus indicator is drawn just ouside the border, but as both are black and the
+ border is thicker than the focus indicator, it no longer meets the definition of "visible".
+
a {border: medium solid black}
+
+
+
Tests
+
+
Procedure
+
+
+
+
Set the focus to all focusable elements on a page using the keyboard.
+
+
Check that the focus indicator is visible.
+
+
+
+
+
+
Expected Results
+
+
+
+
#2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F79.html b/wcag21/techniques/failures/F79.html
new file mode 100644
index 0000000..d457f36
--- /dev/null
+++ b/wcag21/techniques/failures/F79.html
@@ -0,0 +1,124 @@
+
+
+
+
+ F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component
+ not being programmatically determinable or no notification of change of focus state
+ available
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.2 due to the focus state of a user interface component
+ not being programmatically determinable or no notification of change of focus state
+ available
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Whether a user interface component has focus is a particularly important facet of
+ its state. Many types of assistive technology rely on tracking the current keyboard
+ focus. Screen readers will move the user's point of regard to the focused user interface
+ component, and screen magnifiers will change the display of the content so that the
+ focused component is visible. If assistive technology is not notified when focus moves
+ to a new component, the user will become confused when they attempt to interact with
+ the wrong component.
+
+
While user agents usually handle this functionality for standard controls, custom-scripted
+ user interface components are responsible for using accessibility APIs to make focus
+ information and notifications available.
+
+
+
+
Examples
+
A custom menu displays menu items by rendering them explicitly, handling mouse and
+ key events directly and highlighting the currently selected menu item. The programmer
+ does not expose the menu item that has focus via the Accessibility API, so assistive
+ technology can only determine that focus is somewhere within the menu and cannot determine
+ which menu item has focus.
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Using the accessibility checker for the technology (or if that is not available, inspect
+ the code or test with an assistive technology), check the controls to see if they
+ expose the focus state through the accessibility API.
+
+
+
Using the accessibility checker for the technology (or if that is not available, inspect
+ the code or test with an assistive technology), check whether assistive technology
+ is notified when focus moves from one control to another.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If Check #1 or Check #2 is false, then this failure condition applies and the content
+ fails this Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F8.html b/wcag21/techniques/failures/F8.html
new file mode 100644
index 0000000..1f36d1d
--- /dev/null
+++ b/wcag21/techniques/failures/F8.html
@@ -0,0 +1,110 @@
+
+
+
+
+ F8: Failure of Success Criterion 1.2.2 due to captions omitting some dialogue or important
+ sound effects
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.2.2 due to captions omitting some dialogue or important
+ sound effects
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition for all techniques involving captions. If
+ the "caption" does not include all of the dialogue (either verbatim or in
+ essence) as well as all important sounds then the 'Captions' are not real
+ captions.
+
+
NOTE: Captions sometimes simplify the spoken text both to make it easier to
+ read and to avoid forcing the viewer to read at very high speed. This is
+ standard procedure and does not invalidate a caption.
+
+
+
+
Examples
+
+
Example 1
+
Examples of text streams that are not captions include:
+
+
+
text that contains the dialogue (possibly simplified dialogue) but that does not describe
+ important sounds
+
+
+
+
text that omits dialogue during portions of the material
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
View the material with captioning turned on.
+
+
Check that all dialogue is accompanied by a caption.
+
+
Check that all important sounds are captioned.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 and check #3 are false, then this failure condition applies and the content
+ fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F80.html b/wcag21/techniques/failures/F80.html
new file mode 100644
index 0000000..ef6cdf9
--- /dev/null
+++ b/wcag21/techniques/failures/F80.html
@@ -0,0 +1,110 @@
+
+
+
+
+ F80: Failure of Success Criterion 1.4.4 when text-based form controls do not resize when
+ visually rendered text is resized up to 200%
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.4 when text-based form controls do not resize when
+ visually rendered text is resized up to 200%
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this failure condition is to describe a problem that occurs when
+ changing the size of text does not cause the text-based form controls to resize accordingly.
+ This means that the user may have difficulty entering text and being able to read
+ what they have entered because the text is not displayed at the text size required
+ by the user.
+
+
Text-based form controls include input boxes (text and textarea) as well as buttons.
+
+
+
Examples
+
+
Example 1: A Contact Form
+
A Contact Us form has some introductory information and then form controls for users
+ to enter their first name, last name, telephone number and email address. The heading,
+ introductory text and form control labels have been implemented in a scalable way
+ but the form controls themselves have not.
+
+
The XHTML component:
<h1>Contact Us</h1>
+ <p>Please provide us with your details and we will contact you as soon as we can. Note that all of the form fields are required.</p>
+ <label for="fname">First Name</label><input type="text" name="fname" id="fname" /><br />
+ <label for="lname">Last Name</label><input type="text" name="lname" id="lname" /><br />
+ <label for="phone">Telephone</label><input type="text" name="phone" id="phone" /><br />
+ <label for="email">Email</label><input type="text" name="email" id="email" /><br />
+ <input type="submit" name="Submit" value="Submit" id="Submit" />
Enter some text into text-based form controls that receive user entered text.
+
+
Increase the text size of the content by 200%.
+
+
Check that the text in text-based form controls has increased by 200%.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #3 is false, then the failure condition applies and the content fails these
+ Success Criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F81.html b/wcag21/techniques/failures/F81.html
new file mode 100644
index 0000000..07dc2f7
--- /dev/null
+++ b/wcag21/techniques/failures/F81.html
@@ -0,0 +1,123 @@
+
+
+
+
+ F81: Failure of Success Criterion 1.4.1 due to identifying required or error fields using
+ color differences only
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.1 due to identifying required or error fields using
+ color differences only
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This objective of this technique is to describe the failure that occurs when a required
+ field or an error field is marked with color differences only, without an alternate
+ way to identify the required field or error field. This can cause problems for people
+ who are blind or colorblind, because they may not be able to perceive the color differences
+ that indicate which field is required or which field is causing an error.
+
+
+
+
Examples
+
+
+
A user is completing an online form, and the phone number field is required. To indicate
+ that the phone number field is required, the label "Phone Number" is displayed in
+ a color different from the color used for optional fields, without any other indication
+ that "Phone Number" is a required field. A blind or colorblind user may not be able
+ to identify that "Phone Number" is a required field.
+
+
+
A user submits an online form and leaves a required field blank, resulting in an error.
+ The form field that caused the error is indicated by red text only, without an additional
+ non-color indication that the field caused an error.
+
+
+
+
+
Note
+
+
+
In both examples, the color could be used without failure if the text was sufficiently
+ different in visual presentation (e.g. bold or in a different font) that it would
+ be easily differentiated from the surrounding text if the color were removed. It would
+ also not fail if the color chosen had sufficient luminosity difference (lightness)
+ from the other text that it would be easily be seen as different if viewed in black
+ and white. In these cases - the information would not be displayed in color (hue)
+ alone but also in "presentation" or "lightness" respectively.
+
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
For all required fields or error fields in the Web page that are identified using
+ color differences:
+
+
+
+
+
Check that an non-color way to identify the required field or error field is provided.
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #1 is false, then this failure condition applies and content fails the Success
+ Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F82.html b/wcag21/techniques/failures/F82.html
new file mode 100644
index 0000000..a6e14c0
--- /dev/null
+++ b/wcag21/techniques/failures/F82.html
@@ -0,0 +1,109 @@
+
+
+
+
+ F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields
+ but not including a text label
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields
+ but not including a text label
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure ensures that people with visual or cognitive disabilities will recognize
+ phone number fields and understand what information to provide to fill in the fields.
+ Phone numbers are frequently formatted in fixed, distinctive ways, and authors may
+ feel that just providing visual formatting of the fields will be sufficient to identify
+ them. However, even if all the fields have programmatically determined names, a text
+ label must also identify the set of fields as a phone number.
+
+
+
+
Examples
+
+
Example 1
+
In the United States, phone numbers are broken into a three digit area code, a three
+ digit prefix, and a four digit extension. A web page creates fixed length text input
+ fields for the three parts of the phone number, surrounding the first field with parenthesis
+ and separating the second and third fields with a dash. Because of this formatting,
+ some users recognize the fields as a phone number. However, there is no text label
+ for the phone number on the web page. This is because the label for each field will
+ be the closest preceding text, so the three fields would be labeled "(", ")" , and
+ "-" respectively.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
For each set of phone number fields in the web page that represents a single phone
+ number, check that the set of fields are labeled with a visible text label that is
+ positioned near the set of phone number fields.
+
+
+
For each set of phone number fields in the Web page that represent a single phone
+ number, instructions are provided about how to fill in the fields.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If both check #1 and check #2 are false, then this failure condition applies and the
+ content fails this success criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F83.html b/wcag21/techniques/failures/F83.html
new file mode 100644
index 0000000..e14290f
--- /dev/null
+++ b/wcag21/techniques/failures/F83.html
@@ -0,0 +1,119 @@
+
+
+
+
+ F83: Failure of Success Criterion 1.4.3 and 1.4.6 due to using background images that do
+ not provide sufficient contrast with foreground text (or images of text)
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.3 and 1.4.6 due to using background images that do
+ not provide sufficient contrast with foreground text (or images of text)
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure occurs when people with low vision are not able to read text that is
+ displayed over a background image. When there is not sufficient contrast between the
+ background image and the text, features of the background image can be confused with
+ the text making it difficult to accurately read the text.
+
+
To satisfy Success Criterion 1.4.3 and 1.4.6, there must be sufficient contrast between
+ the text and its background. For pictures, this means that there would need to be
+ sufficient contrast between the text and those parts of the image that are most like
+ the text and behind the text.
+
+
+
+
Examples
+
+
Example 1: Failure Example 1
+
Black text overlays an image with black lines. The lines cross behind the letters
+ making F's look like E's etc.
+
+
+
+
Example 2: Failure Example 2
+
Black text overlays an image with dark gray areas. Wherever the text crosses a dark
+ gray area the contrast is so bad that the text cannot be read.
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
+
+ Quickcheck: First do a quick check to see if the contrast between the text and the area of the
+ image that is darkest (for dark text) or lightest (for light text) meets or exceeds
+ that required by the Success Criterion (1.4.3 or 1.4.5). If the contrast meets or
+ exceeds the specified contrast, then there is no failure.
+
+
+
If the Quickcheck is false, then check to see if the background behind each letter
+ has sufficient contrast with the letter.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If Quickcheck is false and #2 is false as well then this failure condition applies
+ and the content fails the contrast Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F84.html b/wcag21/techniques/failures/F84.html
new file mode 100644
index 0000000..3a535e5
--- /dev/null
+++ b/wcag21/techniques/failures/F84.html
@@ -0,0 +1,111 @@
+
+
+
+
+ F84: Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click
+ here" or "more" without a mechanism to change the link text to specific text.
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click
+ here" or "more" without a mechanism to change the link text to specific text.
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure describes a common condition where links such as "click here" or "more"
+ are used as anchor elements where you need to have the surrounding text to understand
+ their purpose and where there isn't any mechanism to make the destination clear by
+ itself, such as a button to expand the link text.
+
+
Many blind people who use screen readers call up a dialog box that has a list of links
+ from the page. They use this list of links to decide where they will go. But if many
+ of the links in that list simply say "click here" or "more" they will be unable to
+ use this feature in their screen reader, which is a core navigation strategy. That's
+ why it's a failure of 2.4.9 to not provide any way of allowing them to know the destination
+ from the link text alone. It is also true for people who tab through links. If all
+ they hear as they tab through the document is "click here, click here, click here
+ etc." they will become confused.
+
+
+
+
Examples
+
+
Example 1
<a href="file110.htm">Click here</a> for more information on the Rocky Mountains.
+
+
Example 2
<h2>News headlines</h2>
+The middle east peace meetings have yielded fruitful dialogue.
+<a href="r4300.htm">read more</a>
+
+
+
Tests
+
+
Procedure
+
+
+
+
Examine each link on the page.
+
+
Check to see if it has non-descript link text such as "click here" or "more" whose
+ purpose can be determined from the surrounding text but not from the link text alone.
+
+
+
Check to see if there is a mechanism on the page which turns all non-descript links
+ on the page into descriptive links.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #2 is true AND #3 is false, then this failure condition applies and content
+ fails the success criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F85.html b/wcag21/techniques/failures/F85.html
new file mode 100644
index 0000000..2645986
--- /dev/null
+++ b/wcag21/techniques/failures/F85.html
@@ -0,0 +1,155 @@
+
+
+
+
+ F85: Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent
+ to their trigger control in the sequential navigation order
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent
+ to their trigger control in the sequential navigation order
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes the failure condition that results when a Web page opens a dialog or
+ menu interface component embedded on the page in a way that makes it difficult for
+ a keyboard user to operate because of its position in the sequential navigation order.
+ When the user opens the dialog or menu embedded on the page by activating a button
+ or link, his next action will be to interact with the dialog or menu. If focus is
+ not set to the dialog or menu, and it is not adjacent to the trigger control in the
+ sequential navigation order, it will be difficult for the keyboard user to operate
+ the dialog or menu.
+
+
+
+
Examples
+
+
Example 1: Adding a dialog or menu embedded on the page to the end of the sequential
+ navigation order
+
+
When a DHTML menu or dialog is activated, it is created dynamically, positioned visually
+ near the trigger, and appended to the end of the DOM. Because it is appended to the
+ end of the DOM, it is at the end of the sequential navigation order. The user must
+ tab through the rest of the web page before he can interact with the dialog or menu.
+
+
+
+
Example 2: Setting focus to the document after dismissing a menu embedded on the page
+
When a menu is dismissed, it is removed or hidden from the web page and focus is set
+ to the document. The user must tab from the beginning of the navigation sequence to
+ reach the point from which the menu was opened.
+
For each menu or dialog embedded on a Web page that is opened via a trigger control:
+
+
+
+
+
+
Activate the trigger control via the keyboard.
+
+
+
+
Check whether focus is in the menu or dialog.
+
+
Check whether advancing the focus in the sequential navigation order puts focus in
+ the menu or dialog.
+
+
+
+
+
+
+
+
+
Dismiss the menu or dialog.
+
+
+
+
Check whether focus is on the trigger control.
+
+
Check whether advancing the focus backwards in the sequential navigation order puts
+ focus in the trigger control.
+
+
+
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If both points under step 1 are false, then this failure condition applies and the
+ content fails this success criterion.
+
+
+
If both points under step 2 are false, then this failure condition applies and the
+ content fails this success criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F86.html b/wcag21/techniques/failures/F86.html
new file mode 100644
index 0000000..273e205
--- /dev/null
+++ b/wcag21/techniques/failures/F86.html
@@ -0,0 +1,177 @@
+
+
+
+
+ F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part
+ form field, such as a US telephone number
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part
+ form field, such as a US telephone number
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This describes a failure condition of Success Criterion 4.1.2 where some or all of
+ the parts of multi-part form field do not have names. Often there is a label for the
+ multi-part field, which is either programatically associated with the first part,
+ or not programatically associated with any parts.
+
+
+
Note
+
+
+
A name does not necessarily have to be visible, but is visible to assistive technologies.
+
+
+
+
+
+
Examples
+
+
Example 1
+
A US telephone number consists of a 3-digit area code, a 3-digit prefix, and a 4-digit
+ suffix. They are typically formatted as follows ([area code]) [prefix]-[suffix], such
+ as (206) 555-1212. Often, forms asking for a telephone number will include 3 separate
+ fields, but with a single label, such as:
+
The failure occurs when there is not a name for each of the 3 fields in the Accessibility
+ API. A user with assistive technology will experience these as three undefined text
+ fields. Some assistive technologies will read the punctuation as identification for
+ the text fields, which can be even more confusing. In the case of a 3-field US phone
+ number, some assistive technologies would name the fields "(", ")" and "-", which
+ is not very useful.
+
+
+
+
Example 2
+
The same US telephone number. In this case, the label is not programatically associated
+ with any of the parts.
+
A user with assistive technology will be led to believe that the first field is for
+ the entire phone number, and will experience the second and third fields as undefined
+ text fields.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Check that there is a programmatically determined name for the field.
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false for any subfield, then the failure condition applies and the
+ content fails the success criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F87.html b/wcag21/techniques/failures/F87.html
new file mode 100644
index 0000000..e7e563b
--- /dev/null
+++ b/wcag21/techniques/failures/F87.html
@@ -0,0 +1,150 @@
+
+
+
+
+ F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using
+ :before and :after pseudo-elements and the 'content' property in CSS
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using
+ :before and :after pseudo-elements and the 'content' property in CSS
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The CSS :before and :after pseudo-elements specify the location of content before
+ and after an element's document tree content. The content property, in conjunction
+ with these pseudo-elements, specifies what is inserted. For users who need to customize
+ style information in order to view content according to their needs, they may not
+ be able to access the information that is inserted using CSS. Therefore, it is a failure
+ to use these properties to insert non-decorative content.
+
+
+
Note
+
A common way to test this critieria is to disable CSS styles to view whether content
+ added using pseudo-elements remains visible.
+
+
+
+
+
Examples
+
+
Example 1
+
In the following example, :before and :after are used to indicate speaker changes
+ and to insert quotation marks in a screenplay.
+
For each instance of content inserted through use of the :before and :after pseudo-elements
+ and the content property:
+
+
+
+
+
Check that non-decorative information presented by the generated content is available
+ when styles are overridden.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false, then this failure condition applies and the content fails this
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F88.html b/wcag21/techniques/failures/F88.html
new file mode 100644
index 0000000..f118fd6
--- /dev/null
+++ b/wcag21/techniques/failures/F88.html
@@ -0,0 +1,128 @@
+
+
+
+
+ F88: Failure of Success Criterion 1.4.8 due to using text that is justified (aligned to
+ both the left and the right margins)
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.8 due to using text that is justified (aligned to
+ both the left and the right margins)
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
Many people with cognitive disabilities have a great deal of trouble with blocks of
+ text that are justified (aligned to both the left and the right margins). The spaces
+ between words create "rivers of white" running down the page, which can make the text
+ difficult for some people to read. This failure describes situations where this confusing
+ text layout occurs. The best way to avoid this problem is not to create text layout
+ that is fully justified (aligned to both the left and the right margins).
+
+
+
+
Examples
+
+
Example 1
+
In the following example of a failure, the HTML align attribute is used to create justified text.
+
+<p align="justify">Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus
+nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec
+ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus.
+Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum
+primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo
+justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.
+</p>
+
+
Example 2
+
In this example of a failure, the CSS text-align property is used to create justified
+ text.
+
+...
+p {text-align: justify}
+
+...
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus
+nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec
+ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus.
+Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum
+primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo
+justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.</p>
Verify that content is not justified (aligned to both the left and the right margins).
+
+
+
+
+
+
Expected Results
+
+
+
+
If test procedure #2 is false, then this failure condition applies and the content
+ fails to meet Success Criterion 1.4.8.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F89.html b/wcag21/techniques/failures/F89.html
new file mode 100644
index 0000000..39e4d24
--- /dev/null
+++ b/wcag21/techniques/failures/F89.html
@@ -0,0 +1,156 @@
+
+
+
+
+ F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible
+ name for an image which is the only content in a link
+
+
+
+
+
+
+
+
+
Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible
+ name for an image which is the only content in a link
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure condition occurs when a link contains only non-text content, such as
+ an image, and that link cannot be identified by an accessible name. The accessible
+ name for a link is defined according to the Accessible Name and Description Computation.
+
+
This also applies when both text and images are used separately on a page to link
+ to the same target. In this case success technique H2: Combining adjacent image and text links for the same resource is the recommended approach to reduce the number of separate links and the undesirable
+ redundancy.
+
+
+
+
Examples
+
+
Example 1: HTML Search Results
+
A search site returns search results that include both a text link and an image link
+ to the match site. The image has a null alt attribute, since the result already contains a link with a text description. However,
+ the screen reader does not ignore the image link but uses heuristics to find some
+ text that might describe the purpose of the link. For example, the screen reader might
+ announce, "football dot gif Football Scorecard."
+
Check whether the link contains only non-text content.
+
+
Check whether the non-text content has been implemented in a way that it can be ignored
+ by assistive technologies, such as using role="presentation" or alt=""
+ .
+
+
+
Check that the link does not have an accessible name provided in another way such
+ as aria-label or aria-labelledby.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If all checks are true, then this failure condition applies and the content fails
+ the success criteria.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F9.html b/wcag21/techniques/failures/F9.html
new file mode 100644
index 0000000..470c8f9
--- /dev/null
+++ b/wcag21/techniques/failures/F9.html
@@ -0,0 +1,121 @@
+
+
+
+
+ F9: Failure of Success Criterion 3.2.5 due to changing the context when the user removes
+ focus from a form element
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 3.2.5 due to changing the context when the user removes
+ focus from a form element
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This document describes a failure that occurs when removing focus from a form
+ element, such as by moving to the next element, causes a change of context.
+
+
+
+
+
Examples
+
+
Example 1
+
The user is going through the form filling out the fields in order.
+ When he moves from the third field to the forth, the form submits.
+
+
Check if the form submits when you move from one field to the
+ next.
+
+
+
Check if moving from one field to the next launches any new
+ windows.
+
+
+
Check if moving from one field to the next navigates to another
+ screen.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If step #3, step #4, or step #5 is true, then this failure condition applies and
+ the content fails the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F90.html b/wcag21/techniques/failures/F90.html
new file mode 100644
index 0000000..94b06b8
--- /dev/null
+++ b/wcag21/techniques/failures/F90.html
@@ -0,0 +1,154 @@
+
+
+
+
+ F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content
+ via the headers and id attributes
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content
+ via the headers and id attributes
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
One way for authors to explicitly associate header cells to data cells is by using
+ the id and headers attributes. These allow the author to associate multiple header
+ cells to a particular data cell, which can be necessary when complex data tables with
+ more than one level of heading are used.
+
+
The failure occurs when the relationship between data cells and corresponding header
+ cells cannot be programmatically determined correctly because the association of id and headers attributes is faulty. This can happen, for example, when copying code within tables
+ and forgetting to update the code.
+
Example 1: Table content not correctly associated to nested headers
+
In this example, nested headers are used, but the content cells are incorrectly associated
+ via the id and headers attributes. All cells reference top level header 'Exams' (id="e")
+ - this isn't correct for the last three columns which should reference header 'Projects'.
+ Also, the referencing of the second level column headers has been accidentally swapped
+ even though in this example this makes no difference as the contents (1, 2, Final)
+ are repeated.
+
+
+
Example Code:
+<table>
+ <tr>
+ <th rowspan="2" id="h">Homework</th>
+ <th colspan="3" id="e">Exams</th>
+ <th colspan="3" id="p">Projects</th>
+ </tr>
+ <tr>
+ <th id="e1" headers="e">1</th>
+ <th id="e2" headers="e">2</th>
+ <th id="ef" headers="e">Final</th>
+ <th id="p1" headers="p">1</th>
+ <th id="p2" headers="p">2</th>
+ <th id="pf" headers="p">Final</th>
+ </tr>
+ <tr>
+ <td headers="h">15%</td>
+ <td headers="e p1">15%</td> // should be "e e1"
+ <td headers="e p2">15%</td> // should be "e e2"
+ <td headers="e pf">20%</td> // should be "e ef"
+ <td headers="e e1">10%</td> // should be "p p1"
+ <td headers="e e2">10%</td> // should be "p p2"
+ <td headers="e ef">15%</td> // should be "p pf"
+ </tr>
+</table>
+
For tables that associate data cells to header cells via the id and headers attributes,
+ check that the programmatic association is correct.
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #1 is false, then this failure condition applies and the content fails the
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F91.html b/wcag21/techniques/failures/F91.html
new file mode 100644
index 0000000..7ba191f
--- /dev/null
+++ b/wcag21/techniques/failures/F91.html
@@ -0,0 +1,180 @@
+
+
+
+
+ F91: Failure of Success Criterion 1.3.1 for not correctly marking up table headers
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 for not correctly marking up table headers
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure occurs when data tables do not use header elements (th) or other appropriate
+ table mark-up (the scope attribute, headers and id or the ARIA roles columnheader
+ / rowheader) to make the headers programatically determinable from within table content.
+ Making headers programmatically determinable is especially important when data cells
+ are only intelligible together with header information. When screen reader users navigate
+ through the table content horizontally or vertically, the headers that change can
+ be read out to provide the necessary context for the information in the data cells.
+
+
+
+
Examples
+
+
Example 1: Headers not marked up appropriately
+
This table does not use th (or other appropriate header markup) for headers. Instead,
+ it uses td elements for all cells. Navigating cell by cell, screen readers will often
+ fail to read the header cells associated with content.
+
+
For all data tables, check if table headers can be correctly programmatically determined
+ by use of one of the following mechanisms:
+
+
+
+
+
+
headers marked up with table header (th) elements
+
+
+
+
scope attributes on th for tables with more than a single row or column of table headers.
+
+
+
scope attributes on th for tables with more than a single row or column of table headers.
+
+
+
headers and data cells associated using headers and id attributes
+
+
+
+
headers marked up as td elements with the scope attribute
+
+
+
+
headers marked up with ARIA role attributes rowheader or columnheader
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If all checks are false, then this failure condition applies and the content fails
+ the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F92.html b/wcag21/techniques/failures/F92.html
new file mode 100644
index 0000000..5ff81d3
--- /dev/null
+++ b/wcag21/techniques/failures/F92.html
@@ -0,0 +1,136 @@
+
+
+
+
+ F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content
+ which conveys semantic information
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.3.1 due to the use of role presentation on content
+ which conveys semantic information
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure occurs when a role of presentation is applied to an element whose purpose
+ is to convey information or relationships in the content. Elements such as table, can convey information about the content contained in them via their semantic markup.
+ The WAI-ARIA role of
+ presentation
+ on the other hand, is intended to suppress semantic information of content from the
+ accessibility API and prevent user agents from conveying that information to the user.
+ Use of the presentation role for content which should convey semantic information may prevent the user from
+ understanding that content.
+
+
+
+
+
Examples
+
+
Example 1
+
In this example, tabular data is marked up with role=presentation. Though design layout
+ tables can be marked up in such a way, data tables need to retain their semantic information
+ and should therefore not be marked up with role=presentation.
+
Check if an element which conveys information, structure, or relationships through
+ its semantic markup
+
+
+
+
Element has the attribute role="presentation".
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
If check #2 is true, then this failure condition applies and the content fails the
+ Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F93.html b/wcag21/techniques/failures/F93.html
new file mode 100644
index 0000000..48609a8
--- /dev/null
+++ b/wcag21/techniques/failures/F93.html
@@ -0,0 +1,145 @@
+
+
+
+
+ F93: Failure of Success Criterion 1.4.2 for absence of a way to pause or stop an HTML5
+ media element that autoplays
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.2 for absence of a way to pause or stop an HTML5
+ media element that autoplays
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
This failure occurs when an audio or video element with an audio track contains the autoplay attribute and does not contain the muted attribute, and no controls or commands have been provided to pause or stop the media
+ resource.
+
+
When the autoplay attribute is present, the user agent will automatically begin playback of the media
+ resource as soon as it can do so without stopping. When the muted attribute is present, the user agent will initially mute the media resource's audio
+ output, overriding any user preference.
+
+
If the media element is shorter than 3 seconds, the failure does not occur. If the
+ user agent provides user preferences to override autoplay behavior, the failure does
+ not occur.
+
+
The HTML spec contains the following notes:
+
+
User agents do not need to support autoplay, and it is suggested that user agents
+ honor user preferences on the matter. Authors are urged to use the autoplay attribute rather than using script to force the video to play, so as to allow the
+ user to override the behavior if so desired.
+
+
+
Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows
+ the user to override the automatic playback when it is not desired, e.g. when using
+ a screen reader. Authors are also encouraged to consider not using the automatic playback
+ behavior at all, and instead to let the user agent wait for the user to start playback
+ explicitly.
+
+
+
+
+
Examples
+
+
Example 1: An auto-playing audio track
+
In this example, the advertising video contains an audio track. The video will play
+ continuously because of the loop attribute, and the video will start automatically because of the autoplay attribute and because there does not appear to be any controls to allow the user
+ to stop the video.
+
Check if an audio or video element has an active audio track.
+
+
+
Check if the audio or video lasts longer than 3 seconds.
+
+
Check if the element has an autoplay attribute.
+
+
+
Check if the element does not have a muted attribute.
+
+
+
Check if no command or control has been provided to stop or pause the media element.
+
+
+
+
+
+
Expected Results
+
+
+
+
If checks 1-5 are true, then this failure condition applies and the content fails
+ the Success Criterion.
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F94.html b/wcag21/techniques/failures/F94.html
new file mode 100644
index 0000000..a36b420
--- /dev/null
+++ b/wcag21/techniques/failures/F94.html
@@ -0,0 +1,162 @@
+
+
+
+
+ F94: Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize
+ text
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize
+ text
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to document the failure of text to re-scale when
+ viewport units are used on text. As these units are relative to the viewport, it means they cannot
+ be resized by zooming or adjusting text-size.
+
+
There are various methods to increase and decrease the size of text and other content,
+ but viewport units applied to text (generally via font-size in CSS) prevent most available methods. Attempts to use browser controls to zoom
+ or adjust text-size will not work. Only methods that completely override the CSS will
+ work, and those could cause other issues such as layouts collapsing or text overlapping.
+
+
Some uses of viewport units may not prevent text-size adjustments, but if they are
+ used as the primary method for defining text-size, they are likely to cause a failure
+ of Success Criterion 1.4.4.
+
+
+
Note
+
If media queries were used to adjust the size of text or unit of measure at different
+ screen sizes, it may not be a failure of Resize text. On-page controls provided by the author are also a way of passing the resize text
+ success criteria.
+
+
+
+
+
Examples
+
+
Example 1: Failure example 1
+
The following CSS and HTML snippet uses VW units to size the text.
/* CSS */
+.callout {
+ font-size:1vw;
+}
+
+<p class="callout">
+ Text that scales by viewport units<p/>
Use any of the following methods to resize text when available:
+
+
+
+
the zoom feature of the browser
+
+
the text-sizing feature of the browser,
+
+
on-page controls for resizing text.
+
+
+
+
+
+
Check that the text resizes by one of the methods above, and can be resized to at
+ least 200% of the default.
+
+
+
+
+
+
Expected Results
+
+
+
If step #5 is false, then this failure condition applies and the content fails Success
+ Criteria 1.4.4, Resize Text.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F95.html b/wcag21/techniques/failures/F95.html
new file mode 100644
index 0000000..689c904
--- /dev/null
+++ b/wcag21/techniques/failures/F95.html
@@ -0,0 +1,101 @@
+
+
+
+
+ F95: Failure of Success Criterion 1.4.13 due to content shown on hover not being hoverable
+
+
+
+
+
+
+
+
Failure of Success Criterion 1.4.13 due to content shown on hover not being hoverable
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Any technology that supports the display of additional content on pointer hover.
The objective of this failure is to describe a situation where users find it difficult
+ or impossible to move the pointer over additional content that appears on hover. For
+ users of screen magnification software, the new content is often not fully visible
+ in the current magnifed section. In order to perceive it, it is therefore critical
+ for these users to be able to move the pointer away from the trigger and over the
+ additional content, and thereby change the position of the magnified section, without
+ this content disappearing.
+
+
+
+
Examples
+
+
+
A pop-up opens on pointer hover. Due to the chosen screen magnification, the content
+ is only partially visible. However, as soon as the pointer is moved away from the
+ trigger towards the pop-up content so it can be read, the pop-up automatically closes.
+
+
+
Hovering over a chart with data points, pop-ups open to show details of the respective
+ data point, somewhat offset from the data point itself. When moving the pointer towards
+ the pop-up so it can be fully read with magnification, the pointer travels over other
+ data points that cause the appearance of other pop-ups that replace the particular
+ pop-up the user wanted to see.
+
+
+
+
+
+
Tests
+
+
Procedure
+
For each area of additional content that appears on pointer hover:
+
+
+
The pointer can be moved over the new content without the additional content disappearing.
+
+
The appearance of the additional content is controlled by the user agent, not the
+ author.
+
+
+
+
+
+
Expected Results
+
+
+
If #1 and #2 are false, then content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F96.html b/wcag21/techniques/failures/F96.html
new file mode 100644
index 0000000..d7b4773
--- /dev/null
+++ b/wcag21/techniques/failures/F96.html
@@ -0,0 +1,149 @@
+
+
+
+
+ F96: Failure due to the accessible name not containing the visible label text
+
+
+
+
+
+
+
+
Failure due to the accessible name not containing the visible label text
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that include interactive controls (such as links or form inputs).
The objective of this Failure is to describe situations where speech input users cannot
+ reliably speak the name of a control because it differs from the visible label.
+
+
When speech input users interact with a web page, they usually speak a command followed
+ by the reference to some visible label (like the text in a button or a link, or the
+ text labelling some input). If the visible label does not match the accessible name
+ of the control, speech users may be unable to directly activate that control.
+
+
There are techniques that go beyond the visible label text of elements. The idea is
+ to provide more context for users of assistive technologies to whom the visible context
+ may not be available. Examples are the use of accessible hidden (e.g., offscreen-positioned)
+ text, the use of the aria-label attribute to overwrite the label text, or the use
+ of the aria-labelledby attribute to compose a label text from one or more strings
+ strings on the page.
+
+
When the use of these techniques results in an accessible name in which the exact
+ string of the visible label does not occur in the accessible name, speech users may
+ be unable to activate that control. Refer to the Accessible Name and Description Computation algorithm to work out the order of precedence in computing the accessible name of
+ a control.
+
+
+
+
Examples
+
+
Example 1: Mismatch of visible button text and accessible name supplied via aria-label
+
The text in a search button reads "Go" but the accessible name provided in an aria-label
+ attribute is "Find in this site"
+
+ <button id="sitesearch" aria-label="Find in this site">Go</button>
+
+
+
Example 2: Invisible link text disrupts visible label text string in accessible name
+
A download link reads "Download specification" but there is invisible link text so
+ that the accessible name of that link is "Download gizmo specification". While the
+ visible label text is contained in the accessible name, there is no string match which
+ may prevent the link from being activated by speech input.
+
Example 3: Input with a hidden label carrying text that differs from the input's value
+ attribute
+
+
An input of type="submit" with the value="search" which is exposed as visible label
+ of the input, has a programmatically linked and accessibly hidden label enclosing
+ the text "Find in this site" referenced by aria-labelledby. Because aria-labelledby
+ takes precedence over the value of the input, the accessible name of the input in
+ most browser / screen reader combinations will be "Find in this site". Speech users
+ speaking a command such as "Click search" will be unable to activate the input.
+
+ <div id="hidden-label">Find in this site</div>
+ <input type="submit" aria-labelledby="hidden-label" value="search">
+
For all controls with a visible label (e.g., link text, button text, programmatically
+ linked label, images in links with text), check that:
+
+
+
+
The accessible name is the same as the visible label.
+
+
The accessible name contains a match for the string of the visible label.
+
+
+
+
+
Expected Results
+
+
+
If checks #1 and #2 are false, the content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F97.html b/wcag21/techniques/failures/F97.html
new file mode 100644
index 0000000..12b9e49
--- /dev/null
+++ b/wcag21/techniques/failures/F97.html
@@ -0,0 +1,104 @@
+
+
+
+
+ F97: Failure due to locking the orientation to landscape or portrait view
+
+
+
+
+
+
+
+
Failure due to locking the orientation to landscape or portrait view
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
The objective of this technique is to describe how restricting the view of content
+ to a single orientation is a failure to allow content to be viewed in multiple orientations.
+ When content is presented with a restriction to a specific orientation, users must
+ orient their devices to view the content in the orientation that the author imposed.
+ Some users have their devices mounted in a fixed orientation (e.g. on the arm of a
+ power wheelchair), and if the content cannot be viewed in that orientation it creates
+ problems for the user.
+
+
If a specific orientation is determined to be essential for the operation and viewing of the content, then this failure technique will not
+ apply.
+
+
+
+
Examples
+
+
+
A news app always shows the content in portrait orientation. Users can view the content
+ on a device which supports landscape and portrait display orientations. When the device
+ is turned to landscape view, the content appears sideways to the user.
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
Open the content in landscape view. Check that the content is oriented for this view.
+
+
Open the content in portrait view. Check that the content is oriented for this view.
+
+
Check if portrait or landscape view is essential for the viewing and operation of
+ the content.
+
+
+
If there are any controls in the content, user agent, operating system, or device
+ that restrict or allow orientation changes, check that the controls can be set to
+ allow checks one and two to be true.
+
+
+
+
+
+
Expected Results
+
+
+
If check #1 or check #2 is false, and checks #3 and #4 are false, then this failure
+ condition applies and content fails the Success Criterion.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F98.html b/wcag21/techniques/failures/F98.html
new file mode 100644
index 0000000..631e4e3
--- /dev/null
+++ b/wcag21/techniques/failures/F98.html
@@ -0,0 +1,195 @@
+
+
+
+
+ F98: Failure due to interactions being limited to touch-only on touchscreen devices
+
+
+
+
+
+
+
+
Failure due to interactions being limited to touch-only on touchscreen devices
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that include interactive controls (such as links, form inputs, or
+ complex custom widgets) and that can detect the presence of different input modalities.
+
The objective of this Failure is to describe situations where users on devices that
+ have a touchscreen are unable to use other input modalities available to them (such
+ as an additional/external mouse or keyboard).
+
+
There are various methods and heuristics for web content to determine if a user's
+ device has a touchscreen. However, even when a touchscreen is present, other input
+ modalities may be available to users. It is not necessarily the case that the user
+ will be interacting with the web content (exclusively, or at all) using the touchscreen.
+
+
If, when a touchscreen is detected, web content is designed to be operated exclusively
+ through touch, these users will be unable to operate the content using their other
+ (possibly preferred) input mechanisms.
+
+
+
+
Examples
+
+
Example 1: Only using touch-specific JavaScript event listeners when a touchscreen
+ is detected
+
+
These types of approaches have historically been popular for "mobile" specific development,
+ to ensure that touchscreen interactions are more responsive and immediate (due to
+ the way that touch interactions used to add a delay of approximately 300ms between
+ a "tap" interaction and the generic click event being fired).
+
+/* inferring the presence of a touchscreen based on
+ support for the Touch Events API */
+
+if (window.TouchEvent || ('ontouchstart' in window)) {
+ /* set up event listeners for touch */
+ target.addEventListener('touchend', ...);
+ ...
+} else {
+ /* set up event listeners for mouse/keyboard */
+ target.addEventListener('click', ...);
+ ...
+}
+
+/* inferring the presence of a touchscreen based on
+ the CSS Media Queries 4 Interaction Media Features
+ match for a "coarse" primary input mechanism */
+
+if (window.matchMedia && window.matchMedia("(pointer:coarse)").matches) {
+ /* set up event listeners for touch */
+ target.addEventListener('touchend', ...);
+ ...
+} else {
+ /* set up event listeners for mouse/keyboard */
+ target.addEventListener('click', ...);
+ ...
+}
+
Similarly, web content that omits relevant/necessary keyboard event listeners (e.g.
+ for the correct keyboard interaction with a complex widget, such as a tab interface)
+ when a touchscreen is detected - under the assumption that on a touch device, keyboard
+ support won't be necessary.
+
+/* inferring the presence of a touchscreen based on
+ the navigator.maxTouchPoints property defined in
+ the Pointer Events API */
+
+if (window.PointerEvent && ('maxTouchPoints' in navigator) &&
+ (navigator.maxTouchPoints > 0)) {
+ /* no need to listen to keyboard - there's a touchscreen... */
+ ...
+} else {
+ /* set up event listeners for keyboard interactions */
+ target.addEventListener('keyup', ...);
+ ...
+}
+
+
Note
+
Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard - but only in situations
+ where a touchscreen interface was also detected.
+
+
+
+
+
Example 2: Hiding/omitting controls for mouse and keyboard users when a touchscreen
+ is detected
+
+
Web content containing interactive widgets such as content carousels, with visible
+ buttons to operate the widget (such as previous/next buttons, or a visible scrollbar/slider).
+ These visible controls are hidden/omitted when a touchscreen is detected, under the
+ assumption that users will simply use touch gestures to operate the widgets, and no
+ other alternatives are then provided for keyboard or mouse users.
+
+/* using CSS Media Queries 4 Interaction Media Features
+ to hide particular elements in the page (such as a container
+ with visible controls) when a "coarse" primary input is present */
+
+@media (pointer: coarse) {
+ #widget .controls { display: none; }
+}
+
Depending on the specific implementation, authors may allow mouse interactions with
+ widgets that mirror touch gestures - for instance, allowing mouse users to also drag/swipe
+ carousels, rather than just relying on clickable previous/next controls or scrollbars.
+ In these cases, hiding controls when a touchscreen is detected will still allow users
+ to operate the widget with the mouse (unless this interaction has also been suppressed/omitted
+ when the touchscreen was detected, as per the previous example). However, if the only
+ keyboard-operable controls for the widget were hidden, and no alternative for keyboard
+ users was provided (such as allowing cursor key operation), this situation would still
+ fail Success Criterion 2.5.6.
+
+
+
Note
+
Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard and (depending on the touch gesture that the user is expected to perform) Success Criterion
+ 2.5.1 Pointer Gestures.
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
Open the content on a device with a touchscreen and at least one additional input
+ modality - this includes touch-enabled laptops and touchscreen devices (smartphones
+ or tablets) with a paired external keyboard and mouse.
+
+
+
Check that all interactive controls can be operated using not only the touchscreen,
+ but also the additional input mechanisms (keyboard and mouse)
+
+
+
If the presence of the touchscreen caused interactive controls not to be displayed
+ (compared to the same content when viewed on a device without a touchscreen), check
+ that there are alternative controls/ways for users of other additional input mechanisms
+ to operate the content
+
+
+
+
+
+
Expected Results
+
+
+
If checks #2 or #3 are false, the content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/F99.html b/wcag21/techniques/failures/F99.html
new file mode 100644
index 0000000..2f94c9f
--- /dev/null
+++ b/wcag21/techniques/failures/F99.html
@@ -0,0 +1,136 @@
+
+
+
+
+ F99: Failure of Success Criterion 2.1.4 due to implementing character key shortcuts that
+ cannot be turned off or
+ remapped
+
+
+
+
+
+
+
+
+
Failure of Success Criterion 2.1.4 due to implementing character key shortcuts that
+ cannot be turned off or
+ remapped
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
This failure applies to web content that can be interacted with using a physical keyboard
+ as input mechanism.
+
When keyboard shortcuts using only character keys are implemented, voice commands
+ can inadvertently trigger functionality. Character key shortcuts use a single key
+ such as a letter key (including upper- and lower-case letters),
+ punctuation, number, or symbol characters.
+
+
Content must either not implement single character key shortcuts, or offer settings
+ to either turn off these
+ shortcuts or to map them to keyboard shortcuts that employ an additional modifier
+ key, such Alt or
+ Ctrl.
+
+
+
Note
+
The use of a single key keyboard shortcut is not a failure if the shortcut is only
+ active when a particular interface element has focus. For example, when a select element
+ or a custom listbox has focus, the input of single character keys to navigate the
+ list is a useful feature.
+
+
+
The test procedure suggests asking the author (often the developer of the site) whether
+ keyboard shortcuts are used. If that information is trusted then the procedure can
+ be simpler than pressing all the keys.
+
+
The success criterion does not apply when single key shortcuts are only active when
+ interface elements have the focus, for example, a select element. Here, pressing a letter key is used for fast navigation within the select
+ options.
+
+
Viewing page scripts and searching for typical keyboard event handlers like document.addEventListener('keydown' ...) or the presence of the .keycode attribute
+ may establish the presence of scripts that intercept keyboard shortcuts without modification
+ keys like ALT or
+ STR being held down at the same time. As there are several ways of implementing character
+ key events, this
+ method is not considered reliable.
+
+
Some browsers employ single key shortcuts with Shift. For example, Firefox opens a page search when pressing
+ Shift + / and a search in page links when pressing Shift + '. In these cases, it will be necessary to press Esc or click an empty part of the page to remove the focus from the browser input.
+
+
+
+
Examples
+
An application uses the single key shortcut S to bring up a search popup. There is no setting available to turn off or modify the
+ shortcut.
+
+
+
+
Tests
+
+
Procedure
+
If the site does not provide settings to disable or remap keyboard shortcuts:
+
+
+
+
If loading the page sets focus to an input, click on an empty part of the page to
+ ensure that
+ no inputs are in focus.
+
+
+
Press keys identified by the author as shortcut keys, or if this information is not
+ available, press all printing characters (i.e., all number, letter, sign and punctuation
+ keys). Do not press non-printing
+ modifier and control keys such as Ctrl, Alt, Esc, Arrow keys and (where present) the function keys F1-F12. Also
+ exempt are Space, Enter, Return, Tab, and the Delete key.
+
+
+
Hold the Shift key and press the same keys again.
+
+
+
Check whether a function has been triggered by pressing the keys
+
+
+
+
+
Expected Results
+
If step #4 is false then this failure condition applies and the content fails the
+ Success Criterion.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html b/wcag21/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html
new file mode 100644
index 0000000..6b8515a
--- /dev/null
+++ b/wcag21/techniques/failures/failure-concurrent-input-mechanisms-touch-or-mouse-keyboard.html
@@ -0,0 +1,194 @@
+
+
+
+
+ failure-concurrent-input-mechanisms-touch-or-mouse-keyboard: Failure due to interactions being limited to touch-only on touchscreen devices
+
+
+
+
+
+
+
+
Failure due to interactions being limited to touch-only on touchscreen devices
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
All technologies that include interactive controls (such as links, form inputs, or
+ complex custom widgets) and that can detect the presence of different input modalities.
+
+
This technique is not referenced from any Understanding document.
+
+
+
Description
+
The objective of this Failure is to describe situations where users on devices that
+ have a touchscreen are unable to use other input modalities available to them (such
+ as an additional/external mouse or keyboard).
+
+
There are various methods and heuristics for web content to determine if a user's
+ device has a touchscreen. However, even when a touchscreen is present, other input
+ modalities may be available to users. It is not necessarily the case that the user
+ will be interacting with the web content (exclusively, or at all) using the touchscreen.
+
+
If, when a touchscreen is detected, web content is designed to be operated exclusively
+ through touch, these users will be unable to operate the content using their other
+ (possibly preferred) input mechanisms.
+
+
+
+
Examples
+
+
Example 1: Only using touch-specific JavaScript event listeners when a touchscreen
+ is detected
+
+
These types of approaches have historically been popular for "mobile" specific development,
+ to ensure that touchscreen interactions are more responsive and immediate (due to
+ the way that touch interactions used to add a delay of approximately 300ms between
+ a "tap" interaction and the generic click event being fired).
+
+/* inferring the presence of a touchscreen based on
+ support for the Touch Events API */
+
+if (window.TouchEvent || ('ontouchstart' in window)) {
+ /* set up event listeners for touch */
+ target.addEventListener('touchend', ...);
+ ...
+} else {
+ /* set up event listeners for mouse/keyboard */
+ target.addEventListener('click', ...);
+ ...
+}
+
+/* inferring the presence of a touchscreen based on
+ the CSS Media Queries 4 Interaction Media Features
+ match for a "coarse" primary input mechanism */
+
+if (window.matchMedia && window.matchMedia("(pointer:coarse)").matches) {
+ /* set up event listeners for touch */
+ target.addEventListener('touchend', ...);
+ ...
+} else {
+ /* set up event listeners for mouse/keyboard */
+ target.addEventListener('click', ...);
+ ...
+}
+
Similarly, web content that omits relevant/necessary keyboard event listeners (e.g.
+ for the correct keyboard interaction with a complex widget, such as a tab interface)
+ when a touchscreen is detected - under the assumption that on a touch device, keyboard
+ support won't be necessary.
+
+/* inferring the presence of a touchscreen based on
+ the navigator.maxTouchPoints property defined in
+ the Pointer Events API */
+
+if (window.PointerEvent && ('maxTouchPoints' in navigator) &&
+ (navigator.maxTouchPoints > 0)) {
+ /* no need to listen to keyboard - there's a touchscreen... */
+ ...
+} else {
+ /* set up event listeners for keyboard interactions */
+ target.addEventListener('keyup', ...);
+ ...
+}
+
+
Note
+
Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard - but only in situations
+ where a touchscreen interface was also detected.
+
+
+
+
+
Example 2: Hiding/omitting controls for mouse and keyboard users when a touchscreen
+ is detected
+
+
Web content containing interactive widgets such as content carousels, with visible
+ buttons to operate the widget (such as previous/next buttons, or a visible scrollbar/slider).
+ These visible controls are hidden/omitted when a touchscreen is detected, under the
+ assumption that users will simply use touch gestures to operate the widgets, and no
+ other alternatives are then provided for keyboard or mouse users.
+
+/* using CSS Media Queries 4 Interaction Media Features
+ to hide particular elements in the page (such as a container
+ with visible controls) when a "coarse" primary input is present */
+
+@media (pointer: coarse) {
+ #widget .controls { display: none; }
+}
+
Depending on the specific implementation, authors may allow mouse interactions with
+ widgets that mirror touch gestures - for instance, allowing mouse users to also drag/swipe
+ carousels, rather than just relying on clickable previous/next controls or scrollbars.
+ In these cases, hiding controls when a touchscreen is detected will still allow users
+ to operate the widget with the mouse (unless this interaction has also been suppressed/omitted
+ when the touchscreen was detected, as per the previous example). However, if the only
+ keyboard-operable controls for the widget were hidden, and no alternative for keyboard
+ users was provided (such as allowing cursor key operation), this situation would still
+ fail Success Criterion 2.5.6.
+
+
+
Note
+
Generally, these approaches will also result in a failure of Success Criterion 2.1.1 Keyboard and (depending on the touch gesture that the user is expected to perform) Success Criterion
+ 2.5.1 Pointer Gestures.
+
+
+
+
+
+
Tests
+
+
Procedure
+
+
+
Open the content on a device with a touchscreen and at least one additional input
+ modality - this includes touch-enabled laptops and touchscreen devices (smartphones
+ or tablets) with a paired external keyboard and mouse.
+
+
+
Check that all interactive controls can be operated using not only the touchscreen,
+ but also the additional input mechanisms (keyboard and mouse)
+
+
+
If the presence of the touchscreen caused interactive controls not to be displayed
+ (compared to the same content when viewed on a device without a touchscreen), check
+ that there are alternative controls/ways for users of other additional input mechanisms
+ to operate the content
+
+
+
+
+
+
Expected Results
+
+
+
If checks #2 or #3 are false, the content fails the Success Criterion.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/failures/img/F69-obscured.gif b/wcag21/techniques/failures/img/F69-obscured.gif
new file mode 100644
index 0000000000000000000000000000000000000000..e9f69137c139fd5a4cc2ec9d9d89301bbd0f090f
GIT binary patch
literal 4280
zcmb_bi9b~R_a9^l*>_TQ20e6y7br*
zEwUGVl_g8dbAO-lH~h})HLp8o&N=V%e!tHh(=$YE9rs~eJ8lO@59f{|g9*gK;LF4#DW7D1<{{9E#vj6o=B8;xGt@!8i=TVJM(Y2c|;5wBN&A+7{U+;
zLm>=o1*`!WAPraoTA&6N18e{du)r`z7evoNATW%=FhRKhRwMBIBrWio}_gikCTxwso#A
zTPj}_sCf+DIn!D-bX)t{%KMkC)vxaw#t$8H_O4h4Yt*eRiBTp+JM^e6ZQ73
z-oO3AUHji9_u8u#vews0ArL)q&
zLb=1vHKEM%Q|}*PGafdAY49Xi(GGqXO$B^|1TwmyjLKLv540
zfpy(c2aY#dH2qkm_1SY&SVUBQsfsG7BxFh3U!Byr%z>G{*Yf{xOGH8P^X;R}Xdae~
z5!d&AEezG35Z*HV()x5g4JZ2E0*RO(pPjMQ#a!kCt6u7C7e!#f3X*cOBOM>yhYnSX
zgn)y%|x*sGC>T-&RWj6C$S_sq>X
zsW;{F52Z{hZpa*OF3do@v_24(wA#smwVIg-cAr&3$G}6$CKlzo+TFS7|)2jsEr*{O;IR67ljEZ
z*j^LzEY3PNAOgo%o41Pjxi2ulG$)%)Nr_0l3dO7UTSCd{k`{HOO1Dj88cx=63J2h&0YKckoo5*w4cxv{wrd#Ib373Q%*uKR%6v>l;!#N
zoMWkNEjFqzu3Hb84*71L)|H9h9OnPyN_uT*WzuF%5dL$1)cA12ma!%OkH1T$EodsH
z)j|21rsp^`SKmmf+KT#h`{WizdUKz(9yeYT6gMx(5(@C1U8|$~Ye`sic&MO?iSbR4
zuJm=BrxZD5&m4_DwEZfgdPA){fTSoLDS+>ImnSiETP@5yXsuMl6MGI1^1l)ZBgV37
z3MO(-n|{=q7v!7uQm3{QCMD#X-CkPY@~n)#d#jpR_?2rzCHbr+dgVhJKjj^A@!Ki+
zR-YeU|C;ds#w@871_~!6&dzMziBYzupo60_IxbHS;eK(Es^W&BN2C3BP
z+=ibT2C+P`aewOH&EaS#mZub4LZFhgkIO3m8Y)L#CfJqAiaZuh`Iad1`|M9_$yAd|
zx+&tz%1AdC*-*O2NLxRR?<&5g2XmLD8X8%Yv%#H`&X*Fn^aZ{w*~$-2r9##fhrd3I
z=YH$hMgmm{>>EIlt`slH;gXAFzPRvRS%3t?dmx!-`X2d;>sI;rrB@h&cgKf_D^ri
zyZN`IMDtz}cS!onJkYtJE_^JR;ZfD-w}^|J0u{7NGWYTIAO@lQ8`;E8GsCn%uXIHZoOLof()~u1vv9~PDgwtz`H{6I0PW-dY7uoF}OMZ4r
zcOqFaMXC)rj}#A9jBnmcR-HMyep}FuUvB%r+tv&BYn1F94y>|{eZg|=4TNmXNFFWL
zdlM6BwPnJC!)*GmEUKEkvz3nZzttTo%+qsGaeNfx^7vc=#kten|ER4l(TFk`qR7T1
zr;%uS5>|i|WDcJc6hF=pg8uU{c);J?Mq7SLrn5|i&Bco#$Q0-uy;r&5?zEJ+rc__d
zAUP1_QFc09{%zA_c$0|`XU-nW^PXd+0T(sC@^Q}e_f~c_S_e4rak(Ta&9B$rV>t)$
z*7wo)qMJ>O$>eskm4O4t6rRht{W0cFbJQp^>&S`1I@#o<^2G7J|kNuS}7_G?&%#|B0+$B>wnc5B`$9
z%8$f>w86ID-&c8#*2m!?OXY*gsb3gxg-Ds$Xi|;-;F&24&+%Eo*X7Q>oqGJH=y
zvFDy}&7Z^I*?-*=X9QmJ>7+W}bxwQ3mfC5sx!i3Mdn{xJ@Z#inaQX&e_qt;Uvl_}-fy9w8}Y!;&;`u+j!
zq5Vb%W}TI0zDY?#r>uVXPt*%;XQ&m)W?&IQzgt!;AK6x^l
z=AjIOf1=pnPaiqbLs_uHH*CMiv)51s
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to show how non-text objects in Flash can be marked
+ so that they can be read by assistive technology.
+
+
The Flash Player supports text alternatives to non-text objects using the name property in the accessibility object, which can be defined in ActionScript or within
+ Flash authoring tools.
+
+
When an object contains words that are important to understanding the content, the
+ name property should include those words. This will allow the name property to play the same function on the page as the object. Note that it does not
+ necessarily describe the visual characteristics of the object itself but must convey
+ the same meaning as the object.
+
+
+
+
Examples
+
+
Example 1: Applying a textual alternative for a symbol (graphic, button or movieclip)
+
The Flash Professional authoring tool's Accessibility panel lets authors provide
+ accessibility information to assistive technology and set accessibility options for
+ individual Flash objects or entire Flash applications.
+
+
+
+
For a text alternative to be applied to a non-text object, it must be saved as a symbol
+ in the movie's library. Note: Flash does not support text alternatives for graphic symbols. Instead, the graphic
+ must be converted to or stored in a movie clip or button symbol.
+
+
+
Bring up the Accessibility panel by selecting "Window > Other Panels > Accessibility"
+ in the application menu, or through the shortcut ALT + F11. Ensure that the 'Make
+ object accessible' checkbox is checked.
+
+
+
Select the non-text instance on the movie stage, the fields in the Accessibility panel
+ become editable.
+
+
+
Enter a meaningful text alternative in the 'name' field, properly describing the purpose
+ of the symbol.
+
+
+
+
+
+
+
Example 2: Applying textual alternatives programmatically in ActionScript 2.0
+
To manage an object's text equivalent programmatically using ActionScript 2, the
+ _accProps object must be used. This references an object containing accessibility
+ related properties set for the object. The code example below shows a simple example
+ of how the _accProps object is used to set an objects name in ActionScript.
+
// 'print_btn' is an instance placed on the movie's main timeline
+_root.print_btn._accProps = new Object();
+_root.print_btn._accProps.name = "Print";
+
+
Example 3: Applying textual alternatives programmatically in ActionScript 3.0
+
To manage an object's text equivalents programmatically using ActionScript 3, the
+ AccessibilityProperties object and name property must be used. The code example below shows a simple example of how the
+ name property is used to set an objects name in ActionScript.
+
// 'print_btn' is an instance placed on the movie's main timeline
+print_btn.accessibilityProperties = new AccessibilityProperties();
+print_btn.accessibilityProperties.name = "Print";
Open the SWF file in Internet Explorer 6 or higher (using Flash Player 6 or higher),
+ or Firefox 3 or higher (using Flash Player 9 or higher)
+
+
+
Use a tool which is capable of showing an object's name text alternative, such as
+ ACTF aDesigner 1.0 to open the Flash movie.
+
+
+
In the GUI summary panel, loop over each object which is contained by the Flash movie
+ and ensure the object that was provided a name has a proper name attribute appearing
+ in the tool's display.
+
+
+
Authors may also test with a screen reader, by reading the Flash content and listening
+ to hear that the equivalent text is read when tabbing to the non-text object (if
+ it is tabbable) or hearing the alternative text read when reading the content line-by-line.
+
+
+
All non-text objects have text equivalents that can serve the same purpose and convey
+ the same information as the non-text object
+
+
+
+
+
+
+
Expected Results
+
+
Check #6 is true.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH10.html b/wcag21/techniques/flash/FLASH10.html
new file mode 100644
index 0000000..c54f070
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH10.html
@@ -0,0 +1,128 @@
+
+
+
+
+ FLASH10: Indicating required form controls in Flash
+
+
+
+
+
+
+
+
Indicating required form controls in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a clear indication that a specific
+ form control in a Web application or form is required for successful data submission.
+ The word "required" is added to the form control's accessible name, and a visual
+ indicator is placed next to the label.
+
+
+
+
Examples
+
+
Example 1: Adding the word "required" to the control's accessible name
+
This example shows how to use the Accessibility panel to indicate a field as being
+ 'required' to users:
+
+
+
+
Visually, place asterisk character or some other indication adjacent to the form
+ control's label.
+
+
+
Use the Accessibility panel to combine the word "required" with the control's label
+ in the "Name" field.
+
+
+
+
This approach is illustrated in the screenshot below:
For each required form control within a Flash movie, confirm that:
+
+
+
+
The required state is indicated visually
+
+
The required state is indicated textually using the 'Name' field in the Accessibility
+ panel
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Each of the above is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH11.html b/wcag21/techniques/flash/FLASH11.html
new file mode 100644
index 0000000..a893d0e
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH11.html
@@ -0,0 +1,169 @@
+
+
+
+
+ FLASH11: Providing a longer text description of an object
+
+
+
+
+
+
+
+
Providing a longer text description of an object
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to a provide longer, more detailed textual information
+ for an image than would be suitable for the image's accessible name. An accessible
+ button is provided adjacent to the image that displays a new panel containing the
+ image's long description text.
+
+
+
+
Examples
+
+
Example 1: Making a hidden description visible on request
+
In this example, an image containing statistical data is shown. The image is provided
+ a short textual alternative ("Graph of percentage of total U.S. noninsitutionalized
+ population age 16-64 declaring one or more disabilities"). Below the image, the
+ user can click a button that will overlay a long textual description of the statistical
+ information itself. When the button is clicked, the following actions are taken:
+
+
+
+
+
The MovieClip containing the long text description is made visible, and its AccessibilityProperties.silent property is set to false to make it visible to assistive technology. Its contents
+ are placed in the tab order.
+
+
+
The original image and button are temporarily hidden from assistive technology
+ and the tab order.
+
+
+
+
The image and descriptive text were taken from a previously published HTML example
+ for long image descriptions on WebAIM.org
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH12.html b/wcag21/techniques/flash/FLASH12.html
new file mode 100644
index 0000000..29b6724
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH12.html
@@ -0,0 +1,211 @@
+
+
+
+
+ FLASH12: Providing client-side validation and adding error text via the accessible description
+
+
+
+
+
+
+
+
Providing client-side validation and adding error text via the accessible description
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to validate user input as values are entered
+ for each field, by means of client-side scripting. If errors are found, a description
+ is added to the controls that have invalid data. Visually, the description will
+ be placed adjacent to the control. Additionally, the error message text is added
+ to the control's accessible description so that it is readable by assistive technology
+ when the control receives focus.
+
+
+
+
Examples
+
+
Example 1: Validating a text field
+
In this example, a sample form is shown with two text fields ('name' and 'zip code').
+ Both fields are required. When the form's submit button is pressed, the values of
+ the text fields will be validated. If a textfield contains an invalid value, an
+ _accProps object is created for the textfield, and its description property is set the error message.
+
+
+
Note
+
+
+
Instead of using the accessible description, the error text can also be added to
+ the accessible name (_accProps.name), which is supported by a wider range of assistive technology than the _accProps.description property.
+
+
+
+
+
ActionScript 2.0 Code
import flash.accessibility. *;
+import mx.accessibilty.ButtonAccImpl;
+import mx.controls.Alert;
+import mx.accessibility.AlertAccImpl;
+
+AlertAccImpl.enableAccessibility();
+ButtonAccImpl.enableAccessibility;
+
+resetTextFieldAccNames();
+Accessibility.updateProperties();
+
+submit_btn.addEventListener("click", handleClick);
+function handleClick(e) {
+ //reset values
+ resetTextFieldAccNames();
+ resetTextFieldAccDescriptions();
+ resetErrorLabels();
+ //perform validation
+ var errors =[];
+ if (name_txt.text == '')
+ errors.push([name_txt, "You must enter your name", name_error_lbl]);
+ if (zipcode_txt.text == '')
+ errors.push([zipcode_txt, "You must enter your zip code", zipcode_error_lbl]);
+ else if (zipcode_txt.text.length != 5 || isNaN(zipcode_txt.text))
+ errors.push([zipcode_txt, "Zip code must be 5 digits", zipcode_error_lbl]);
+
+ //add validation error messages, if any
+ var field, errorMsg, errorLabel;
+ if (errors.length > 0) {
+ //loop over encountered errors
+ for (var i = 0; i < errors.length; i++) {
+ field = errors[i][0];
+ errorMsg = errors[i][1];
+ errorLabel = errors[i][2];
+
+ updateAccDescription(field, "Warning: " + errorMsg);
+ errorLabel.text = errorMsg;
+ }
+ } else {
+ Alert.show("Form field values were entered correctly");
+ }
+ Accessibility.updateProperties();
+}
+
+function updateAccName(obj, newName: String) {
+ if (! obj._accProps)
+ obj._accProps = new Object();
+ obj._accProps.name = newName;
+}
+
+function updateAccDescription(obj, newDescription: String) {
+ if (! obj._accProps)
+ obj._accProps = new Object();
+ obj._accProps.description = newDescription;
+}
+
+function getAccName(obj) {
+ return obj._accProps? obj._accProps.name: "";
+}
+
+function resetTextFieldAccNames() {
+ updateAccName(name_txt, "name, required");
+ updateAccName(zipcode_txt, "zip code, required");
+}
+
+function resetTextFieldAccDescriptions() {
+ updateAccDescription(name_txt, "");
+ updateAccDesciption(zipcode_txt, "");
+}
+
+function resetErrorLabels() {
+ name_error_lbl.text = "";
+ zipcode_error_lbl.text = "";
+}
When a Flash movie provides interactive forms that can be submitted, confirm that:
+
+
+
+
+
+
The validation warnings are placed next to the control visually.
+
+
The validation warnings are added to the accessible name or description of each
+ control.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH13.html b/wcag21/techniques/flash/FLASH13.html
new file mode 100644
index 0000000..e8c9874
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH13.html
@@ -0,0 +1,202 @@
+
+
+
+
+ FLASH13: Using HTML language attributes to specify language in Flash content
+
+
+
+
+
+
+
+
Using HTML language attributes to specify language in Flash content
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to identify the default language of the Flash
+ content by providing the lang and/or xml:lang attribute on the HTML or object elements
+ for the page containing the Flash. The embedded Flash content will inherit the language
+ specified. If the entire web page uses the same language, the lang and/or xml:lang
+ attribute can be placed on the page's HTML element, as described in H57: Using the language attribute on the HTML element.
+
+
Since Flash inherits the language from the HTML or object element, all text within
+ the Flash content is expected to be in that inherited language. This means that
+ it is possible to have a Flash object in the French language on a page that is primarily
+ in another language, or to have a page with multiple Flash objects, each in a
+ different language. It is not possible, however, to indicate changes in the human
+ language of content within a single Flash object using this technique.
+
+
+
+
Examples
+
+
Example 1: Using the language of the page as whole in the embedded Flash
+
This example defined the content of the entire web page to be in the French language.
+ The Flash content will inherit the specified language from the HTML container.
+
Example 2: Applying a language just to the embedded Flash
+
This example defines the content of a Flash movie to be in the French language.
+ The Flash movie is embedded using SWFObject's static publishing method. This means that there are two nested object elements, the outer to target Internet
+ Explorer, the Inner to target other browsers. For this reason the lang and xml:lang
+ attributes must be added twice.
+
Examine the html element and the object element of the HTML document containing
+ the reference to the SWF.
+
+
+
Check that the human language of the Flash content is the same as the inherited
+ language for the object element as specified in HTML 4.01, Inheritance of language
+ codes
+
+
+
Check that the value of the lang attribute conforms to BCP 47: Tags for the Identification
+ of Languages or its successor and reflects the primary language used by the Flash
+ content.
+
+
+
Check that no changes in human language occur within the Flash content
+
+
+
+
+
+
Expected Results
+
+
+
+
For Success Criterion 3.1.1: Checks 1-3 are all true.
+
+
For Success Criterion 3.1.2: Checks 1-4 are all true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH14.html b/wcag21/techniques/flash/FLASH14.html
new file mode 100644
index 0000000..35a94ff
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH14.html
@@ -0,0 +1,179 @@
+
+
+
+
+ FLASH14: Using redundant keyboard and mouse event handlers in Flash
+
+
+
+
+
+
+
+
Using redundant keyboard and mouse event handlers in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to demonstrate how to provide device independence
+ by providing equivalent event handlers in response to a mouse or focus event. Supporting
+ both mouse and keyboard events ensures that users will be able to perceive the same
+ information, regardless of the input device they used. If the event changes the
+ state of the control, it may be important to change the descriptive name of the
+ control in the event handlers.
+
+
+
+
Examples
+
+
Example 1: Updating button text with multiple event handlers
+
In this example, a group of buttons is assigned the same event handlers for the
+ flash.events.FocusEvent.FOCUS_IN and flash.events.MouseEvent.MOUSE_OVER events.
+ When a button receives focus or is hovered over using a mouse, text describing the
+ button will be updated.
+
import fl.accessibility.ButtonAccImpl;
+import fl.controls.Button;
+import flash.accessibility. *
+import flash.events.FocusEvent;
+import flash.events.MouseEvent;
+import flash.net.navigateToURL;
+import flash.net.URLRequest;
+
+ButtonAccImpl.enableAccessibility();
+var states: Object = {
+ "Alabama": "Alabama is a state located in the southeastern region of the \
+ United States of America.",
+ "California": "California is the most populous state in the United States",
+ "New York": "New York is a state in the Mid-Atlantic and Northeastern \
+ regions of the United States"
+};
+
+var buttons: Array =[];
+var button: Button;
+var accProps: AccessibilityProperties;
+var count = 0;
+for (var i in states) {
+ button = new Button();
+ button.label = i;
+ button.addEventListener(MouseEvent.CLICK, clickHandler);
+ button.addEventListener(MouseEvent.MOUSE_OVER, highlightHandler);
+ button.addEventListener(MouseEvent.MOUSE_OUT, unHighlightHandler);
+ button.addEventListener(FocusEvent.FOCUS_IN, highlightHandler);
+ button.addEventListener(FocusEvent.FOCUS_OUT, unHighlightHandler);
+ accProps = new AccessibilityProperties();
+ accProps.description = states[i];
+ button.accessibilityProperties = accProps;
+ addChild(button);
+ button.x = 30
+ button.y = 30 + count * 30;
+ buttons[i] = button;
+ count++;
+}
+
+function highlightHandler(e) {
+ descText.text = states[e.target.label];
+}
+
+function unHighlightHandler(e) {
+ descText.text = "";
+}
+
+
+function clickHandler(e) {
+ var url: URLRequest = new URLRequest("http://www.wikipedia.org/wiki/" + e.target.label);
+ navigateToURL(url, "_self");
+}
+
Note
+
+
+
To improve accessibility for screen reader users, the descriptive text is also attached
+ to the buttons themselves as an accessible description. Also note that for button
+ components, the MouseEvent.CLICK event will fire on mouse clicks as well as when
+ the Enter key is pressed.
+
Confirm that event handlers are assigned for both mouse and keyboard events
+
+
+
+
+
+
Expected Results
+
+
+
+
The above is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH15.html b/wcag21/techniques/flash/FLASH15.html
new file mode 100644
index 0000000..710db41
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH15.html
@@ -0,0 +1,260 @@
+
+
+
+
+ FLASH15: Using the tabIndex property to specify a logical reading order and a logical tab order
+ in Flash
+
+
+
+
+
+
+
+
+
Using the tabIndex property to specify a logical reading order and a logical tab order
+ in Flash
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to control the Flash Movie's reading order and
+ tab order by assigning tabIndex values to its elements.
+
+
The tab order is the order in which objects receive input focus when users press the
+ Tab key. The tab order does not necessarily contain the same elements as the reading
+ order does, as the reading order can also contain elements that are not focusable.
+ However, both the reading order and tab order can be controlled using tab index values.
+
+
+
Flash Player uses a default tab index order from left to right and top to bottom.
+
To create a custom reading order, assign a tab index value to every instance on the
+ stage, either through ActionScript or through the Accessibility panel. Create a tabIndex
+ value for every accessible object, not just the focusable objects. For example, dynamic
+ text must have tab indexes, even though a user cannot tab to dynamic text.
+
+
You can create a custom tab-order index in the Accessibility panel for keyboard navigation
+ for the following objects:
+
+
+
+
Dynamic text
+
+
Input text
+
+
Buttons
+
+
Movie clips, including compiled movie clips
+
+
Components
+
+
Screens
+
+
+
Tab focus occurs in numerical order, starting from the lowest index number. After
+ tab focus reaches the highest tab index, focus returns to the lowest index number.
+ When you move tab-indexed objects that are user-defined in your document, or to another
+ document, Flash retains the index attributes. Check for and resolve index conflicts
+ (for example, two different objects on the Stage with the same tab-index number).
+ If two or more objects have the same tab index in any given frame, Flash follows the
+ order in which the objects were placed on the Stage.
+
+
To add a tabIndex value using the Accessibility panel, perform the following steps
+ for every accessible object on the stage:
+
+
+
+
Select the element by clicking on it.
+
+
In the Accessibility panel, enter a numeric value in the "Tab index" field. The
+ value must be a positive integer (up to 65535) that reflects the order in which
+ the selected object should be read. Elements with higher tab index values will be
+ read after elements with lower values. If two or more objects have the same tab
+ index in any given frame, Flash follows the order in which the objects were placed
+ on the Stage.
+
+
+
To visualize the currently defined tab order, select View > Show Tab Order. Tab
+ index numbers for individual objects appear in the upper-left corner of the object.
+
+
+
+
+
+
Note
+
+
+
You can also use ActionScript code to create a tab-order index for keyboard navigation.
+
+
+
+
+
+
These steps are illustrated in the screenshots below
+
+
+
+
Note
+
+
+
Flash Player no longer requires that you add all of the objects in a FLA file to
+ a list of tab index values. Even if you do not specify a tab index for all objects,
+ a screen reader reads each object correctly.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Using tabIndex to navigate a column structure
+
This example contains dynamic TextField instances that are grouped into columns.
+ To ensure the reading order follows the column structure. The TextField instances
+ are given a tab index value that corresponds to their textual content (for example,
+ the TextField containing the text "Sample Text 3" has a tabindex value of 3. Additionally,
+ a single TextField is added that has no tabindex value set. This field contains
+ the text "Not in tab order". Even though this field is visually placed between sample
+ text 2 and 3, it is placed at the end of the custom tab order because it is not
+ assigned a tabindex value.
+
Example 2: Controlling tab order in a two-column layout
+
This example contains a Flash based form that is laid out over two
+ columns. To make the tab order follow the column structure, each form
+ control is assigned a tab index value in the Accessibility panel.
+
Use a screen reader to navigate through the Flash movie, one element at a time.
+
+
+
+
Check that the order in which the screen reader announces the content, matches the
+ logical visual order.
+
+
+
When focus has been placed inside the Flash movie, press the Tab key repeatedly to
+ traverse its contents by keyboard.
+
+
+
Verify that all interactive and focusable elements are reachable by keyboard, in a
+ logical order.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #2 and #4 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH16.html b/wcag21/techniques/flash/FLASH16.html
new file mode 100644
index 0000000..48bb44b
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH16.html
@@ -0,0 +1,135 @@
+
+
+
+
+ FLASH16: Making actions keyboard accessible by using the click event on standard components
+
+
+
+
+
+
+
+
Making actions keyboard accessible by using the click event on standard components
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to demonstrate how to invoke a scripting function
+ in a way that is keyboard accessible by attaching it to keyboard-accessible, standard
+ Flash components provided by the Adobe Flash Professional authoring tool. In order
+ to ensure that scripted actions can be invoked from the keyboard, they are associated
+ with standard Flash components such as the Button component. The click event of
+ these components is device independent. While the "CLICK" event is a mouse event,
+ it is actually mapped to the default action of a button. The default action occurs
+ when the user clicks the element with a mouse, but it also occurs when the user
+ focuses the element and hits the space key, and when the element is triggered via
+ the accessibility API.
+
+
+
+
Examples
+
+
Example 1: Click event on a button
+
This example shows a button that uses the MouseEvent.CLICK event to change its label.
+ This event will fire both on mouse click and when the space key is pressed
+
When a Flash Movie contains interactive controls, confirm that:
+
+
+
+
Standard Flash components are used for the controls
+
+
The controls use the "click" event
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH17.html b/wcag21/techniques/flash/FLASH17.html
new file mode 100644
index 0000000..bdbd1ea
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH17.html
@@ -0,0 +1,395 @@
+
+
+
+
+ FLASH17: Providing keyboard access to a Flash object and avoiding a keyboard trap
+
+
+
+
+
+
+
+
Providing keyboard access to a Flash object and avoiding a keyboard trap
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to allow keyboard focus to move to and from Flash
+ content embedded in a web page. In browsers other than Internet Explorer, there
+ is a problem related to keyboard accessibility of embedded Flash content. The problem
+ is that, while both the Flash content and the HTML content around it may be keyboard
+ accessible, many browsers do not support moving keyboard focus between the Flash content
+ and HTML content without using a mouse. Once focus is placed inside the Flash
+ content, a keyboard user will be trapped there. Similarly, when focus is placed
+ somewhere else on the HTML content (outside the Flash content), it will be impossible
+ to move focus into the content. This technique is designed to let the Flash author
+ address this issue and provide support for moving focus between the Flash content
+ and the HTML content via the keyboard.
+
+
This issue has been around for a long time, and is related to the way browsers implement
+ embedded plug-ins. Until this problem is fixed, it is up to the Flash developer
+ to come up with a work around. This technique is one of those workarounds. The approach
+ behind this technique is the following:
+
+
+
+
Two 'neighbor' focusable HTML objects are identified for each Flash content in
+ the document (one before and one after the content). These elements can be any HTML
+ elements that are part of the web page's tab order (such as links and form controls).
+
+
+
+
The Flash content object itself is added to the document tab order as well, making
+ it possible to tab into the content.
+
+
+
Inside the Flash content, the Flash Player maintains its own tab order. Normally,
+ when the start or end of the Flash tab order is reached (when tabbing through the
+ content), focus will wrap to the beginning or end of the content's tab order, and
+ it will not be possible to (shift) tab out of it. With this technique however, when
+ a 'focus wrap' is detected focus will instead be moved to the neighboring element
+ in the HTML tab order (allowing a keyboard user to 'break out' of the Flash tab
+ order).
+
+
+
+
When the SWFFocus class is imported into a Flash project, the following will happen:
+
+
+
+
+
+
+
A JavaScript <script> tag will be generated and added to the HTML document containing
+ the Flash content. This JavaScript code will:
+
+
+
+
+
Set a tabIndex value of "0" on the <object> element of each Flash content found
+ in the page. This causes the Flash objects to become part of the tab order.
+
+
+
Optionally, create a hidden anchor element before and after the Flash content,
+ which is used by the SWFFocus class to move focus out of the Flash content back
+ into the HTML page. Alternatively, the developer can specify existing focusable
+ HTML elements as adjacent tab stops for the Flash content.
+
+
+
Set event handlers for the Flash content object, so that when it receives focus,
+ the SWFFocus class is notified to manage the content's internal tab order.
+
+
+
+
+
+
+
The SWFFocus class monitors changes in focus within the Flash content. When a focus
+ wrap is detected in the content, a JavaScript function will be called to instead
+ move focus back to the neighboring HTML content.
+
+
+
+
As indicated above, there are two ways in which this technique can be used:
+
+
+
+
+
Letting the SWFFocus class generate neighboring focusable elements in the HTML tab
+ order for each Flash content (demonstrated in example 1 below)
+
+
+
By default, the SWFFocus class will create a hidden link element before and after
+ an embedded Flash content. These elements are needed as 'anchor' to move focus to
+ when (shift) tabbing out of the Flash content. This approach is the easiest to implement,
+ as it does not require any additional work by the developer. The downside is that
+ the hidden links will clutter the HTML tab order with meaningless elements (although
+ these elements are only used as tab stops when tabbing _out of_ the Flash content,
+ not when tabbing _into_ it). Because of this, it is recommended to use the following
+ approach instead:
+
+
+
+
+
+
+
Explicitly identifying focusable HTML elements that come before and after the a
+ Flash content in the HTML tab order (demonstrated in example 2 below)
+
+
+
With this approach, the developer can use ID values to identify the elements that
+ come before and after the Flash content in the HTML tab order. This is done by setting
+ special class names on the Flash content's <object> element. This is the preferred
+ approach, as it does not cause an unnecessary cluttering of the tab order. However,
+ it does require more work and awareness by the developer (who has to manually set
+ ID values). Also, in some scenarios there simply may not be a next or previous focusable
+ element for a Flash content.
+
To run the example from a local drive (as opposed to running it from a web server),
+ the local directory needs to be added to Flash Player's security settings.
+
+
+
+
+
+
Example 1: Using automatically generated links
+
In this example, the SWFFocus class is used without explicitly identifying focusable
+ HTML elements. This will cause SWFFocus to dynamically insert hidden links before
+ and after the Flash content.
+
+
Loading the Flash Content
+
The Flash object in this example is added using SWFObject's dynamic publishing method, which means that the object tag is created dynamically by JavaScript in a way
+ that the browser supports. While this is the recommended approach, it is not a
+ requirement for using this technique. The SWFFocus class will also work when the
+ object tag is hardcoded into the HTML document.
+
+
The sample code below shows how to load the content dynamically with SWFObject.
+
+
+
HTML and Javascript Code Sample for Example 1
<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>Keyboard Trap Fix Example</title>
+ <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
+ <script src="swfobject_2_1.js" type="text/javascript"/>
+ <script type="text/javascript">
+ var flashvars = {};
+ var params = {};
+ params.scale = "noscale";
+ var attributes = {};
+ attributes.id = "FlashSample1SWF";
+ attributes.name = "FlashSample1SWF";
+ swfobject.embedSWF("keyboard_trap_fix_custom_as3.swf", "flashSample1", \
+ "150", "200", "9.0.0", "expressInstall.swf", flashvars, params, attributes);
+</script>
+ </head>
+ <body>
+ <p>The following Flash content automatically generates invisible
+ links before and after the flash content, allowing keyboard focus
+ to move out of the Flash content.</p>
+ <div id="flashSample1">
+ <a href="http://www.adobe.com/go/getflashplayer">
+ <img alt="Get Adobe Flash player"
+ src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif"
+ />
+ </a>
+ </div>
+ </body>
+</html>
Importing and Initializing the SWFFocus class in Flash
+
The SWFFocus class needs to be added to a Flash or Flex project's source path. The
+ easiest way to achieve this is to import the SWFFocus.swc into Library path for your
+ project or to copy the com/swffocus/SWFFocus.as file (including the nested directory
+ structure) to the project's root directory.
+
+
When the SWFFocus class is added to the content's source path, it needs to be initialized
+ with the following code:
+
The code for the class itself can be found in the source files.
+
+
+
Example 2: Explicitly identifying existing focusable html element
+
For a large part, this technique is the same as example 1 :
+
+
+
The dynamic loading approach by SWFObject is used to load the Flash content
+
+
The SWFFocus class needs to be added to the content's sourcepath and initialized
+ in the Flash content
+
+
+
+
For more details about these steps, see example 1.
+
In this case however, special class names are added to the Flash content object.
+ These class names indicate the ID values of the elements previous and next of the
+ content in the HTML tab order. The class names are:
+
+
+
+
'swfPref-<previous ID>', where '<previous element>' should be the ID value of the
+ previous element in the tab order.
+
+
+
'swfNext-<next ID>', where '<next element>' should be the ID value of the next
+ element in the tab order.
+
+
+
+
For example, the HTML code could look like this (notice the added class names on
+ the object tag):
+
Since this example uses SWFObject's dynamic loading, the class names will have to
+ be specified as attribute when SWFObject is initialized. This is demonstrated in
+ the code example below.
+
+
HTML and Javascript Code Sample for Example 2
<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <title>Keyboard Trap Fix Example </title>
+ <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
+ <script src="swfobject_2_1.js" type="text/javascript"/>
+
+ <script type="text/javascript">
+ var flashvars = {};
+ var params = {};
+ params.scale = "noscale";
+ var attributes = {};
+ attributes.id = "FlashSample2SWF";
+ attributes.name = "FlashSample2SWF";
+ attributes["class"] = "swfPrev-focus1 swfNext-focus2";
+ swfobject.embedSWF("keyboard_trap_fix_as3.swf", "flashSample1", "150",
+ "200", "9.0.0", "expressInstall.swf", flashvars, params, attributes);
+ </script>
+ </head>
+ <body>
+ <a href="http://www.lipsum.com/" id="focus1">lorem</a>
+ <p>The following Flash content uses existing links in the document
+ to move focus to when (shift) tabbing out of the Flash content.
+ The existing links are defined by placing special classnames on
+ the Flash object.</p>
+ <div id="flashSample2">
+ <a href="http://www.adobe.com/go/getflashplayer">
+ <img alt="Get Adobe Flash player"
+ src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif"
+ />
+ </a>
+ </div>
+ <a href="http://www.lipsum.com/">lorem</a>
+ </body>
+</html>
Note: this example assumes that the focusable HTML elements exist and have an ID
+ value at the time SWFObject is called to insert the Flash content. However, in some
+ situations it is also possible that these elements do not yet exist when the Flash
+ content is created, or that the elements will be deleted dynamically at a later
+ point. If this happens, it is possible to reassign ID values for previous and next
+ focusable elements. To do this, call the SWFsetFocusIds() method on the Flash
+ content object, like so:
+
var o = document.getElementById("FlashSample1SWF");
+o.SWFsetFocusIds('prevId', 'nextId');
From that point on the updated IDs will be used to move focus to when tabbing out
+ of the Flash content.
+
+
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
If possible, confirm that the source of the Flash content imports and initializes
+ the SWFFocus class
+
+
+
Press the tab key to move through tabbable items on the page
+
+
Confirm that it is possible to tab into the Flash content
+
+
Continue tabbing and confirm that it is possible to tab out of the flash content
+
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks 3 and 4 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH18.html b/wcag21/techniques/flash/FLASH18.html
new file mode 100644
index 0000000..26bf96f
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH18.html
@@ -0,0 +1,254 @@
+
+
+
+
+ FLASH18: Providing a control to turn off sounds that play automatically in Flash
+
+
+
+
+
+
+
+
Providing a control to turn off sounds that play automatically in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The intent of this technique is to allow a user to turn off sounds that start automatically
+ when a Flash movie loads. The control to turn off the sounds should be located near
+ the beginning of the page to allow the control to be easily and quickly discovered
+ by users . This is useful for those who utilize assistive technologies (such as
+ screen readers, screen magnifiers, switch mechanisms, etc.) and those who may
+ not (such as those with cognitive, learning and language disabilities).
+
+
In this technique, an author includes a control that makes it possible for users
+ to turn off any sounds that are played automatically. For maximum accessibility,
+ the control can be added to the HTML document rather than to the Flash movie. The
+ HTML control will communicate with the Flash movie through the ExternalInterface
+ class. This means that the user can control the sound playback without having
+ to interact with Flash content. If this is not practical, the control can be provided
+ within the Flash content, provided that the control is keyboard operable, located
+ early in the tab and reading order, and clearly labeled to indicate that it will
+ turn off the sounds that are playing.
+
+
+
+
Examples
+
+
Example 1: Providing a button in the Flash to stop sound
+
This example demonstrates the addition of a button within the Flash movie to allow
+ the user to stop sounds from playing. A class called SoundHandler is created which
+ automatically starts playing an mp3 file when the movie loads.
+
Example 2: Providing a button in the HTML before the Flash object to stop sound
+
A class called SoundHandler is created which automatically starts playing an mp3
+ file when the movie loads. An HTML button is placed in the HTML document containing
+ the Flash movie. When the button is clicked the action is communicated between the
+ HTML page and the Flash movie via the Flash Player JavaScript API, resulting in
+ the toggleSound method being called on the SoundHandler class.
+
+
ActionScript 3.0 code for Example 2
package wcagSamples {
+ import flash.display.Sprite;
+ import flash.external.ExternalInterface;
+ import flash.net.URLRequest;
+ import flash.media.Sound;
+ import flash.media.SoundChannel;
+
+ import flash.events.MouseEvent;
+ public class SoundHandler extends Sprite {
+ private var snd: Sound = new Sound();
+ private var soundOn: Boolean = true;
+ private var req: URLRequest = new URLRequest("http://av.adobe.com/podcast/\
+ csbu_dev_podcast_epi_2.mp3");
+ private var channel: SoundChannel = new SoundChannel();
+
+ public function SoundHandler() {
+ if (ExternalInterface.available)
+ ExternalInterface.addCallback("toggleSound", this.toggleSound);
+ snd.load(req);
+ channel = snd.play();
+ }
+
+ private function toggleSound(enable: Boolean): void {
+ if (! enable) {
+ channel.stop();
+ soundOn = true;
+ } else {
+ channel = snd.play();
+ soundOn = true
+ }
+ }
+ }
+}
HTML code for Example 2
<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
+ <title>Flash Sound Toggle example</title>
+ <script src="swfobject.js" type="text/javascript"/>
+ <script type="text/javascript">
+ function $(id) {
+ return document.getElementById(id);
+ }
+
+ swfobject.embedSWF("html_control_to_toggle_audio_as3.swf",
+ "flashPlaceHolder", "0", "0", "8");
+ function init() {
+ var soundOn = true;
+ $("soundToggle").onclick = function(event){
+ soundOn = !soundOn;
+ $("flashPlaceHolder").toggleSound(soundOn);
+ event.target.value = soundOn ? "Stop Sound" : "Start Sound";
+ };
+ }
+ window.onload = init;
+</script>
+
+ </head>
+ <body id="header">
+ <h1>Flash Automatic Sound Demo</h1>
+ <p>This page contains a Flash movie that automatically starts
+ playing sound. Use the button below to stop or start the
+ sound</p>
+ <input id="soundToggle" type="button" value="Stop Sound"/>
+ <p id="flashPlaceHolder">Flash needs to be installed for this
+ example to work</p>
+ </body>
+</html>
+
For Flash movies that automatically start playing sound after loading:
+
+
+
+
Confirm that an HTML control that conforms to WCAG 2.0 is placed at the beginning
+ of the document's tab order
+
+
+
If there is no HTML-based control, confirm that an accessible control is placed
+ at the beginning of the Flash movie's tab order.
+
+
+
Activate the HTML or Flash-based control
+
+
Verify that audio playback stops
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #1 or #2 is true, and #4 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH19.html b/wcag21/techniques/flash/FLASH19.html
new file mode 100644
index 0000000..7d59761
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH19.html
@@ -0,0 +1,166 @@
+
+
+
+
+ FLASH19: Providing a script that warns the user a time limit is about to expire and provides
+ a way to extend it
+
+
+
+
+
+
+
+
+
Providing a script that warns the user a time limit is about to expire and provides
+ a way to extend it
+
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to notify users that they are almost out of time
+ to complete an interaction. When scripts provide functionality that has time limits,
+ the script can include functionality to warn the user of imminent time limits and
+ provide a mechanism to request more time. 20 seconds or more before the time limit
+ occurs, the script provides a confirm dialog that states that a time limit is
+ imminent and asks if the user needs more time. If the user answers "yes" then the
+ time limit is reset. If the user answers "no" or does not respond, the time limit
+ is allowed to expire.
+
+
This technique involves time limits set with the setTimeout() method. If, for example,
+ the time limit should be 60 seconds, you can set the time limit for 40 seconds (20
+ seconds less than the desired timeout) and show a confirm dialog. The confirm dialog
+ sets a new timeout for the remaining 20 seconds. If the user requests more time,
+ a new timeout is set. However, if the 20-second "grace period time limit" expires
+ (meaning 60 seconds have now elapsed), the action appropriate for the expiry of
+ the 60 second time limit in the original design is taken.
+
+
+
+
Examples
+
+
Example 1: Using ActionScript to offer a time limit extension before the timeout expires
+
This is a basic AS2 example of a time limit that can be extended by the user. An
+ alert is shown after 40 seconds of inactivity, warning that the session is about
+ to expire. The user is given 20 seconds to press the space bar or click on the "Yes"
+ button. Note that the 40 second duration would be insufficient for most tasks and
+ is artificially short for ease of demonstration.
+
import mx.controls.Alert;
+import flash.accessibility.Accessibility;
+
+mx.accessibility.AlertAccImpl.enableAccessibility();
+
+var sessionTimeout;
+var sessionNotificationTimeout;
+var timeLimit: Number = 60000;
+var sessionAlert: Alert;
+resetTimeout();
+
+testField.addEventListener("change", resetTimeout);
+
+function resetTimeout() {
+ clearTimeout(sessionTimeout);
+ clearTimeout(sessionNotificationTimeout);
+ sessionTimeout = setTimeout(endSession, timeLimit);
+ sessionNotificationTimeout = setTimeout(showTimeoutAlert, timeLimit - 20000);
+}
+
+function showTimeoutAlert() {
+ sessionAlert = Alert.show("Click the YES button to extend your session",
+ "Your login session is about to expire, do you need more time?",
+ Alert.YES | Alert.NO, null, handleAlertClick);
+}
+
+function endSession() {
+ sessionAlert.deletePopUp();
+ Alert.show("please log in again",
+ "Your session has expired");
+}
+
+function handleAlertClick(e) {
+ if (e && e.detail && e.detail == Alert.YES)
+ resetTimeout();
+}
load the page and start a timer that is 20 seconds less than the time limit.
+
+
when the timer expires, check that a confirmation dialog is displayed warning of
+ the impending time limit and allows the user to extend the limit within 20 seconds.
+
+
+
+
+
+
+
+
Expected Results
+
+
Check #2 is true
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH2.html b/wcag21/techniques/flash/FLASH2.html
new file mode 100644
index 0000000..522a97f
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH2.html
@@ -0,0 +1,226 @@
+
+
+
+
+ FLASH2: Setting the description property for a non-text object in Flash
+
+
+
+
+
+
+
+
Setting the description property for a non-text object in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a long text alternative that serves
+ the same purpose and presents the same information as the original non-text content
+ when a short text alternative is not sufficient.
+
+
The Flash Player supports long text alternatives to non-text objects, which can be
+ defined in ActionScript or within Flash authoring tools using the description property, as indicated in the examples below.
+
+
+
+
Examples
+
+
Example 1: Applying a Description for a symbol (graphic, button or movieclip)
+
The Flash Professional authoring tool's Accessibility panel lets authors provide
+ accessibility information to assistive technology and set accessibility options for
+ individual Flash objects or entire Flash applications.
+
+
+
+
For a text alternative to be applied to a non-text object, it must be saved as a
+ symbol in the movie's library. Note: Flash does not support text alternatives for graphic symbols. Instead, the graphic
+ must be converted to or stored in a movie clip or button symbol.
+
+
+
Bring up the Accessibility panel by selecting "Window > Other Panels > Accessibility"
+ in the application menu, or through the shortcut ALT + F11. Ensure that the 'Make
+ object accessible' checkbox is checked.
+
+
+
Select the non-text instance on the movie stage, the fields in the Accessibility
+ panel become editable.
+
+
+
Enter a description describing the non-text object's contents concisely. For example,
+ a diagram could have a 'name' identifying what information the diagram conveys, while
+ the 'Description' field lists this information in full detail. Alternatively, for
+ an animation which is part of an instructional movie about car repairs the name could
+ be: 'how to replace a flat tire', while the long description describes each step
+ of the process in greater detail.
+
+
+
+
+ Important: Only use the 'Description' field if a short text alternative is not sufficient to
+ describe the objects purpose. Otherwise, leave the 'Description' field empty.
+
+
+
+
+
Example 2: Applying Description programmatically in ActionScript 2.0
+
To manage an object's text equivalents programmatically using ActionScript, the _accProps object must be used. This references an object containing accessibility related
+ properties set for the object. The code example below shows a simple example of how
+ the _accProps object is used to set an objects name and description in ActionScript.
+
+
A chart showing sales for October has a short text alternative of "October sales
+ chart". The long description would provide more information, as shown in the code
+ below.
+
// 'chart_mc' is an instance placed on the movie's main timeline
+_root.chart_mc._accProps = new Object();
+_root.chart_mc._accProps.name = "October Sales Chart";
+_root.chart_mc._accProps.description = "Bar Chart showing sales for October.\
+ There are 6 salespersons.Maria is highest with 349 units.Frances is next\
+ with 301.Then comes Juan with 256, Sue with 250, Li with 200 and Max\
+ with 195.The primary use of the chart is to show leaders, so the description\
+ is in sales order.";
+
+
Example 3: Applying Description programmatically in ActionScript 3.0
+
To manage an object's text equivalents programmatically using ActionScript, the AccessibilityProperties object must be used. The code example below shows a simple example of how the AccessibilityProperties object used to set an objects name and description in ActionScript.
+
+
A chart showing sales for October has a short text alternative of "October sales
+ chart". The long description would provide more information, as shown in the code
+ below.
+
// 'chart_mc' is an instance placed on the movie's main timeline
+chart_mc.accessibilityProperties = new AccessibilityProperties();
+chart_mc.accessibilityProperties.name = "October Sales Chart";
+chart_mc.accessibilityProperties.description = "Bar Chart showing sales for October.\
+ There are 6 salespersons.Maria is highest with 349 units.Frances is next\
+ with 301.Then comes Juan with 256, Sue with 250, Li with 200 and Max\
+ with 195.The primary use of the chart is to show leaders, so the description\
+ is in sales order.";
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Open the SWF file in Internet Explorer 6 or higher (using Flash Player 6 or higher),
+ or Firefox 3 or higher (using Flash Player 9 or higher)
+
+
+
Use a tool which is capable of showing an object's long description, such as ACTF
+ aDesigner 1.0 to open the Flash movie.
+
+
+
In the GUI summary panel, loop over each object which is contained by the Flash
+ movie and ensure the object that was provided a description has a proper description
+ value appearing in the tool's display.
+
+
+
Authors may also test with a screen reader, by reading the Flash content and listening
+ to hear that the description is read when tabbing to the non-text object (if it is
+ tabbable) or hearing the alternative text read when reading the content line-by-line.
+
+
+
+
All non-text objects have text equivalents that can serve the same purpose and convey
+ the same information as the non-text object.
+
+
+
+
+
+
+
Expected Results
+
+
#6 is true.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH20.html b/wcag21/techniques/flash/FLASH20.html
new file mode 100644
index 0000000..cef855f
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH20.html
@@ -0,0 +1,330 @@
+
+
+
+
+ FLASH20: Reskinning Flash components to provide highly visible focus indication
+
+
+
+
+
+
+
+
Reskinning Flash components to provide highly visible focus indication
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The purpose of this technique is to allow the author to use ActionScript and component
+ skins to apply a strong visual indication when a component receives focus. In this
+ particular technique, both the component's background color and border will change.
+ When the component loses focus, it returns to its normal styling.
+
+
The visual highlights will be applied by switching some of the component's skin
+ parts. The Standard Flash components each have their own set of skins that make
+ up the component's visual appearance. Each part is represented by a MovieClip which
+ can be edited or replaced in order to customize how the component looks. The most
+ relevant skin for this technique is the focusRectSkin skin, which is shared by
+ all components. By default this skin applies a subtle visual highlight when the
+ component receives focus.
+
+
This technique can be applied through the following steps:
+
+
+
Create a customized version of focusRectSkin.
+
+
Use scripting to associate the component with the customized skin.
+
+
+
There are two ways to customize a skin:
+
+
+
+
+
Duplicating Existing Skin
+
+
With this approach you create a copy of the existing focusRect skin for modification.
+ You will manually have to apply the skin for each individual component instance
+ (as indicated in step 5 below).
+
+
+
+
+
Drag the components you want to style to the stage. This will ensure the appropriate
+ component related skins are added to the movie's library.
+
+
+
Open the Library panel, and navigate to the "Component Assets > Shared" folder.
+
+
+
+
Right-click (or Ctrl-click on a Mac) on the focusRectSkin MovieClip, and choose
+ "Duplicate" from the context menu.
+
+
+
Edit the visual border in the skin's MovieClip. For example, the focus rectangle
+ can be made thicker to stand out more (This step is illustrated in the screenshot
+ below this list).
+
+
+
Using ActionScript, associate form component instances with your customized version
+ of focusRectSkin. This can be achieved using the setStyle method.
+
+
+
+
+
+
+
+
+
+
+
Modifying Existing Skin
+
+
With this approach, the original focusRect skin is modified. This means that the
+ changes you make will be applied to the visual focus indication of _every_ focusable
+ component.
+
+
+
+
+
Drag the components you want to style to the stage. This will ensure the appropriate
+ component related skins are added to the movie's library.
+
+
+
Open the Library panel, and navigate to the "Component Assets > Shared" folder.
+
+
+
+
Open the focusRectSkin MovieClip for editing by double clicking on it.
+
+
Edit the visual border in the skin's MovieClip. For example, the focus rectangle
+ can be made thicker to stand out more.
+
+
+
+
+
+
Note
+
+
+
With this approach you will override the existing skin. If you don't want this,
+ follow the "Duplicate Existing Skin" approach instead.
+
+
+
+
+
+
+
+
+
The focusRect skin applies to all focusable Flash components. If you want to modify
+ other highlights (for example highlights that occur when hovering over a component
+ with the mouse), you will have to edit component specific skins individually. For
+ example, to edit the mouseover highlights for the checkbox component, you will have
+ to modify or duplicate both Checkbox_overIcon and Checkbox_selectedOverIcon. Similarly,
+ for the Button component you will have to modify the Button_over skin.
+
+
Also, keep in mind that the existing skins are automatically applied on certain
+ events (focus, mouseover, etc.). It is however also possible to manually switch
+ a skin at a moment of your own choosing (e.g. to indicate invalid content for a
+ text field). this can also be achieved this by calling the setStyle method.
+
+
+
+
Examples
+
+
Example 1: A thick blue border to indicate focus
+
The code below shows an example where form component instances are associated with
+ a modified version of the focusRectSkin MovieClip. The result is that the components
+ receive a thick blue border rather than the default thin border Flash provides.
+ The code makes a reference to a modified skin called Focus_custom, which has been
+ added to the movie's library in advance.
+
+
Note that the custom version of focusRectSkin also sets a transparent yellow background
+ to increase the visual highlight further. Components such as Buttons and checkboxes
+ will show this background, but TextInput components will not. To ensure the yellow
+ background will still be applied to the TextInput instance, the following workaround
+ is applied:
+
+
+
+
A duplicate version of the TextInput "normal" skin (which can be found in the library
+ at "Component Asssets > TextInputSkins > TextInput_upSkin") is created and edited
+ to show a yellow background.
+
+
+
FocusIn, FocusOut, MouseOver and MouseOut handlers are assigned to the TextInput
+ instance, which temporarily swap the default "normal" skin with the custom "normal"
+ skin while the component is focused or hovered over.
+
+
+
+
Additionally, the button_over skin is duplicated and modified to change the default
+ mouseover highlights for the button component instance. The checkbox_overIcon and
+ checkbox_selectedOverIcon skins are directly modified, which means those changes
+ will be applied to all checkbox instances.
+
When a Flash movie contains focusable components, confirm that:
+
+
+
+
The visual highlight is applied by modifying the component's skins
+
+
A visual highlight is shown when the components receive focus
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH21.html b/wcag21/techniques/flash/FLASH21.html
new file mode 100644
index 0000000..0824068
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH21.html
@@ -0,0 +1,182 @@
+
+
+
+
+ FLASH21: Using the DataGrid component to associate column headers with cells
+
+
+
+
+
+
+
+
Using the DataGrid component to associate column headers with cells
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The intent of this Technique is to ensure that information and relationships that
+ are implied visually by data tables are also made available programmatically. Specifically,
+ the association between table column headers and their corresponding cells must
+ be exposed to assistive technology. In Flash, the DataGrid component can be used
+ to achieve this. When accessibility is enabled for the DataGrid component, Flash
+ will automatically prepend the column name in front of each cell value when exposing
+ the grid row's accessible name to assistive technology. For example, the row in
+ the screenshot below would be announced by a screen reader as "Row 6 of 13 Name
+ Patty Crawford Bats L Throws L Year Jr Home Whittier, CA".
+
+
+
Note
+
+
+
The DataGrid component in Flash only supports column headings, not row headings.
+
+
+
+
+
+
+
+
+
Examples
+
+
Example 1: A statistical data table
+
In this example, statistical data is used as data provider for a dynamically created
+ DataGrid component. The lines import fl.accessibility.DataGridAccImpl; DataGridAccImpl.enableAccessibility();
+ are required to enable accessibility for the Datagrid Component.
+
Open the SWF file in Internet Explorer 6 or higher (using Flash Player 6 or higher),
+ or Firefox 3 or higher (using Flash Player 9 or higher)
+
+
+
Use a tool which is capable of showing an object's accessibility name, such as
+ ACTF aDesigner 1.0 to open the Flash movie.
+
+
+
In the GUI summary panel, inspect the accessibility name for the DataGrid rows
+ and cells to ensure that the heading data is presented in conjunction with the data
+ cell data.
+
+
+
Authors may also test with a screen reader, by reading the Flash content and listening
+ to hear that the heading and data cell data are read when reading the DataGrid.
+
+
+
+
Authors may also verify in the Flash authoring tool that the DataGrid component
+ is used to structure the data and that the DataGrid has been made accessible using
+ the DataGridAccImpl.enableAccessibility method.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check 3, 4, or 5 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH22.html b/wcag21/techniques/flash/FLASH22.html
new file mode 100644
index 0000000..57c2701
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH22.html
@@ -0,0 +1,167 @@
+
+
+
+
+ FLASH22: Adding keyboard-accessible actions to static elements
+
+
+
+
+
+
+
+
Adding keyboard-accessible actions to static elements
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to demonstrate how to provide keyboard
+ access to a Flash MovieClip that is not keyboard accessible by default.
+ This technique ensures that the element is focusable by setting the
+ tabEnabled property, and it ensures that the action can be triggered
+ from the keyboard by providing a keydown handler in addition to a click
+ handler.
+
+
+
+
Examples
+
+
Example 1: MovieClip used as a button
+
In this example, a custom MovieClip is used as a button. To make it
+ keyboard accessible, the MovieClip is placed in the tab order using
+ the tabEnabled. Additionally, redundant event handlers are added so
+ that the custom button responds to both a mouse click and a space bar
+ keypress. Finally, the custom button is provided an accessible name
+ using the MovieClip's AccessibilityProperties object. This makes the
+ button's label perceivable by assistive technology.
+
Using a generic MovieClip is generally not recommended, since
+ the custom button will be perceived as a focusable graphic rather than
+ a button. Instead, a better approach would be to use the standard Flash
+ Button component, or create a new symbol with a type of "button".
+
When a Flash Movie contains generic MovieClip instances that are used
+ as interactive controls, confirm that:
+
+
+
+
+
The MovieClip instance has its tabEnabled property set to true
+
+
+
The MovieClip instance has event handlers for both mouse and keyboard events
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH23.html b/wcag21/techniques/flash/FLASH23.html
new file mode 100644
index 0000000..d8a827b
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH23.html
@@ -0,0 +1,164 @@
+
+
+
+
+ FLASH23: Adding summary information to a DataGrid
+
+
+
+
+
+
+
+
Adding summary information to a DataGrid
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a brief overview of
+ how data has been organized into a DataGrid or a brief explanation
+ of how to navigate the grid.
+
+
As Flash does not provide a summary attribute, this descriptive text
+ will be added to the DataGrid's accessible desription instead. This
+ approach will make the summary information available to people who
+ use screen readers; the information is not displayed visually.
+
+
The summary is useful when the table has a complex structure (for
+ example, when there are several sets of row or column headers, or when
+ there are multiple groups of columns or rows). The summary may also
+ be helpful for simple data tables that contain many columns or rows
+ of data.
+
+
+
+
Examples
+
+
Example 1: Adding a summary to a DataGrid in the Accessibility control panel
+
This is an example of a DataGrid being added to the stage in Flash
+ Professional from the Components panel. The description field is used
+ in the Accessibility control panel in Flash to serve as the summary
+ information for the DataGrid.
+
+
+
+
Create a new Flash file (.fla) or open an existing one to put
+ a DataGrid into.
+
+
+
Open the Flash components panel from the Window menu
+
+
Drag a DataGrid component onto the stage and position as desired.
+
+
Select the DataGrid component and add the summary information
+ to the description field for DataGrid, using the Accessibility control
+ panel.
+
+
+
+
+
+
Example 2: Adding a summary to a DataGrid with ActionScript 3
+
This is a basic AS3 example of a DataGrid component that has summary
+ text added as its accessible description.
+
import fl.accessibility.DataGridAccImpl;
+import fl.controls.DataGrid;
+import fl.controls.Label;
+import fl.data.DataProvider;
+import flash.accessibility.Accessibility;
+import flash.accessibility.AccessibilityProperties;
+import flash.system.Capabilities;
+
+DataGridAccImpl.enableAccessibility();
+
+createGrid();
+
+//set the summary text as accessible description
+var accProps: AccessibilityProperties = new AccessibilityProperties();
+accProps.description = "The first column shows the player's name," +
+ "the second and third column shows the player's gaming statistics." +
+ "the fourth column shows the player's year as FR (Freshman), JR (junior) or SO (Sophomore)." +
+ "The fifth column shows the player's home city and state";
+aDg.accessibilityProperties = accProps;
+if (Capabilities.hasAccessibility)
+Accessibility.updateProperties();
+
+function createGrid() {
+
+ //create and add the components
+ var aDg: DataGrid = new DataGrid();
+ addChild(aDg);
+ aDg.move(50, 50);
+ bldRosterGrid(aDg);
+
+ var aRoster: Array = new Array();
+ aRoster =[ {
+ Name: "Wilma Carter", Bats: "R", Throws: "R", Year: "So", Home: "Redlands, CA"
+ }, {
+ Name: "Sue Pennypacker", Bats: "L", Throws: "R", Year: "Fr", Home: "Athens, GA"
+ }, {
+ Name: "Jill Smithfield", Bats: "R", Throws: "L", Year: "Sr", Home: "Spokane, WA"
+ }, {
+ Name: "Betty Kay", Bats: "R", Throws: "R", Year: "Fr", Home: "Palo Alto, CA"
+ },];
+ aDg.dataProvider = new DataProvider(aRoster);
+ aDg.rowCount = aDg.length;
+}
+
+function bldRosterGrid(dg: DataGrid) {
+ dg.setSize(400, 300);
+ dg.columns =[ "Name", "Bats", "Throws", "Year", "Home"];
+ dg.columns[0].width = 120;
+ dg.columns[1].width = 50;
+ dg.columns[2].width = 50;
+ dg.columns[3].width = 40;
+ dg.columns[4].width = 120;
+};
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH24.html b/wcag21/techniques/flash/FLASH24.html
new file mode 100644
index 0000000..68f9c86
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH24.html
@@ -0,0 +1,169 @@
+
+
+
+
+ FLASH24: Allowing the user to extend the default time limit
+
+
+
+
+
+
+
+
Allowing the user to extend the default time limit
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to allow the user to extend the
+ default time limit by providing a mechanism to extend the time when
+ scripts provide functionality that has default time limits. In order
+ to allow the user to request a longer time limit, the script can provide
+ a form (for example) allowing the user to enter a larger time limit
+ or indicating that more time is needed.
+
+
+
+
Examples
+
+
Example 1: Changing timeout with a dropdown list
+
This is a basic AS2 example where the timeout duration can be changed
+ by the user through a dropdown list. In this example there is a combobox
+ with the instance name sessionLimitDuration.
+
import mx.controls.Alert;
+import mx.accessibility.AlertAccImpl;
+import mx.accessibility.ComboBoxAccImpl;
+
+ComboBoxAccImpl.enableAccessibility();
+AlertAccImpl.enableAccessibility();
+
+var sessionTimeout;
+var sessionNotificationTimeout;
+var timeLimit: Number;
+var sessionAlert: Alert;
+
+adjustTimeoutDuration();
+// reset the timeout when interaction occurs
+testField.addEventListener("change", resetTimeout);
+
+//
+//update limit duration when the combobox value changes
+//
+sessionLimitDuration.addEventListener("change", adjustTimeoutDuration);
+
+function adjustTimeoutDuration(e) {
+ timeLimit = sessionLimitDuration.value * 1000;
+ resetTimeout();
+ timeoutDescription.text = "A session timeout will be simulated after " +
+ sessionLimitDuration.selectedLabel + " without interaction in the form field below."
+}
+
+function resetTimeout() {
+ clearTimeout(sessionTimeout);
+ sessionTimeout = setTimeout(endSession, timeLimit);
+}
+
+function endSession() {
+ sessionAlert.deletePopUp();
+ Alert.show("please log in again",
+ "Your session has expired");
+}
Check that there is a control to adjust the time limit near the
+ top of the page that allows the user to adjust the time to at least
+ ten times longer than the default.
+
+
+
Verify that the default time limit for the page is long enough
+ that a user can easily navigate to the control even if they are 10
+ times slower than most users.
+
+
+
+
+
+
+
Expected Results
+
+
The above is true
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH25.html b/wcag21/techniques/flash/FLASH25.html
new file mode 100644
index 0000000..3007ebd
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH25.html
@@ -0,0 +1,256 @@
+
+
+
+
+ FLASH25: Labeling a form control by setting its accessible name
+
+
+
+
+
+
+
+
Labeling a form control by setting its accessible name
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide an accessible name to
+ the built in form components provided by Flash. Some components, such
+ as radio buttons, checkboxes and buttons, have their own label property.
+ For other components, the developer needs to specify the component's
+ label text as accessible name. This can be either be achieved through
+ the Accessibility panel (for components placed on the stage during
+ authoring) or through scripting (for components that are dynamically
+ created at runtime).
+
+
ActionScript 2
+
In ActionScript 2 the accessible name needs to be set on a component's
+ _accProps property. This property must be an object. If the property
+ has not been set yet, the developer needs to create a custom object
+ and assign it to the _accProps property. The object itself can have
+ several accessibility related properties, one of them being _accProps.name,
+ which specifies the accessible name. When an _accProps property is
+ updated, the developer must call Accessibility.UpdateProperties() for
+ the changes to take effect. Before calling Accessibility.UpdateProperties(),
+ it is recommended to check the System.capabilities.hasAccessibility
+ flag. this will prevent an error on environments that do not support
+ MSAA.
+
+
ActionScript 2 provides the following accessible components:
+
+
+
SimpleButton
+
+
CheckBox
+
+
RadioButton
+
+
Label
+
+
TextInput
+
+
TextArea
+
+
ComboBox
+
+
ListBox
+
+
Window
+
+
Alert
+
+
DataGrid
+
+
+
ActionScript 3
+
In ActionScript 3 the accessible name needs to be set on a component's
+ accessibilityProperties property. This property must be an instance
+ of flash.accessibility.AccessibilityProperties. If the property has
+ not been set yet, the developer needs to create the a new AccessibilityProperties
+ instance and assign it to the accessibilityProperties property. The
+ object itself can have several accessibility related properties, one
+ of them being accessibilityProperties.name which specifies the accessible
+ name. When an accessibilityProperties property is updated, the developer
+ must call flash.accessibility.Accessibility.UpdateProperties() for the
+ changes to take effect. Before calling Accessibility.UpdateProperties(),
+ it is recommended to check the flash.system.capabilities.hasAccessibility
+ flag. this will prevent an error on environments that do not support
+ MSAA.
+
+
ActionScript 3 provides the following accessible components.
+
+
+
Button
+
+
CheckBox
+
+
ComboBox
+
+
List
+
+
RadioButton
+
+
TileList
+
+
+
+
+
Examples
+
+
Example 1: Setting a component's accessible name using the Accessibility panel
+
To add and label a component control, follow these steps:
+
+
+
From the 'Components' panel, drag the component on to the stage,
+ or use scripting to create a new instance.
+
+
+
With the newly created component instance selected, enter its
+ label text in the Accessibility Panel's Name field.
+
+
+
+
+
+
Example 2: Setting the accessible name through ActionScript 2.0
+
The code example below shows how a ListBox component is created and assigned an accessible
+ name.
+
For Flash movies that contain form components, confirm that either:
+
+
+
+
The selected component's label text is specified in the Accessibility
+ Panel's "name" field.
+
+
+
In ActionScript 2.0: Scripting is used to dynamically set the
+ component's _accProps.name property
+
+
+
In ActionScript 3.0: Scripting is used to dynamically set the
+ component's accessibilityProperties.name property
+
+
+
+
+
+
+
Expected Results
+
+
One of the above is true
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH26.html b/wcag21/techniques/flash/FLASH26.html
new file mode 100644
index 0000000..5482601
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH26.html
@@ -0,0 +1,233 @@
+
+
+
+
+ FLASH26: Applying audio descriptions to Flash video
+
+
+
+
+
+
+
+
Applying audio descriptions to Flash video
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Flash CS3 and higher
+
+
ActionScript 3.0 and higher
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a way for people
+ who are blind or otherwise have trouble seeing the video in
+ audio-visual material to be able to access the material. With
+ this technique a description of the video is provided via audio
+ description that will fit into the gaps in the dialogue in
+ the audio-visual material.
+
+
+
+
Examples
+
+
Example 1: Playing descriptions when cue points are reached
+
In this example, the FLVPlayback component is used to create
+ a video player. A custom class called "AudioDescriptions" is
+ added to manage the playback of extended audio descriptions.
+ This class provides event listeners to listen for cue points
+ in the media that have been identified by the audio description
+ provider. When these cuepoints are reached, an mp3 file containing
+ the corresponding description will start playing. The recorded
+ descriptions have been timed to fit with in the gaps in the
+ movie's dialog.
+
+
By default, audio descriptions will be enabled. A button (which
+ must itself be accessible to meet other success criteria) is
+ provided below the video player that allows the user to turn
+ audio descriptions on or off.
+
package {
+ import fl.video. *;
+ import flash.events. *;
+ import flash.media.Sound;
+ import flash.media.SoundChannel;
+ import flash.net.URLRequest;
+ import flash.display.Sprite;
+
+ public class AudioDescriptions extends Sprite {
+ private var channel: SoundChannel = new SoundChannel;
+ private var myPlayer: FLVPlayback;
+ private var _enabled: Boolean = true;
+ private var _toggleBtn: Button;
+ private var snd: Sound = new Sound();
+ public function AudioDescriptions() {
+ // point myPlayer to the FLVPlayback component instance on the stage,
+ // which should be loaded with a valid video source.
+ myPlayer = my_FLVPlybk;
+ // add cue points. When any of these are reached, the
+ // MetadataEvent.CUE_POINT event will fire
+ myPlayer.addASCuePoint(8.35, "ASpt1");
+ myPlayer.addASCuePoint(23.23, "ASpt2");
+
+ enable();
+
+ enable_AD_btn.addEventListener(MouseEvent.CLICK, handleBtnClick);
+ }
+
+ private function handleBtnClick(e) {
+ _enabled = ! _enabled;
+ if (! _enabled) {
+ disable();
+ enable_AD_btn.label = "Enable Audio Descriptions";
+ } else {
+ enable();
+ enable_AD_btn.label = "Disable Audio Descriptions";
+ }
+ }
+
+ public function enable() {
+ // set up an event handler which will be called each time a cue point is reached
+ myPlayer.addEventListener(MetadataEvent.CUE_POINT, cp_listener);
+ }
+
+ public function disable() {
+ // remove the event handler called each time a cue point is reached, so
+ // that audio description is disabled.
+ myPlayer.removeEventListener(MetadataEvent.CUE_POINT, cp_listener);
+ }
+
+ private function cp_listener(eventObject: MetadataEvent): void {
+ snd = new Sound();
+ //recreate sound object as it can only load one mp3 file
+ //check to see which cue point was reached
+ switch (eventObject.info.name) {
+ case "ASpt1":
+ snd.load(new URLRequest("sphere.mp3"));
+ //create a new Sound object, and load the appropriate mp3
+ channel = snd.play();
+ // play the audio description, and assign it to the SoundChannel object
+ break;
+ case "ASpt2":
+ snd.load(new URLRequest("transfrm.mp3"));
+ channel = snd.play();
+ break;
+ }
+ }
+ }
+}
Example 2: Providing an additional audio track for descriptions
+
Audio description can also be provided via an additional audio
+ track that is the same length and plays simultaneously as the
+ primary media, but that only includes sound for the segments
+ when audio description needs to be played and silence at other
+ times. A Flash author can provide a toggle to turn this additional
+ audio track on or off, based on the listener's preference.
+ When the additional track is enabled, there are two parallel
+ audio tracks, one being the primary audio, and the second being
+ the one containing only audio description. It is still necessary
+ to ensure that the audio description and primary audio do not
+ overlap in ways that make comprehension difficult. This method
+ will achieve the same result as the method used in Example
+ 1, but may be chosen because of the type of audio description
+ files that are provided to the Flash author.
+
When Flash content contains video with an audio soundtrack,
+ confirm that:
+
+
+
+
+
Audio descriptions have been made available using separate
+ sound files.
+
+
+
A button is provided that allows users to enable or disable
+ the audio descriptions
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH27.html b/wcag21/techniques/flash/FLASH27.html
new file mode 100644
index 0000000..d9197f9
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH27.html
@@ -0,0 +1,184 @@
+
+
+
+
+ FLASH27: Providing button labels that describe the purpose of a button
+
+
+
+
+
+
+
+
Providing button labels that describe the purpose of a button
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to describe the purpose
+ of a button by providing descriptive text as the button's accessible
+ name. The description lets a user distinguish this button from
+ other buttons in the Flash movie and helps the user determine
+ whether to activate the button. An empty string is not sufficient
+ as a button's accessible name.
+
+
For buttons with text labels, the label text will be used
+ as a buttons accessible name. If a button is image based and
+ does not have a text label, the button's accessible name will
+ have to be set separately using the Accessibility panel or
+ through scripting.
+
+
+
+
Examples
+
+
Example 1: Using the label property to describe the button's purpose
import fl.controls.Button;
+import fl.accessibility.ButtonAccImpl;
+
+ButtonAccImpl.enableAccessibility();
+
+var myButton:Button = new Button();
+myButton.label = "View Items in Cart";
+
+
+
Example 2: Using scripting to set the accessible name for an image button using Actionscript
+ 3.0
+
+
In this example, the button's label property is deliberately set to an empty string. To be perceivable to assistive technology,
+ the button's accessibilityProperties.name property is set.
+
For each button in the Flash movie that uses this technique:
+
+
+
+
Check that the button's label text correctly describes
+ the button's purpose
+
+
+
If a button does not have a text label, confirm that descriptive
+ text has been added as the button's accessible name.
+
+
+
If a button contains both label text and an accessible
+ name, confirm that the combination of the two makes sense
+ as a description for the button's purpose.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1, #2, and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH28.html b/wcag21/techniques/flash/FLASH28.html
new file mode 100644
index 0000000..2035991
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH28.html
@@ -0,0 +1,183 @@
+
+
+
+
+ FLASH28: Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash
+
+
+
+
+
+
+
+
Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
ASCII characters, emoticons, and leetspeek are sometimes used
+ and present accessibility challenges since the meaning is conveyed
+ through the visual appearance of groupings of individual characters.
+
+
In Flash, such groupings of characters can be made accessible
+ by wrapping them in a MovieClip, and providing an accessible
+ name. It is crucial that the forceSimple property for the
+ MovieClip is set to true also. This will hide the actual ASCII
+ characters from assistive technology.
+
+
+
+
Examples
+
+
Example 1: Providing a text alternative for ASCII art in the Accessibility control
+ panel
+
+
This example contains words written in ASCII art using leetspeek
+ (the text says "WCAG 2 rulez"). To make this text
+ accessible, the following steps are followed:
+
+
+
+
Place the ASCII characters in a MovieClip instance
+
+
+
+
Select the MovieClip instance containing the text, and
+ make the following changes in the Accessibility panel:
+
+
+
+
+
Add a meaningful text alternative for the ASCII art,
+ without leetspeak (such as "WCAG 2 RULEZ").
+
+
+
Uncheck the "Make child objects accessible" checkbox,
+ so that the ASCII characters will not be read by screen
+ readers
+
+
+
+
+
+
+
+
These steps are ilustrated in the screenshot below:
+
+
+
+
Example 2: Providing a text alternative for ASCII art using ActionScript
+
This example is the same as example 1, except using ActionScript
+ instead of the Accessibility control panel in the Flash Professional
+ authoring tool.
+
+
+
+
Place the ASCII characters in a MovieClip instance
+
+
Provide an instance name for the MovieClip instance (e.g. myASCII)
+
+
Set the accessible name for the MovieClip and set the
+ forceSimple property to true to hide the text inside the
+ MovieClip.
+
+
+
// 'myASCII' is a MovieClip instance placed on the movie's main timeline
+myASCII.accessibilityProperties = new AccessibilityProperties();
+myASCII.accessibilityProperties.name = "WCAG 2 Rulez";
+myASCII.accessibilityProperties.forceSimple = true;
+
Use a tool which is capable of showing an object's name
+ to open the Flash movie.
+
+
+
Locate the ASCII grouping, leet speak, or emoticon and
+ verify in the tool that the accessibility name represents
+ the same information.
+
+
+
Authors may also test with a screen reader, by reading
+ the Flash content and listening to hear that the equivalent
+ text is read when tabbing to the non-text object (if it is
+ tabbable) or hearing the alternative text read when reading
+ the content line-by-line.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#3 or #4 above is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH29.html b/wcag21/techniques/flash/FLASH29.html
new file mode 100644
index 0000000..db8efd1
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH29.html
@@ -0,0 +1,239 @@
+
+
+
+
+ FLASH29: Setting the label property for form components
+
+
+
+
+
+
+
+
Setting the label property for form components
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to explicitly associate a form
+ component with its label text by setting the component's label property.
+ Setting this property will visually place a label next to the component,
+ and exposes the label text to assistive technology.
+
For other components, the label text has to placed adjacent to the
+ form component manually. For these components, the label text can be
+ associated with the form component using one of these approaches:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Examples
+
In order for these form controls to be accessible to assistive
+ technology, the following lines of code will have to be added once
+ to the movie's script:
+
When the Button, CheckBox or RadioButton components are used:
+
+
+
+
confirm that labels describing the purpose of the button have
+ been provided through the component's label property.
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH3.html b/wcag21/techniques/flash/FLASH3.html
new file mode 100644
index 0000000..d20bd23
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH3.html
@@ -0,0 +1,175 @@
+
+
+
+
+ FLASH3: Marking objects in Flash so that they can be ignored by AT
+
+
+
+
+
+
+
+
Marking objects in Flash so that they can be ignored by AT
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The purpose of this technique is to show how images can be marked so that they can
+ be ignored by Assistive Technology.
+
+
The Flash Player supports the ability for authors to control which graphics appear
+ to assistive technologies using the silent property of the accessibility object, as indicated in the examples below.
+
+
+
+
Examples
+
+
Example 1: Hiding a graphic in the Flash Professional authoring tool
+
The Flash Professional authoring tool's Accessibility panel lets authors provide
+ accessibility information to assistive technology and set accessibility options for
+ individual Flash objects or entire Flash applications.
+
+
+
+
To apply changes to accessibility properties for a graphic, it must be saved as a
+ symbol in the movie's library. Note: Flash does not support text alternatives for graphic symbols. Instead, the graphic
+ must be converted to or stored in a movie clip or button symbol.
+
+
+
Bring up the Accessibility panel by selecting "Window > Other Panels > Accessibility"
+ in the application menu, or through the shortcut ALT + F11.
+
+
+
Select the graphic object
+
+
If the 'Make object accessible' checkbox in the Accessibility control panel is checked,
+ uncheck this option to remove the graphic from the accessiblity information conveyed
+ to assistive technologies.
+
+
+
+
+
+
Example 2: Applying textual alternatives programmatically in ActionScript 2.0
+
To manage an object's text equivalents programmatically using ActionScript, the _accProps property must be used. This references an object containing accessibility related
+ properties set for the object. The code example below shows a simple example of how
+ the _accProps property is used to remove an object from the accessibility information for the
+ movie using ActionScript.
+
// 'decorative_mc' is an instance placed on the movie's main timeline
+_root.decorative_mc._accProps = new Object();
+_root.decorative_mc._accProps.silent = true;
+
+
+
Resources
+
Resources are for information purposes only, no endorsement implied.
Open the SWF file in Internet Explorer 6 or higher (using Flash Player 6 or higher),
+ or Firefox 3 or higher (using Flash Player 9 or higher)
+
+
+
Use a tool which is capable of showing an object's accessibility information, such
+ as ACTF aDesigner 1.0 to open the Flash movie.
+
+
+
In the GUI summary panel, loop over each object which is contained by the Flash
+ movie and ensure the object that was designed to be hidden does not appear in the
+ tool's display.
+
+
+
Authors may also test with a screen reader, by reading the Flash content and listening
+ to hear that object is not mentioned when the page is read.
+
+
+
Non-text objects that are coded to be hidden from assistive technologies are not
+ available to assistive technology.
+
+
+
+
+
+
+
Expected Results
+
+
Check #6 is true.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH30.html b/wcag21/techniques/flash/FLASH30.html
new file mode 100644
index 0000000..9669731
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH30.html
@@ -0,0 +1,172 @@
+
+
+
+
+ FLASH30: Specifying accessible names for image buttons
+
+
+
+
+
+
+
+
Specifying accessible names for image buttons
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
For image based Button components the accessible name needs to be
+ set to provide a functional label. This label indicates the button's
+ function, but does not attempt to describe the image. The label is
+ especially important if there are multiple buttons on the page that
+ each lead to different results.
+
+
The accessible name for a button may need to be updated if the button
+ changes during the use of the Flash movie.
+
+
+
+
Examples
+
+
Example 1: Accessible name for a simple image button
+
In this example, an icon based button is given an accessible name
+ through scripting. When the button is clicked a web page is opened.
+
//provide text equivalent for image button
+this.check_btn.accessibilityProperties = new AccessibilityProperties();
+this.check_btn.accessibilityProperties.name = "Check page validation";
+
+//set up event listener and function to navigate to URL
+
+this.check_btn.addEventListener(MouseEvent.CLICK, onClickHandler);
+
+function onClickHandler(e: MouseEvent): void {
+ var btn = e.target;
+ var url: String = "http://validator.w3.org";
+ var request: URLRequest = new URLRequest(url);
+ navigateToURL(request, '_blank');
+}
When a Flash Movie contains image based buttons, confirm that:
+
+
+
+
An accessible name is provided for the button that describes the
+ button's action
+
+
+
If the button's action changes (for example when it is clicked)
+ the accessible name changes correspondingly
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH31.html b/wcag21/techniques/flash/FLASH31.html
new file mode 100644
index 0000000..a1470b0
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH31.html
@@ -0,0 +1,231 @@
+
+
+
+
+ FLASH31: Specifying caption text for a DataGrid
+
+
+
+
+
+
+
+
Specifying caption text for a DataGrid
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to programmatically associate captions
+ for DataGrids where captions are provided in the presentation. Normally,
+ the caption for a table is a table identifier and acts like a title
+ or heading for the table.
+
+
Flash does not have a caption element for the DataGrid component,
+ but the same effect can be achieved through the following approach:
+
+
+
+
Place a label component or textfield above the DataGrid, containing
+ the grid's caption text.
+
+
+
Duplicate the caption text and add it as the grid's accessible
+ name. This can either be achieved by setting a value to the grid's "name" field
+ in the Accessibility panel or by setting the grid's AccessibilityProperties.name
+ property.
+
+
+
+
+
+
Examples
+
+
Example 1: Associating a label with a DataGrid
+
This is an example of a DataGrid being added to the stage in Flash
+ Professional from the Components panel. A label element is also added
+ from the Components panel to contain the caption text and the caption
+ text is used in the Accessibility control panel in Flash to serve as
+ the accessibility name for the DataGrid.
+
+
+
+
Create a new Flash file (.fla) or open an existing one to put
+ a DataGrid into.
+
+
+
Open the Flash components panel from the Window menu
+
+
Drag a DataGrid component onto the stage and position as desired.
+
+
Drag a label component onto the stage and position as desired.
+
+
Add text to the label component.
+
+
Select the DataGrid component and add the same text as is used
+ in the label component to the name field for DataGrid, using the
+ Accessibility control panel.
+
+
+
+
+
+
Example 2: Associating a caption with a DataGrid using ActiveScript 3
+
This is a basic AS3 example of a DataGrid generated through scripting.
+ Additionally a label element is created, containing the caption text,
+ and the caption text is added to the grid as an accessible name.
+
import fl.accessibility.DataGridAccImpl;
+import fl.controls.DataGrid;
+import fl.controls.Label;
+import fl.data.DataProvider;
+import flash.accessibility.Accessibility;
+import flash.accessibility.AccessibilityProperties;
+import flash.system.Capabilities;
+
+// enable accessibility for the DataGrid
+DataGridAccImpl.enableAccessibility();
+
+createGrid();
+
+// set the data grid caption text
+var gridCaptionText: String = "Game Results";
+gridCaption.text = gridCaptionText;
+//add the caption text as the DataGrid's accessible name
+var accProps: AccessibilityProperties = new AccessibilityProperties();
+accProps.name = gridCaptionText;
+aDg.accessibilityProperties = accProps;
+if (Capabilities.hasAccessibility)
+Accessibility.updateProperties();
+
+function createGrid() {
+
+ //create and add the components
+ var aDg: DataGrid = new DataGrid();
+ var gridCaption: Label = new Label();
+ addChild(aDg);
+ addChild(gridCaption);
+ aDg.move(50, 50);
+ gridCaption.move(50, 20);
+
+ var captionFormat: TextFormat = new TextFormat();
+ captionFormat.size = 24;
+ gridCaption.setStyle("textFormat", captionFormat);
+ gridCaption.width = 300;
+ gridCaption.height = 100;
+ bldRosterGrid(aDg);
+ //prepare the data
+ var aRoster: Array = new Array();
+ aRoster =[
+ {Name: "Wilma Carter", Bats: "R", Throws: "R", Year: "So", Home: "Redlands, CA"},
+ {Name: "Sylvia Munson", Bats: "R", Throws: "R", Year: "Jr", Home: "Pasadena, CA"},
+ {Name: "Carla Gomez", Bats: "R", Throws: "L", Year: "Sr", Home: "Corona, CA"},
+ {Name: "Betty Kay", Bats: "R", Throws: "R", Year: "Fr", Home: "Palo Alto, CA"},
+ ];
+ aDg.dataProvider = new DataProvider(aRoster);
+ aDg.rowCount = aDg.length;
+};
+
+function bldRosterGrid(dg: DataGrid) {
+ dg.setSize(400, 300);
+ dg.columns =[ "Name", "Bats", "Throws", "Year", "Home"];
+ dg.columns[0].width = 120;
+ dg.columns[1].width = 50;
+ dg.columns[2].width = 50;
+ dg.columns[3].width = 40;
+ dg.columns[4].width = 120;
+};
The accessible name can also be applied to the DataGrid using
+ the Accessibility panel in the Flash authoring tool.
+
+
+
In the above example, the text used for the DataGrid caption will
+ be read twice, once as the text label that is offered for sighted
+ users, and again as the accessible name for the DataGrid. Authors
+ can avoid duplicate voicing by setting the silent property for the
+ label text to true.
+
Check whether the Flash movie contains a DataGrid component.
+
+
Confirm that each DataGrid's caption text has been added to the component as an accessible
+ name.
+
+
+
+
+
+
+
Expected Results
+
+
Step 2 is true.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH32.html b/wcag21/techniques/flash/FLASH32.html
new file mode 100644
index 0000000..a667ece
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH32.html
@@ -0,0 +1,204 @@
+
+
+
+
+ FLASH32: Using auto labeling to associate text labels with form controls
+
+
+
+
+
+
+
+
Using auto labeling to associate text labels with form controls
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
Except for the CheckBox and RadioButton component, the built in Flash
+ components are not automatically provided an associated label. For
+ these components, label text has to be placed adjacent to their control
+ manually, using the Label component. If the 'auto-label' feature is
+ enabled in the Accessibility panel, then the Flash Player will automatically
+ associate the label text for the TextInput and TextArea components.
+ This means that for these components, it is not necessary to duplicate
+ the label text for the control using the Accessibility panel. The auto
+ label feature is enabled by default.
+
+
Additionally, the auto label feature will enable the Flash Player
+ to automatically add text contained by Button symbols as the symbol's
+ accessible name. This will only work if the Button symbol only consists
+ of one layer, containing the text label.
+
+
+
Note
+
+
+
Since auto-labeling associates labels without human intervention
+ the accuracy of the association should be verified. For more predictable
+ results authors are encouraged to explicitly add labels to all controls.
+
+
+
+
+
To auto labeling, perform the following steps:
+
+
+
Ensure that the textual descriptions for each form control within
+ the flash application are placed adjacent to the control itself. Text
+ eligible to be used for auto-labeling must not be set to be hidden
+ from assistive technology.
+
+
+
Select the movie stage, and open the Accessibility panel.
+
+
Ensure that the 'Auto Label' option is checked. This will automatically
+ associate labels with their TextInput and TextArea controls, and
+ add text inside custom button symbols as their accessible name.
+
+
+
If the auto label behavior is inappropriate to your Flash content,
+ uncheck the 'Auto label' option, and ensure that each control receives
+ a meaningful 'name' value in the Accessibility panel.
+
+
+
To disable auto labeling for a particular object but not the whole
+ movie, convert the text to the 'dynamic text' type using the 'Property
+ inspector'. Then select it, and uncheck its 'Make object accessible'
+ option in the Accessibility panel.
+
+
+
+
+
Note
+
+
+
As an alternative to using the Accessibility panel, the auto
+ label feature can also be turned off by setting the AccessibilityProperties.noAutoLabel
+ to true for the stage object.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Using the "Auto Label" option in the Accessibility panel
+
This example shows two TextInput components, a TextArea component
+ and a custom button symbol instance. For the TextInput components,
+ a separate label element has been placed to the left of the control.
+ For the TextArea component, the label has been placed above the control.
+ For the custom button, the label text is placed inside the button symbol.
+ Because the "Auto Label" option is enabled in the Accessibility
+ panel, all these controls will be provided an accessible name based
+ on their label.
+
If a Flash form contains TextInput or TextArea components, or custom
+ button symbols with text labels, confirm that:
+
+
+
+
+
The Auto Label option is enabled in the movie's Accessibility
+ panel
+
+
+
Use a screen reader or MSAA checker to ensure that the label text
+ is indeed exposed as the control's accessible name
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH33.html b/wcag21/techniques/flash/FLASH33.html
new file mode 100644
index 0000000..b17f757
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH33.html
@@ -0,0 +1,165 @@
+
+
+
+
+ FLASH33: Using relative values for Flash object dimensions
+
+
+
+
+
+
+
+
Using relative values for Flash object dimensions
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to specify the width and/or height
+ of an embedded Flash object using relative units such as em values.
+ The size of the Flash object is allowed to expand to fill the size
+ of its container (a parent element) by setting the movie width and
+ height to 100%. The container's width and height is set with relative
+ units. This will allow user agents that support text resizing to resize
+ the Flash object in line with changes in text size settings. When the
+ Flash object's dimensions are adjusted its contents will be scaled,
+ making it easier to read for low vision users.
+
+
+
Note
+
+
+
This technique is not necessary to support users who use zoom
+ functionality in their browsers.
+
+
+
+
+
+
+
Examples
+
+
Example 1: Scaling text while keeping a minimum size
+
In this example, a Flash object is loaded into an HTML document using SWFObject's
+ dynamic publishing method. The Flash object's container element
+ is given a class name of "flashPlaceHolder". This class
+ name is then targeted using CSS to set its width and height using
+ relative em values. When the user increases or decreases the browser's
+ text size, the Flash object will scale accordingly. To ensure that
+ the object does not become too small when text size is decreased,
+ the min-width and min-height properties are set to the default dimensions.
+
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
+ <title>Flash Resize example</title>
+ <script src="swfobject/swfobject.js" type="text/javascript"/>
+ <script type="text/javascript">
+ swfobject.embedSWF("scale_movie_dimensions_on_text_resize_as3.swf",
+ "flashPlaceHolder", "100%", "100%", "8")
+</script>
+
+ <style type="text/css">
+ #flashPlaceHolder {
+ width: 20em;
+ height: 15em;
+ min-width: 320px;
+ min-height: 240px;
+ }
+</style>
+ </head>
+ <body id="header">
+ <h1>Flash Resize Demonstration</h1>
+ <p>When the browser's text size is changed, the Flash movie will be
+ resized accordingly.</p>
+ <p id="flashPlaceHolder">Flash needs to be installed for this
+ example to work</p>
+ </body>
+</html>
+
Open a web page containing an embedded flash object
+
+
View the HTML to confirm that the width and height dimensions
+ for the object containing the Flash object are specified using relative
+ units such as em or percent (%).
+
+
+
+
+
+
+
Expected Results
+
+
+
+
Check #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH34.html b/wcag21/techniques/flash/FLASH34.html
new file mode 100644
index 0000000..6e5e07d
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH34.html
@@ -0,0 +1,221 @@
+
+
+
+
+ FLASH34: Turning off sounds that play automatically when an assistive technology is detected
+
+
+
+
+
+
+
+
Turning off sounds that play automatically when an assistive technology is detected
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The intent of this technique is to prevent sounds from playing when
+ the Flash movie loads. This is useful for those who utilize assistive
+ technologies (such as screen readers, screen magnifiers, switch mechanisms,
+ etc.) and those who may not (such as those with cognitive, learning
+ and language disabilities). By default, the sound will be played automatically.
+ When a screen reader such as JAWS is detected however, the sound will
+ have to be started manually.
+
+
To perform screen reader detection, Flash provides the flash.accessibility.Accessibility.active
+ property. If this property is set to true, it means that the Flash
+ player has detected running assistive technology. Based on this flag,
+ the Flash developer can choose to run different functionality.
+
+
+
Note
+
+
+
The Flash Player requires some time to detect active assistive
+ technology and set the Accessibility.active property. To get accurate
+ results, do not check for this property immediately on the first frame
+ of the movie. Instead, perform the check 5 frames in or based on a
+ timed event.
+
+
+
Not every screen reader will be detected using this mechanism.
+ In general, the property will be set to true when any MSAA client
+ is running.
+
+
+
Other assistive technology tools, including screen magnifiers,
+ or tools not used as assistive technologies may also utilize MSAA in
+ ways that result in Accessibility.active being set to true.
+
+
+
+
+
+
+
Examples
+
+
Example 1: A SoundHandler class
+
A class called SoundHandler is created which automatically starts
+ playing an MP3 file only when Accessibility.active is set to false.
+ Note that this example also checks the flash.system.Capabilities.hasAccessibility
+ property. This property does not check whether a screen reader is running,
+ but instead indicates whether the Flash Player is running in an environment
+ that supports MSAA (which basically means the Windows operating system).
+
package wcagSamples {
+ import flash.accessibility.Accessibility;
+ import flash.display.Sprite;
+ import flash.net.URLRequest;
+ import flash.media.Sound;
+ import flash.media.SoundChannel;
+ import flash.system.Capabilities;
+ import fl.controls.Button;
+ import fl.accessibility.ButtonAccImpl;
+ import fl.controls.Label;
+ import flash.events.MouseEvent;
+
+ public class SoundHandler extends Sprite {
+ private var snd: Sound = new Sound();
+ private var button: Button = new Button();
+ private var req: URLRequest = new URLRequest(
+ "http://av.adobe.com/podcast/csbu_dev_podcast_epi_2.mp3");
+ private var channel: SoundChannel = new SoundChannel();
+ private var statusLbl: Label = new Label();
+ public function SoundHandler() {
+ snd.load(req);
+ ButtonAccImpl.enableAccessibility();
+ button.x = 10;
+ button.y = 10;
+ statusLbl.autoSize = "left";
+ statusLbl.x = 10;
+ statusLbl.y = 40;
+ addChild(statusLbl);
+ button.addEventListener(MouseEvent.CLICK, clickHandler);
+ this.addChild(button);
+ if (! Capabilities.hasAccessibility || ! Accessibility.active) {
+ channel = snd.play();
+ button.label = "Stop Sound";
+ statusLbl.text = "No Assistive technology detected. \
+ Sound will play automatically";
+ } else {
+ button.label = "Start Sound";
+ statusLbl.text = "Assistive technology detected. \
+ Sound will not play automatically";
+ }
+ }
+ private function clickHandler(e: MouseEvent): void {
+ if (button.label == "Stop Sound") {
+ button.label = "Start Sound";
+ channel.stop();
+ } else {
+ channel = snd.play();
+ button.label = "Stop Sound";
+ }
+ }
+ }
+}
Open a page containing a Flash movie that starts playing audio
+ automatically when a screen reader is not running
+
+
+
Confirm that the audio is stopped.
+
+
+
+
+
+
Expected Results
+
+
+
+
#3 is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH35.html b/wcag21/techniques/flash/FLASH35.html
new file mode 100644
index 0000000..ead7201
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH35.html
@@ -0,0 +1,183 @@
+
+
+
+
+ FLASH35: Using script to scroll Flash content, and providing a mechanism to pause it
+
+
+
+
+
+
+
+
Using script to scroll Flash content, and providing a mechanism to pause it
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a way for users to stop
+ scrolling content when the scrolling is created by a script. Scrolling
+ content can be difficult or impossible to read by users with low vision
+ or with cognitive disabilities. The movement can also be distracting
+ for some people making it difficult for them to concentrate on other
+ parts of the Web page.
+
+
+
+
Examples
+
+
Example 1: A toggle button to pause and resume scrolling
+
In this example, text scrolls from left to right. A toggle button
+ is provided that allows the user to pause and resume the scrolling
+ behavior. Additionally, a checkbox is provided which can be used to
+ slow down the scrolling speed.
+
+
+
Note
+
+
+
Users may prefer a greater variety of scrolling speed options
+ than are offered in this example. Developers might choose to provide
+ several speed choices with a slider or drop down list control in order
+ to accomplish this.
+
Confirm that a button is provided that allows users to pause and resume the scrolling
+ behavior
+
+
+
Confirm that pressing the button stops the scrolling
+
+
Confirm that pressing the button again restarts the scrolling
+
+
+
+
+
+
Expected Results
+
+
+
+
Checks #1, #2, and #3 are true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH36.html b/wcag21/techniques/flash/FLASH36.html
new file mode 100644
index 0000000..8151e1c
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH36.html
@@ -0,0 +1,111 @@
+
+
+
+
+ FLASH36: Using scripts to control blinking and stop it in five seconds or less
+
+
+
+
+
+
+
+
Using scripts to control blinking and stop it in five seconds or less
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to control blinking with script
+ so it can be set to stop in less than five seconds by the script. The
+ ActionScript setTimeout() method is used to stop the MovieClip's blinking
+ behavior in less than 5 seconds.
+
+
+
+
Examples
+
+
Example 1: Stopping blinking after a timeout
+
In this example a MovieClip (blinkingTextMC) uses its timeline to
+ generate a blinking effect. Before 5 seconds has passed, the MovieClip's
+ gotoAndStop() method is called, which stops the blinking effect.
+
Start a timer for 5 seconds at the start of the blink effect.
+
+
When the timer expires, determine if the blinking has stopped.
+
+
+
+
+
+
Expected Results
+
+
+
+
For each instance of blinking content, #2 is true.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH4.html b/wcag21/techniques/flash/FLASH4.html
new file mode 100644
index 0000000..865f636
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH4.html
@@ -0,0 +1,134 @@
+
+
+
+
+ FLASH4: Providing submit buttons in Flash
+
+
+
+
+
+
+
+
Providing submit buttons in Flash
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to use submit buttons to allow users to take actions
+ that cause changes of context rather than allowing changes in context to occur when
+ the value or state of a non-submit button control is modified. The intended use of
+ a submit button in this technique is to generate an HTTP request that submits data
+ entered in a form or to perform an action that triggers a change in context, so it
+ is an appropriate control to use to initiate this change.
+
+
+
+
Examples
+
+
Example 1: ActionScript 3 combobox with submit button
+
This is a basic ActionScript 3 example of a combobox component with a submit button
+ to redirect the user to a different resource.
+
Example 2: ActionScript 2 combobox with submit button
+
This is a basic ActionScript 2 example of a combobox component with a submit button
+ to redirect the user to a different resource - the same example as in example 1 except
+ in ActionScript 2:
+
Find all interactive control instances (that are not submit buttons) in the flash
+ movie that can initiate a change of context, e.g. a combobox, radio button or checkbox.
+
+
+
+
For each instance, confirm that the event handler(s) responsible for the change
+ of context are not associated with the controls themselves, but with a separate button
+ instead.
+
+
+
+
+
+
+
Expected Results
+
+
#2 is true
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH5.html b/wcag21/techniques/flash/FLASH5.html
new file mode 100644
index 0000000..b77d4b9
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH5.html
@@ -0,0 +1,189 @@
+
+
+
+
+ FLASH5: Combining adjacent image and text buttons for the same resource
+
+
+
+
+
+
+
+
Combining adjacent image and text buttons for the same resource
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to avoid unnecessary duplication that occurs when
+ adjacent text and iconic versions of a button are contained in a Flash movie.
+
+
Many kinds of buttons have both a text and iconic button adjacent to each other.
+ Often the text and the icon button are rendered in separate buttons, in part to create
+ a slight visual separation from each other. Although the sighted user can see this
+ slight visual separation, a blind or low vision user may not be able to recognize
+ the separation, and be confused by the redundant buttons. To avoid this, some authors
+ omit specifying the accessible name for the image, but this would fail Success Criterion
+ 1.1.1 because the text alternative would not serve the same purpose as the graphical
+ button. The preferred method to address this is to put the text and image together
+ in one button symbol instance, and provide a single accessible name for the button
+ to eliminate duplication of text.
+
+
+
+
Examples
+
The following examples are for a situation where a button instance comprised of both
+ an image and text is on the stage. The combined button in this example uses the instance
+ name 'flashLink1'.
+
+
To create the combined button in Flash Professional:
+
+
+
Add a graphic object and text to the stage
+
+
Select both objects
+
+
Select 'New Symbol' from the Insert menu or hit Ctrl+F8 to create a new button object
+
+
+
+
Click on the button object on the stage and enter an instance name in the Properties
+ panel.
+
+
+
Continue under example 1, 2, or 3 below.
+
+
+
+
+
Example 1: Using the Accessibility panel to specify the accessible name
+
The Accessibility panel is used to specify the accessible name (which in this case
+ is the same as the visual text).
+
+
+
+
+
Example 2: Using ActionScript to specify the accessible name
+
ActionScript 3 can be used instead of the Accessibility control panel to define the
+ accessibility name for the combined button, as follows:
+
// 'flashLink1' is an instance placed on the movie's main timeline
+flashLink1.accessibilityProperties = new AccessibilityProperties();
+flashLink1.accessibilityProperties.name = "Learn more about Flash";
ActionScript 2 can be used instead of the Accessibility control panel to define the
+ accessibility name for the combined button, as follows
+
// 'flashLink1' is an instance placed on the movie's main timeline
+flashLink1._accProps = new Object();
+flashLink1._accProps.name = "Learn more about Flash";
Open the SWF file in Internet Explorer 6 or higher (using Flash Player 6 or higher),
+ or Firefox 3 or higher (using Flash Player 9 or higher)
+
+
+
Use a tool which is capable of showing an object's name text alternative, such as
+ ACTF aDesigner 1.0 to open the Flash movie.
+
+
+
If you are using ACTF aDesigner 1.0, use the GUI Summary panel to check each image
+ button in the Flash movie and ensure that there is no separate, redundant text control
+ adjacent to the image that performs the same action.
+
+
+
+
+
+
+
Expected Results
+
+
#4 is true.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH6.html b/wcag21/techniques/flash/FLASH6.html
new file mode 100644
index 0000000..5d9a674
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH6.html
@@ -0,0 +1,177 @@
+
+
+
+
+ FLASH6: Creating accessible hotspots using invisible buttons
+
+
+
+
+
+
+
+
Creating accessible hotspots using invisible buttons
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide text alternatives that serve the same
+ purpose as the clickable hotspots of an image. Each hotspot serves as a clickable
+ region for a part of the image which can trigger an action (such as opening a web
+ page corresponding to the hotspot). The hotspots are implemented as invisible Flash
+ buttons, which are each given an accessible name that describes the hotspot's target.
+
+
+
+
+
Examples
+
+
Example 1: Graphic with accessible clickable regions
+
+
+
Add the original graphic that needs to have clickable hotspots to the stage.
+
+
+
+
For each hotspot, do the following:
+
+
+
+
Create a new button symbol by choosing "New Symbol" from the Flash Professional
+ 'Insert' menu or by using the Ctrl + F8 shortcut.
+
+
+
Inside the button symbol, create a shape that matches the clickable surface.
+
+
Place the newly created button on top of the original graphic.
+
+
Open the button's properties panel, and choose "Alpha" from the "Style" dropdown
+ list under "Color Effect". Change the value of the "Alpha" slider that appears to
+ zero so that the button becomes invisible.
+
+
+
Using the Accessibility panel, specify a value for the "tabindex" field to give the
+ button a logical position in the tab order.
+
+
+
Using the Accessibility panel, specify an accessible name that describes the purpose
+ of the hotspot.
+
Find all images with hotspots. For each hotspot, confirm that:
+
+
+
+
The hotspot is implemented as an invisible button
+
+
The hotspot is provided with an accessible name, either through the Accessibility
+ panel or through ActionScript
+
+
+
+
+
+
+
Expected Results
+
+
+
+
#1 and #2 are true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH7.html b/wcag21/techniques/flash/FLASH7.html
new file mode 100644
index 0000000..3bec548
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH7.html
@@ -0,0 +1,122 @@
+
+
+
+
+ FLASH7: Using scripting to change control labels
+
+
+
+
+
+
+
+
Using scripting to change control labels
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The purpose of this technique is to allow users to choose to have additional information
+ added to the label of a button or other control so that it can be understood out
+ of context.
+
+
Some users prefer to have control labels that are self-contained, where there is
+ no need to explore the context of the control. Other users find including the context
+ information in each button to be repetitive and to reduce their ability to use a
+ site. Among users of assistive technology, the feedback to the working group on
+ which is preferable has been divided. This technique allows users to pick the approach
+ that works best for them.
+
+
A control is provided near the beginning of the page that will expand the labels
+ for controls on the page so that no additional context is needed to understand the
+ purpose of those controls. It must always be possible to understand purpose of the
+ control directly from its label.
+
+
This technique expands the control labels only for the current page view. It is also
+ possible, and in some cases would be advisable, to save this preference in a cookie
+ or server-side user profile, so that users would only have to make the selection
+ once per site.
+
+
+
+
Examples
+
+
Example 1: Using ActionScript to add contextual information directly to the label
+ of a button
+
+
This example uses ActionScript to add contextual information directly to the label
+ of a button. When the "Expand Button Labels" button is toggled, each button on the
+ page has its label property modified.
+
import fl.accessibility.ButtonAccImpl;
+ButtonAccImpl.enableAccessibility();
+btn1.addEventListener(MouseEvent.CLICK, clickHandler);
+
+function clickHandler(e) {
+ btn2.label = btn1.selected? "PDF version of 2010 brochure": "PDF";
+ btn2.width = btn1.selected? 200: 100;
+ btn3.label = btn1.selected? "Text version of 2010 brochure": "Text";
+ btn3.width = btn1.selected? 200: 100;
+ btn4.label = btn1.selected? "Word version of 2010 brochure": "Word";
+ btn4.width = btn1.selected? 200: 100;
+}
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH8.html b/wcag21/techniques/flash/FLASH8.html
new file mode 100644
index 0000000..39c97c4
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH8.html
@@ -0,0 +1,348 @@
+
+
+
+
+ FLASH8: Adding a group name to the accessible name of a form control
+
+
+
+
+
+
+
+
Adding a group name to the accessible name of a form control
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
+
+
Adobe Flash Professional version MX and higher
+
+
Adobe Flex
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide a semantic grouping for related form
+ controls. This allows users to understand the relationship of the controls and interact
+ with the form more quickly and effectively.
+
+
In Flash, when related form controls are grouped, this grouping can be indicated
+ by adding the group's name to each form control's accessible name.
+
+
Grouping controls is most important for related radio buttons and checkboxes. A
+ set of radio buttons or checkboxes is related when they all submit values for a
+ single named field. They work in the same way as selection lists, allowing the user
+ to choose from a set of options, except selection lists are single controls while
+ radio buttons and checkboxes are multiple controls. Because they are multiple controls,
+ it is particularly important that they be grouped semantically so they can be
+ more easily treated as a single control. Often, user agents will present the value
+ of the legend before the label of each control, to remind users that they are part
+ of the same group.
+
+
It can also be useful to group other sets of controls that are not as tightly related
+ as sets of radio buttons and checkboxes. For instance, several fields that collect
+ a user's address might be grouped together with a legend of "Address".
+
+
+
+
Examples
+
+
Example 1: Adding a group name to the accessible name of radio buttons
+
This example shows how the group name for radio buttons in a group can be made accessible
+ by adding it to each button's accessible name:
+
+
+
+
Add radio button components to the stage:
+
+
Enter each button's label using its label property
+
+
+
Add the visual group label to the left or above the buttons added in step 1
+
+
Select each radio button. In the Accessibility panel, add the group name to the
+ "Name" field;
+
+
+
+
Flash will concatenate the group name with each button's individual name, such as
+ "gender male".
+
+
This approach is illustrated in the screenshot below:
+
+
+
Note
+
+
+
To make the radio buttons in this example accessible, the following two lines need
+ to be added to the movie's script: import fl.accessibility.RadioButtonAccImpl;
+ RadioButtonAccImpl.enableAccessibility();
+
+
Example 2: Programmatically adding a group name with the accessible name of radio
+ buttons
+
+
The code example below shows a basic proof of concept of a class that automatically
+ places a set of form controls inside a fieldset like rectangle, including a legend.
+ For each added control an AccessibilityProperties object is created, and its name property is set to a combination of the legend text and the actual form control
+ label.
+
+package wcagSamples {
+ import flash.display. *;
+ import flash.text. *;
+ import fl.controls. *
+ import flash.accessibility. *;
+ import fl.accessibility. *;
+
+
+ /**
+ * Basic example that demonstrates how to simulate a fieldset, as provided
+ * in HTML. The FieldSet class takes a group of controls and places them
+ * inside a fieldset rectangle with the legend text at the top. For each form
+ * control, the legend text is prepended to the control's accessible name
+ *
+ * Note: This is only a proof of concept, not a fully functional class
+ *
+ * @langversion 3.0
+ * @playerversion Flash 10
+ *
+ */
+ public class FieldSet extends Sprite {
+ private var legend: String;
+ private var bBox: Shape;
+ private var currentY: int = 20;
+
+ public static var LABEL_OFFSET_X: int = 20;
+ public static var CONTROL_OFFSET_X: int = 110;
+
+ /**
+ * CONSTRUCTOR
+ * Legend specifies the FieldSet's legend text, items is an array
+ * describing the controls to be added to the FieldSet
+ */
+
+ public function FieldSet(legend: String, items: Array) {
+ // enable accessibility for components used in this example
+ RadioButtonAccImpl.enableAccessibility();
+ CheckBoxAccImpl.enableAccessibility();
+
+ //create FieldSet rectangle and legend
+ legend = legend;
+ bBox = new Shape();
+ bBox.graphics.lineStyle(1);
+ bBox.graphics.drawRect(10, 10, 300, 250);
+ bBox.graphics.beginFill(0x0000FF, 1);
+ addChild(bBox);
+
+ var fieldSetLegend: TextField = new TextField();
+ fieldSetLegend.text = legend;
+ fieldSetLegend.x = 20;
+ fieldSetLegend.y = 3;
+ fieldSetLegend.background = true;
+ fieldSetLegend.backgroundColor = 0xFFFFFF;
+ fieldSetLegend.border = true;
+ fieldSetLegend.borderColor = 0x000000;
+ fieldSetLegend.autoSize = TextFieldAutoSize.LEFT;
+ addChild(fieldSetLegend);
+
+ // add controls
+ for (var i = 0; i < items.length; i++) {
+ processItem(items[i]);
+ }
+ }
+
+ /**
+ * Adds the control to the Fieldset and sets its accessible name. A
+ * control is represented as an array, containing the following values:
+ * [0] : A string describing the component type
+ * (can be "TextInput", TextArea", Checkbox" or "RadioGroup").
+ * [1] : The label used to identify the control
+ * [2] : If [0] is "RadioGroup", then [2] needs to contain an array of the
+ * labels for each individual radio button. if [0] is "CheckBox", then
+ * [1] can either be empty or a question (e.g. "Do you smoke?"), and
+ * [2] the CheckBox label (e.g. "Yes").
+ *
+ */
+ function processItem(item: Array) {
+ if (item.length < 2)
+ return;
+ currentY += 30;
+ var newControl;
+ //create visual label
+ var lbl: Label;
+ lbl = new Label();
+ lbl.text = item[1] + ": ";
+ lbl.x = FieldSet.LABEL_OFFSET_X;
+ lbl.y = currentY;
+ lbl.width = FieldSet.CONTROL_OFFSET_X;
+ lbl.autoSize = TextFieldAutoSize.RIGHT;
+ lbl.wordWrap = true;
+ addChild(lbl);
+
+ switch (item[0]) {
+ case "TextInput":
+ case "TextArea":
+ newControl = item[0] == "TextInput"? new TextInput(): new TextArea();
+ newControl.x = FieldSet.CONTROL_OFFSET_X;
+ //concatenate accessible name, combining legend and label
+ setAccName(newControl, legend + " " + item[1]);
+ break;
+ case "CheckBox":
+ newControl = new CheckBox();
+ newControl.label = item[2];
+ newControl.x = FieldSet.CONTROL_OFFSET_X;
+ setAccName(newControl, legend + " " + item[1] + " " + item[2]);
+ break;
+ case "RadioGroup":
+ if (item[2] && item[2].length > 0) {
+ var radioGroup: RadioButtonGroup = new RadioButtonGroup(item[0]);
+ var newBtn: RadioButton;;
+ for (var i = 0; i < item[2].length; i++) {
+ newBtn = new RadioButton();
+ // concatenate the legend, the group label, and the button label
+ setAccName(newBtn, legend + " " + item[1] + " " + item[2][i]);
+ newBtn.label = item[2][i];
+ newBtn.group = radioGroup;
+ newBtn.x = FieldSet.CONTROL_OFFSET_X;
+ newBtn.y = currentY;
+ addChild(newBtn);
+ if (i < item[2].length - 1)
+ currentY += 30;
+ }
+ }
+ break;
+ }
+
+ if (newControl) {
+ newControl.y = currentY;
+ addChild(newControl);
+ }
+ }
+
+ /**
+ * Creates an AccessibilityProperties object for an object and sets its name property
+ */
+ public function setAccName(obj, accName) {
+ var accProps: AccessibilityProperties = new AccessibilityProperties();
+ accProps.name = accName;
+ obj.accessibilityProperties = accProps;
+ }
+ }
+}
This example class can be initialized as follows:
var myFieldSet = new FieldSet("Personal Details", // the legend
+ [["TextInput", "Name"], // text field
+ ["RadioGroup", "Gender", ["Male", "Female"]], // radio button group
+ ["CheckBox", "Do you smoke", "yes"], // checkbox
+ ["TextArea", "Comments"], // text area
+]);
+addChild(myFieldSet);
+
When a Flash Movie contains grouped form controls, confirm that either :
+
+
+
+
The group's name is included in the Accessibility panel's "name" field for each
+ control.
+
+
+
Each control has an AccessibilityProperties.name property, which contains both the group's name and the control's label text
+
+
+
+
+
+
+
Expected Results
+
+
+
+
One of the above is true
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/wcag21/techniques/flash/FLASH9.html b/wcag21/techniques/flash/FLASH9.html
new file mode 100644
index 0000000..025ad72
--- /dev/null
+++ b/wcag21/techniques/flash/FLASH9.html
@@ -0,0 +1,200 @@
+
+
+
+
+ FLASH9: Applying captions to prerecorded synchronized media
+
+
+
+
+
+
+
+
Applying captions to prerecorded synchronized media
+
+
Important Information about Techniques
+
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how
+ they relate to the normative WCAG 2.1 success criteria. The Applicability section
+ explains the scope of the technique, and the presence of techniques for a specific
+ technology does not imply that the technology can be used in all situations to create
+ content that meets WCAG 2.1.
+
+
+
+
+
Applicability
+
Adobe Flash-based Content
+
+
+
Adobe Flash CS3 and later
+
+
+
+
Note
+
Adobe has plans to stop updating and distributing the Flash Player at the end of 2020,
+ and encourages authors interested in creating accessible web content to use HTML.
+
The objective of this technique is to provide an option for people who have hearing
+ impairments or otherwise have trouble hearing the sound and dialogue in synchronized
+ media to be able to choose to view captions as an alternative to audio information.
+ With this technique all of the dialogue and important sounds are provided as text
+ in a fashion that allows the text to be hidden unless the user requests it. As a
+ result they are visible only when needed. This can be achieved using the FLVPlayback
+ and FLVPlaybackCaptioning components. Note: when using FLVPlayback skins the closed
+ caption button is accessible by default, but if implementing custom skins authors
+ need to test to verify that the button is accessible.
+
+
+
+
Examples
+
+
Example 1: Adding a timed text caption file to Flash
+
+
+
Use an external tool (such as Magpie or a simple text editor) to create a timed
+ Text captions xml file. Stop and play the video content, and for each relevant part
+ of audio information (including speech, important background noises and event sounds)
+ include the start and end time code as well as the textual alternative. Tools like
+ Magpie have advanced features to make this process easier, whereas a text editor
+ requires you to read the timecodes from your media player and include them in the
+ XML as illustrated in the sample captions document below
+
+
+
In Flash, create a new instance of the FLVPlayback component on your stage, and
+ set its contentPath value to your flv video file using the 'Component inspector'
+ or 'Parameters' panel.
+
+
+
Set the 'Skin' parameter to use a skin which includes the CC (closed captions)
+ button.
+
+
+
From the components list also create an instance of the FLVPlayback captioning
+ component. In the 'Component inspector' panel set its 'Source' parameter to the
+ name of your timed text xml file. The captions will automatically placed at the
+ bottom of the player's frame.
+
+
+
<?xml version="1.0" encoding="UTF-8"?>
+<tt xml:lang="en" xmlns="https://www.w3.org/2006/04/ttaf1"
+ xmlns:tts="https://www.w3.org/2006/04/ttaf1#styling">
+ <head>
+ <styling>
+ <style id="defaultSpeaker" tts:backgroundColor="black"
+ tts:color="white" tts:fontFamily="SansSerif" tts:fontSize="12"
+ tts:fontStyle="normal" tts:fontWeight="normal"
+ tts:textAlign="left" tts:textDecoration="none"/>
+ <style id="defaultCaption" tts:backgroundColor="black"
+ tts:color="white" tts:fontFamily="Arial" tts:fontSize="12"
+ tts:fontStyle="normal" tts:fontWeight="normal"
+ tts:textAlign="center" tts:textDecoration="none"/>
+ </styling>
+ </head>
+ <body id="thebody" style="defaultCaption">
+ <div xml:lang="en">
+ <p begin="0:00:00.20" end="0:00:02.20">If there were nothing in
+ our universe</p>
+ <p begin="0:00:02.20" end="0:00:05.65">the fabric of space-time
+ would be flat.</p>
+ <p begin="0:00:05.65" end="0:00:08.88">But add a mass, and
+ dimples form within it.</p>
+ <p begin="0:00:16.61" end="0:00:19.84">Smaller objects that
+ approach that large mass</p>
+ <p begin="0:00:19.84" end="0:00:23.41">will follow the curve in
+ space-time around it.</p>
+ <p begin="0:00:32.64" end="0:00:36.84">Our nearest star, the
+ sun, has formed such a dimple</p>
+ <p begin="0:00:36.84" end="0:00:38.00">and our tiny planet
+ Earth</p>
+ <p begin="0:00:38.00" end="0:00:41.50">goes along for the ride
+ in the curve of its dimple</p>
+ <p begin="0:00:41.50" end="0:00:43.80">staying in orbit around
+ the sun.</p>
+ <p begin="0:00:45.67" end="0:01:55.00"/>
+ </div>
+ </body>
+</tt>
+