Agencies
Services
IITAA Techniques
IITAA Techniques provide easy-to-understand instructions on how to meet IITAA Standards. IITAA Techniques are modeled after the World Wide Web Consortium (W3C)'s Techniques for WCAG, but are written and organized in the concise and easy-to-follow format of the original IITAA 1.0 Implementation Guidelines.
As with the W3C's Techniques, IITAA Techniques are not the only way to meet the standards. If an agency opts to use different techniques, it is the agency's responsibility to demonstrate that those techniques correctly and completely satisfy all applicable standards. Also like the W3C's Techniques, IITAA Techniques will be periodically updated to cover additional technologies and changes in technologies and tools.
IITAA Techniques for Web Sites, Applications & Documents
The following techniques are applicable to web sites, applications, and documents that are typically displayed in a web browser (or email client) using Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and/or Javascript. They apply whether the HTML code is written directly or generated by a server-side language such as .NET, Java, PHP, etc.
- Code & Content
- IL-WEB-1.1 Use well-formed HTML
- IL-WEB-1.2 Use the lang attribute to identify the language of text
- IL-WEB-1.3 Use the title element to provide a meaningful page title
- IL-WEB-1.4 Use appropriate elements to convey the meaning and role of content
- IL-WEB-1.5 Use landmark regions to identify sections of the page
- IL-WEB-1.6 Use headings to begin sections and use them in the correct order
- IL-WEB-1.7 Use lists to identify series of related items
- Styles
- IL-WEB-2.1 Use text to display text, unless formatting that cannot be achieved with styles is required.
- IL-WEB-2.2 Ensure that text can be resized to at least 200%.
- IL-WEB-2.3 Use contrasting foreground and background colors.
- IL-WEB-2.4 Do not convey information with color alone.
- IL-WEB-2.5 Do not refer to elements on the page by their color, size, shape or location alone.
- IL-WEB-2.6 Ensure that the keyboard focus indicator is visible.
- Images
- Links
- Tables
- Forms
- IL-WEB-6.1 Provide labels or titles for all form fields.
- IL-WEB-6.2 Provide legends for groups of form fields.
- IL-WEB-6.3 If an input error is detected, identify the error and the item that is in error in text.
- IL-WEB-6.4 If an input error is detected, provide suggestions for correction, if known.
- IL-WEB-6.5 For critical data, ensure that input is reversible, checked, or confirmed.
- Scripts
- IL-WEB-7.1 Ensure that significant interactions can be performed with both keyboard and mouse.
- IL-WEB-7.2 Ensure that scripted elements are usable with assistive technologies.
- IL-WEB-7.3 Do not change focus unexpectedly.
- IL-WEB-7.4 Do not change content unexpectedly.
- IL-WEB-7.5 Notify users of time limits and provide a means to extend time if possible.
- Multimedia
- IL-WEB-8.1 Do not convey information with sound alone.
- IL-WEB-8.2 Do not automatically play audio.
- IL-WEB-8.3 Provide a text equivalent for audio containing speech.
- IL-WEB-8.4 Provide synchronized captions for multimedia containing speech.
- IL-WEB-8.5 Provide audio descriptions for multimedia containing essential visual information.
- IL-WEB-8.6 Provide a means of pausing any moving, blinking, scrolling, or auto-updating information.
- IL-WEB-8.7 Do not include content that flashes faster than 3 times per second.
- Frames
- Order
- Sites
Code & Content
IL-WEB-1.1 Use well-formed HTML.
What: HTML is considered "well-formed" when it follows the essential rules established by the World Wide Web Consortium (W3C). These essential rules include using the correct tags, matching opening and closing tags, nesting elements appropriately, and ensuring that attributes are unique.
Why: Web browsers and assistive technologies interpret HTML based on the rules set by the W3C. If there are errors in the HTML code, assistive technology may not be able to interpret or interact with a web page correctly.
How: Indicate the version of HTML you are using by starting each page with a standard document type declaration, such as <!DOCTYPE html>. Use the W3C HTML Validation Service (http://validator.w3.org) to check your code. There should be no errors of the following types:
- element not allowed here
- end tag for element which is not open
- end tag for element which is not finished
- end tag omitted
- duplicate attribute
- ID already defined
Ref: WCAG 4.1.1
IL-WEB-1.2 Use the lang attribute to identify the language of text.
What: The HTML lang attribute specifies the language of text in a web page. It can be used on any HTML element.
Why: Screen readers look at the lang attribute to determine how to pronounce words correctly.
How: Use the lang attribute on the <html> element to identify the primary language of each page, for example, <html lang="en"> for English. Use the lang attribute on other elements to identify words or phrases in other languages, for example, <span lang="es">se habla español</span> for a Spanish phrase within an English document.
Ref: WCAG 3.1.1, 3.1.2
IL-WEB-1.3 Use the title element to provide a meaningful page title.
What: The title of a web page is displayed in the title bar at the top of the web browser window. The title is specified using the <title> element in the <head> section.
Why: Screen readers announce the title whenever a new page is loaded. Screen reader users read the title to confirm that they have reached the intended page and to get a sense of what will be on the page.
How: Add a <title> element in the <head> section that indicates the topic of the page. Include the name of the web site at the beginning or end of the title. Keep titles concise, usually 60 or fewer characters in length.
Ref: WCAG 2.4.2
IL-WEB-1.4 Use appropriate elements to convey the meaning and role of content.
What: HTML is designed to identify the meaning and role of elements within a page. For example, <p> identifies a paragraph and <li> identifies a list item.
Why: Screen readers identify elements to help make reading more efficient. For example, most screen readers can skip from heading to heading, announce the number of items in a list, and identify the current row and column in a table.
How: Use appropriate elements to identify headings, paragraphs, lists, images, links, tables, form controls, etc. Do not use elements based on how they look, for example, do not use heading just to make text bold. Use CSS to customize the appearance of elements. Refer to the HTML Recommendation (https://www.w3.org/TR/html/dom.html#elements) for the meaning of each element.
Ref: WCAG 1.3.1
IL-WEB-1.5 Use landmarks to identify the major sections of each page.
What: Landmarks identify the major regions of a page, such as the header, the navigation menu(s), the main content, and the footer. In HTML, landmarks are set using HTML5 sectioning elements, such as <header>, <nav>, <main>, and <footer>, or role attributes, such as banner, navigation, main, and contentinfo.
Why: Screen readers identify landmarks and allow users to easily skip to or past the different regions.
How: Use the following HTML5 sectioning elements or <div> elements with role attributes to identify the major regions that exist on each page:
- <header> or <div role="banner"> - the site or application header, usually containing the logo, site search, etc.
- <nav> or <div role="navigation"> - the site and/or page navigation menu(s). If there are more than one, use aria-labelledby or aria-label attributes to identify each (e.g., "Site", "Page", etc.).
- <main> or <div role="main"> - the main content area of the page.
- <footer> or <div role="contentinfo"> - footer information such as copyright, contact and privacy policy links, etc.
All content on a page should be contained in one of the above landmark sections. (There are also roles for complementary, form, and search landmarks, which can be used if needed.)
Ref: WCAG 1.3.1, 2.4.1
IL-WEB-1.6 Use headings to begin sections and use them in the correct order.
What: Headings are used to introduce sections and sub-sections within a page. HTML includes six levels of headings, <h1>, <h2>, <h3>, <h4>, <h5>, and <h6>, representing the different levels in an "outline" of the page. Web browsers normally display headings in large, bold font.
Why: Screen readers identify headings so that users can easily skim through content and quickly skip to sections of interest.
How: Start the main content area of each page with an <h1> heading that indicates the topic of the page as identified in the page title. If the content is long enough to be divided into sections, begin each section with a heading of the appropriate level:
- <h2> for sections,
- <h3> for sub-sections,
- <h4> for sub-sub sections, and so on.
Remember that the headling level indicates its depth in an outline of the page. Do not skip levels or choose levels just based on text size. Use CSS to customize the appearance of headings. If desired, headings (and other elements) can be visually hidden but readable by screen readers by using a style such as:
- .screen-reader-only { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; }
Ref: WCAG 1.3.1, 2.4.6
IL-WEB-1.7 Use lists to identify series of related items, including navigation menus.
What: Lists group and identify series of related items. HTML includes "ordered" (<ol>) and "unordered" (<ul>) lists, each of which can contain list items (<li>) and "nested" lists. Navigation menus are lists of links to various locations on a page or pages in a site.
Why: Screen readers identify the number of items in a list and enable users to easily skip between or past items.
How: Use <ol> when the sequence of items is important; use <ul> when the order does not matter. Use CSS to customize the appearance of numbers and bullets, but do not use bullets on ordered lists or numbers or letters on unordered lists.
Ref: WCAG 1.3.1
Styles
IL-WEB-2.1 Use text to display text, unless formatting that cannot be achieved with styles is required.
What: Text can be displayed using actual text characters or as images that look like text. Images of text are sometimes used to achieve a specific style, size, or effect, but this can usually be done using CSS instead.
Why: Users with limited vision may rely on the ability to enlarge or use enhanced color combinations for text. Most operating systems and web browsers enable users to change the size and color of actual text, but not of text in images.
How: Whenever possible, use actual text instead of images of text, with CSS to achieve the desired sizes, colors, or effects. Only use images of text when a specific appearance is required and should not be changed by the user, such as for a logo.
Ref: WCAG 1.4.5
IL-WEB-2.2 Ensure that text can be resized to at least 200%.
What: Most web browsers allow users to increase the size of text using a "zoom" or "text size" setting.
Why: Users with limited vision often rely on the ability to enlarge text.
How: Design your page layout so that text (including text in form controls) can be enlarged to at least 200% using browser zoom or text size settings without the text being obscured or overlapped by other elements. This can be achieved by setting sizes for elements using relative units such as % or em, and being careful when using absolute positioning, setting the overflow property to hidden, or supressing scrollbars.
Ref: WCAG 1.4.4
IL-WEB-2.3 Use contrasting foreground and background colors.
What: Web authors can set specific colors to be used for text and backgrounds.
Why: Users with limited vision or color-blindness may have difficulty reading text that is similar in color to its background.
How: For text, use dark colors on light backgrounds, or vice versa. Small and normal sized text must have a contrast ratio of at least 4.5:1. Large text, 18 pt (150%) or 14 pt (120%) and bold or larger, must have a contrast ratio of at least 3:1. See WCAG Success Criteria 1.4.3 Related Resources (https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum#resources) for a list of tools that can be used to measure contrast ratios. Contrast requirements do not apply to text that is invisible, purely decorative, within a disabled form field, or part of a logo.
Ref: WCAG 1.4.3
IL-WEB-2.4 Do not convey information with color alone.
What: Color is often used to indicate special functions or status. For example, required form fields might be indicated with red labels.
Why: Users with blindness, limited vision, or color-blindness may miss information presented with color.
How: Whenever color is used as an indicator, also use a non-color-based indicator. For example, required form fields could have red labels that also include text or an image (with appropriate alternate text) indicating that they are required.
Ref: WCAG 1.4.1
IL-WEB-2.5 Do not refer to elements on the page by their color, size, shape or location alone.
What: A web page may include instructions that refer to elements on the page by how they look, for example: "To submit the form, click the green button at the bottom."
Why: People using screen readers or custom color combinations may not perceive elements' color, size, shape, or location.
How: Whenever elements are on the page are referred to by their appearance, also identify them in a way that does not depend on their visual appearance, for example: "To submit the form, click the green Submit button after the form" (where "Submit" is the text label of the button).
Ref: WCAG 1.3.3
IL-WEB-2.6 Ensure that the keyboard focus indicator is visible.
What: Most web browsers use an indicator, such as a dotted rectangle, to show which element has focus. Some combinations of background and border styles can hide the focus indicator.
Why: Keyboard users rely on the focus indicator to tell which element they currently working with.
How: Ensure that the focus indicator remains visible for all focusable elements, including links, form fields, buttons, and custom controls. Do not use styles that make non-focused elements look the same as focused elements.
Ref: WCAG 2.4.7
Images
IL-WEB-3.1 Provide appropriate "alternate text" for all images.
What: Web pages often include images. Alternate text is used to convey the meaning of images for users who cannot see them. The HTML image (<img>) element includes an alternate text (alt) attribute specifically for this purpose.
Why: Individuals who are blind cannot see images; screen reading software reads alternate text instead.
How: ALL images must have appropriate alternate text. Alternate text should convey what an image communicates, not describe what it looks like. Specifically:
- For images that contain words - use alternate text that includes the same words. Do not add unnecessary words such as "image of," "picture of,", "logo of," etc.
- For image links - use alternate text that identifies the link's destination or function. Do not include the words "link to."
- For images that are invisible, purely decorative, do not convey meaning, or are completely redundant with text that is on screen - use alt="" (empty string) to indicate that the image can be ignored by a screen reader.
- For CAPTCHA images, use alt text to indicate that the image is being used for CAPTCHA and provide an alternative test in a non-visual medium (e.g., an audio file).
For <img> elements, put the alternate text in the alt attribute. For background images, provide the text on the page in a manner and place that a screen reader can read it when the user encounters the image. Avoid using text characters to simulate images, such as using "->" (dash greater than) to simulate an arrow, since there is not a reliable way to provide alternate text.
Ref: WCAG 1.1.1
IL-WEB-3.2 Provide alternate text for each area in client-side image maps.
What: Image maps are images divided into multiple areas, with each area acting as a link.
Why: Individuals who are blind cannot see images; screen reading software reads alternate text instead.
How: Use alternate text that indicates the function or destination of the link for each area of a client-side image map. The image itself should have alternate text that indicates the overall function of the image map. Avoid using server-side image maps, since they do not have a way to provide alternate text for clickable areas.
Ref: WCAG 1.1.1
IL-WEB-3.3 Provide full descriptions for complex images.
What: Complex images, such as charts, graphs, and diagrams, may convey more information than can be expressed as alternate text.
Why: A full description allows a user who cannot see or understand a complex image another way to access the information it provides.
How: Present a full description of a meaningful image either on the page on which the image appears or through a link immediately preceding or following the image. Use alternate text to provide a concise name for the image. For example, the alternate text of a graph should state its title and the full description should summarize its trends and/or present a table of its data. Avoid using the longdesc attribute to provide a link to a full description, since it is only available to screen reader users.
Ref: WCAG 1.1.1
Links
IL-WEB-4.1 Ensure that links are understandable.
What: A link is understandable when it clearly indicates its destination or function without requiring additional information.
Why: Screen reader users often "tab" through links (skip from link to link by pressing the Tab key) in order to skim a page. Most screen readers also offer a "links list" feature to provide quick and easy access to links. Links that are not understandable, such as "click here" or "more," make these techniques much less efficient.
How: Use link text that is clear and unambiguous. Link text should usually match the title of the page to which the link points. Ensure that links that point to the same URL use the same link text, and that links that point to different URLs use different link text. If title attributes are used, repeat the text of the link as the beginning of the title, followed by the additional information.
If desired, portions of links can be visually hidden but readable by screen readers by using a style such as:
- .screen-reader-only { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; }
Ref: WCAG 2.4.4
IL-WEB-4.2 Provide a means of skipping past repetitive navigation links.
What: Navigation links are the lists of links to the sections or pages of a site. The same navigation links are often repeated on every page.
Why: Because navigation links are typically placed at the beginning of pages, screen reader users must read through all the navigation links before reaching the main area of the page. Individuals who use a keyboard instead of a mouse similarly must tab through all the navigation links before reaching the main area of the page. Providing a means of skipping these links can significantly improve efficiency and usability for screen reader and keyboard users.
How: Provide a link at the beginning of navigation lists that points to a target at the beginning of the main content area of the page. This link must be visible to screen reader and keyboard users, but can be hidden from other users, for example:
<style type="text/css">
a.skipnav { position: absolute; left: -10000px; }
a.skipnav:focus, a.skipnav:active { position: static; left: 0; }
< /style>
<a class="skipnav" href="#content" >Skip to Main Content</a>
<a id="content"></a> Main content....
Ref: WCAG 2.4.1
Tables
IL-WEB-5.1 Identify a header cell for each column and row in simple data tables.
What: In HTML, the table element is used to display data. "Simple" tables have a uniform number of columns and rows. Table header cells (<th>) are used to provide a label for each row and column.
Why: A screen reader can use table headers to provide row and column information while a user explores the data cells within a table.
How: Use <th> elements with scope="col" (for column headers) or scope="row" (for row headers) to identify column and row header cells. The cell that contains the most uniquely identifying information for the column or row should be the header; usually, this should be the first cell of each column and row. Do not include blank or unnecessary columns or rows to control the appearance of the table; use CSS instead.
Ref: WCAG 1.3.1
IL-WEB-5.2 Identify relationships in complex data tables using id and headers attributes.
What: Tables become complex when they have "spanned" columns or rows, multiple layers of headers, or are divided into multiple sections. In complex tables, identifying row and column header cells is not enough to fully label each data cell. The id and headers attributes can be used to associate data cells with multiple row and column headers in complex data tables.
Why: Screen readers can use the information provided with id and headers attributes to interpret relationships in complex tables.
How: Whenever possible, simplify complex tables by re-arranging or dividing them into separate tables. If a table cannot be simplified, use a unique id attribute on each header cell, for example: <th id="header1">, and a headers attributes on each data cell to list the id attributes of header cells that it relates to, for example: <td headers="header1 header2 header3">. Do not include unnecessary columns, rows, colspans, or rowspans just for to control the appearance of the table. See W3C's "Tables in HTML Documents" (http://www.w3.org/TR/html401/struct/tables.html#h-11.4.1) for more details on how to markup complex tables.
Ref: WCAG 1.3.1
IL-WEB-5.3 Do not use data table markup in layout tables.
What: Prior to the adoption of CSS, HTML table elements were often used to lay out pages in multiple columns and rows. While CSS has made this technique unnecessary, it is sometimes still used. If used, layout tables should not include any data table markup, such as <caption> or <th> elements, or scope, headers, or summary attributes.
Why: Screen readers use data table markup to provide extra information and functionality to users, which can be confusing if the table is not actually presenting data.
How: Avoid using tables for layout; use CSS instead. If tables are used for layout, do not use <caption> or <th> elements, or scope, headers, or summary attributes. Use role="presentation" on the table tag to make it clear that the table is being used for layout.
Ref: WCAG 1.3.1
Forms
IL-WEB-6.1 Provide labels or titles for all form fields.
What: HTML forms include "fields" such as text boxes (<input type="text">), check boxes (<input type="checkbox">), radio buttons (<input type="radio">), and drop-down lists (<select>). Each field is typically identified by a text label positioned above, before, or below the field. In HTML, labels are identified using the <label> element. The aria-label or aria-labelledby attributes can also be used to identify labels.
Why: Screen readers cannot always determine which label belongs to which field based on positioning alone. Specifically identifying the label makes this association clear.
How: Use a <label> element whenever possible to identify each form field's label. Set the <label> element's for attribute to match the corresponding field's id, e.g.:
<label for="fieldId">Label Text:</label>
<input id="fieldId" name="fieldName" />
For form fields that cannot be associated with a <label> element, use an aria-label, aria-labelledby, or title attribute instead. Because screen readers typically recognize only one of aria-label, aria-labelledby, label, or title (usually in that order of precedence), use only one method and ensure that it includes the entire label text.
For buttons (<input type="submit|reset|button">), use the value attribute to provide a label; for image buttons (<input type="image">), use the alt attribute for the label. In cases where those methods cannot be used, use aria-label or aria-labelledby instead.
Ref: WCAG 1.3.1, 2.4.6, 3.3.2
IL-WEB-6.2 Provide legends for groups of form fields.
What: In some cases, several form fields may need to be grouped together. For example, a set of radio buttons may offer different answers to a single question.
Why: Screen readers need to be able to read the group name or question in addition to each field's individual label.
How: If possible, group related fields within a <fieldset> element and provide the group name or question in the fieldset's <legend>. If a fieldset cannot be used, apply an aria-label, aria-labelledby, or title attribute to each field in the group and include both the group name and the individual label text. Because screen readers typically recognize only one of aria-label, aria-labelledby, label, or title, use only one method.
Ref: WCAG 1.3.1, 2.4.6, 3.3.2
IL-WEB-6.3 If an input error is detected, identify the error and the item that is in error in text.
What: In web forms, there may be certain fields that must be completed or that require data in a certain format. If a user fails to meet these requirements, the form may present an error message.
Why: Screen readers need to be able to be able to read error messages to the user.
How: Ensure that validation scripts or code present error messages as text. Identify which fields had errors by including their labels in the message. Present the message text in a way and location that a screen readers will find it, such as in an alert box and/or immediately following the <h1> heading for the main section of the page.
Ref: WCAG 3.3.1
IL-WEB-6.4 If an input error is detected, provide suggestions for correction, if known.
What: In web forms, fields may require data in a certain format, for example, a phone number may require ten digits.
Why: All users, and especially those with cognitive disabilities, benefit from a clear explanation of what is required.
How: Ensure that error messages include a clear explanation of what is expected, including examples where possible, for example, "Phone Number must have ten digits, for example 123-456-7890."
Ref: WCAG 3.3.3
IL-WEB-6.5 For critical data, ensure that input is reversible, checked, or confirmed.
What: Some form submissions can have significant consequences, such as making a purchase that can't be refunded or deleting a record that can't be recovered.
Why: Some users with disabilities, including those using complex assistive technologies, may be at greater risk of making unintended entries.
How: Ensure that code that completes a critical action, such as making a purchase or deleting a record, provides a way for the user to check and confirm the action before it is completed or provides a way to reverse the action after it is completed.
Ref: WCAG 3.3.4
Scripts
IL-WEB-7.1 Ensure that significant interactions can be performed with both keyboard and mouse.
What: Scripts can trigger changes when the user performs specific actions using the keyboard or mouse. For example, a paragraph of text could be revealed when the user hovers the mouse over an image.
Why: Some users may be able to use a keyboard but not a mouse. For example, someone with a slight tremor in their hands may not be able to point the mouse at a specific spot, and someone who cannot see the mouse pointer would not be able to tell where the mouse is pointing. These types of users may rely on using the keyboard instead.
How: Whenever using a mouse-only event (e.g., onmouseover, onmouseout) to trigger a significant script action, use the corresponding keyboard event (e.g., onfocus, onblur) to trigger the same action. Ensure that scripts are attached to elements that can receive keyboard focus, such as links, form fields, and elements with a tabindex attribute. Also, make sure that keyboard events do not unintentionally trigger script actions. For example, when a keyboard user arrows through the options in a drop-down list (<select>), the onchange event may be fired once for each option; if a script attached to this event reloads the page (or causes some other significant change), it may be impossible for a keyboard user to operate the control.
Ref: WCAG 2.1.1
IL-WEB-7.2 Ensure that scripted functions are usable with assistive technologies.
What: Scripts can be used for a wide array of functions, from showing a simple alert message to creating a completely custom, interactive application.
Why: Assistive technologies may interact with scripts in unexpected ways. For example, some assistive technologies may not be able to trigger some script events, and other assistive technologies may not recognize changes to content made using scripts. However, assistive technology users need to be able to access the same essential content and functionality whether scripts are fully, partially, or not supported.
How: Whenever scripts are used, it is the responsibility of the developer to thoroughly test using assistive technologies to ensure that all information and functionality is accessible. Testing should confirm that content is usable with system large fonts and high contrast display settings, that interface elements are focusable and operable using the keyboard, that tab and reading order are appropriate, and that all content can be identified and operated with leading assistive technology tools. If there is any doubt, err on the safe side by ensuring that the essential elements of the page do not rely on scripts.
Scripting features that are purely decorative and do not present any significant information or functionality do not need to be made accessible.
Ref: WCAG 1.3.1, 4.1.2
IL-WEB-7.3 Do not change focus unexpectedly.
What: Scripting can be used to move focus from one element to another, load a new page, or open a new window.
Why: Users may be disoriented by changes that they do not expect.
How: In most cases, changes to focus, location, or the current window should be initiated by a user activating (clicking) a link or button. If changes are initiated by other actions, make sure that there is an obvious cause-and-effect relationship between the action and the change. If changes are not likely to be expected, it may be necessary to provide explicit instructions to users before the changes occur.
Ref: WCAG 3.2.1, 3.2.2
IL-WEB-7.4 Do not change content unexpectedly.
What: Scripting can be used to add or change content on a web page.
Why: Users, especially those using screen readers and screen magnifiers, may not notice that content has changed on part of the page that they are not currently reading. If changes occur in parts of the page that have already been read, the user is not likely to "back up" to find the new content.
How: In most cases, content should only be changed or added after the current point of focus in the tab/reading order. For example, if entering a value in a field causes text to appear, the text should appear after that field in the reading order. It is also important to ensure that changes happen quickly enough that they are complete before the user reaches the changed element. For example, if selecting an item from a list box changes the value in a subsequent field, the change must be complete before the focus moves to the subsequent field. If content is changed above the user's focus, or if changes occur slowly enough that a user may move past the changed element before the change is complete, it may be necessary to provide an alert box or other instruction to direct the user to the changed element.
Ref: WCAG 3.2.1, 3.2.2
IL-WEB-7.5 Notify users of time limits and provide a means to extend time if possible.
What: Some web pages, frequently those that require a user to log in, time-out after a certain period of inactivity and require the user to start over.
Why: Users with visual, physical, or cognitive disabilities may require more time than average to read and interact with a web page.
How: Provide a clear explanation of any time limits. If possible, offer the user a way to extend or remove the limits. Avoid settinh time limits unless they are absolutely necessary.
Ref: WCAG 2.2.1
Multimedia
IL-WEB-8.1 Do not convey information with sound alone.
What: It is possible to use sound for a variety of purposes, including presenting warning signals, cues, or verbal instructions.
Why: Users who are deaf or hard of hearing may miss information provided only through sound.
How: Whenever significant information is provided by sound, include a visual indicator that provides the same information as well.
Ref: WCAG 1.1.1, 1.2.1
IL-WEB-8.2 Do not automatically play audio.
What: It is possible for a web page to automatically play sound or music when it loads.
Why: Background sounds or music can make it difficult or impossible for screen readers user to hear their screen readers.
How: Do not automatically play audio for more than 3 seconds. Provide a means for users to start audio playback when they desire (e.g., a "play" button).
Ref: WCAG 1.4.2
IL-WEB-8.3 Provide a text equivalent for audio containing speech.
What: A text transcript is a word-for-word written record of the spoken content of a presentation, speech, meeting, or training, etc.
Why: Individuals who are deaf or hard of hearing may require text transcripts to access audio information.
How: Provide a link to an HTML or text transcript of any audio presented on a web site. Communication Access Realtime Translation (CART) providers can create transcripts of live events.
Ref: WCAG 1.1.1, 1.2.1
IL-WEB-8.4 Provide synchronized captions for multimedia containing speech.
What: Multimedia generally refers to recorded or live media containing both video and audio tracks. Captions are essentially a text transcript of the audio synchronized with the presentation.
Why: Individuals who are deaf or hard of hearing may require captions to access the audio information in multimedia.
How: Different media players have different means of including captions. When selecting a media player, but sure to confirm that it supports captions. If multimedia contains essential audio but no essential video (e.g., just a "talking head"), a text transcript may be provided instead of captions.
Ref: WCAG 1.2.2, 1.2.4
IL-WEB-8.5 Provide audio descriptions for multimedia containing essential visual information.
What: Audio descriptions are verbal descriptions of the actions and images displayed in a video that are inserted during pauses in the regular dialogue or audio track. Audio descriptions are only necessary if significant information that is presented visually is not discernable from the dialogue or audio track.
Why: Individuals who are blind or low-vision may require audio descriptions to access the visual information in multimedia.
How: Carefully consider whether audio descriptions are necessary to present the significant information of a multimedia recording. Many speech-intensive events, such as speeches, lectures, or conferences, do not contain essential video and, therefore, do not need audio description. When necessary, audio descriptions are usually best implemented by a professional "audio describer."
Ref: WCAG 1.2.3, 1.2.5
IL-WEB-8.6 Provide a means of pausing any moving, blinking, scrolling, or auto-updating information.
What: Animated graphics, Javascript, Flash, <blink> tags, <marquee> tags, and other techniques can be used to create a variety of animated effects.
Why: Some users with disabilities are not able to read text that is moving. Animation can be distracting to users with visual or cognitive disabilities.
How: Avoid animation and movement unless it provides significant additional information. If animation is used, provide a means of pausing the animation.
Ref: WCAG 2.2.2
IL-WEB-8.7 Do not include content that flashes faster than 3 times per second.
What: Animated graphics, Javascript, Flash, <blink> tags, and other techniques can be used to cause content to flash.
Why: Flashing faster than 3 times per second can trigger epileptic seizures.
How: Do not include content that flashes faster than 3 times per second.
Ref: WCAG 2.3.1
Frames
IL-WEB-9.1 Provide meaningful titles for frames.
What: HTML frames and iframes are used to divide web pages into separate areas, each displaying a separate web page. Each frame is identified by its title attribute and each page contained within a frame is identified by its <title> element.
Why: To navigate pages with frames, users who are blind must be able to identify the different frames and understand the purpose of each frame. Most screen readers identify frames by speaking the title of each frame.
How: Give each frame and iframe a concise, unique, understandable title attribute that indicates the frame's function and is unique within the frameset. Do not include the word "frame." Set the <title> element of each page contained within a frame to match its title attribute or to identify the current content of that frame. Avoid using empty frames.
Ref: WCAG 4.1.2
Order
IL-WEB-10.1 Ensure that reading order is logical.
What: Web page are often layed out in multiple rows and columns. "Reading order" refers to the order in which a screen reader reads through the page.
Why: Screen readers read through the elements on a web page in the order in which they appear in the page code, regardless of how they are positioned visually. It is essential that the reading order match the logical flow of the document so that a screen reader user would hear the document in the same order that a visual reader would read it.
How: Check the reading order by following the order in which elements appear in the HTML code. Adjust the reading order by rearranging the order in which elements are defined in the code.
Ref: WCAG 1.3.2
IL-WEB-10.2 Ensure that tab order is logical.
What: Screen reader and keyboard users move between form fields and links using the Tab key. The order in which form fields receive focus is called the "tab order." By default, the tab order follows the order in which elements appear in a page's HTML code.
Why: Depending on the design and layout of a page, the tab order may not match the visual (or logical) order of fields on a form. Reading fields out of their intended order can be disorienting for a screen reader or keyboard user.
How: Make sure that fields appear in logical order in the HTML code or use the tabindex attribute on each field to set the appropriate order.
Note: Any element with a positive tabindex will come before all elements without tabindex in the tab order. As a result, tabindex must usually be applied to all or none of the focusable elements on a page.
Ref: WCAG 2.4.3
Sites
IL-WEB-11.1 Identify components consistently throughout a site.
What: Web sites may include elements that have the same function on many pages, for example, a "Search" field and button may be used to search the site or a printer icon (image with alternate text) may be used to print the page.
Why: All users, and especially those with disabilities, find it easier and more efficient to understand repeated elements when they are identified consistently.
How: Ensure that elements that have the same function, have consistent appearance, labels, and/or alternate text on each page.
Ref: WCAG 3.2.4
IL-WEB-11.2 Present navigation components consistently throughout a site.
What: Web sites may include navigation menus, links, and/or controls on many pages.
Why: All users, and especially those with disabilities, find it easier and more efficient to use navigation components when they are presented consistently.
How: Ensure that navigation components, such as menus, "skip navigation" links, search fields, etc., have consistent appearance, operation, and position on each page.
Ref: WCAG 3.2.3
IL-WEB-11.3 Provide multiple ways of navigating a site.
What: Web sites can use different ways of navigating from page to page, such as menus, search fields, links in the main content, site maps, footer links, etc.
Why: Some users may find one way of navigating easer than others.
How: Provide more than one mechanism to find and navigate to the different pages within a web site. (This does not apply to pages that are steps in a process that must be completed in a specific order.)
Ref: WCAG 2.4.5