Agencies
Services
IITAA 2.0 Techniques
IITAA Techniques are simple instructions on how to meet WCAG 2.1 AA guidelines written for web developers. They are modeled after the W3C Techniques for WCAG 2.0 and organized in the easy-to-follow format of the orginal IITAA Implementation Guidelines.
IITAA Techniques for Web Sites & Applications
The following techniques are applicable to web sites and applications that are displayed in a web browser as HTML, CSS, and Javascript.
Text
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>.
WCAG 3.1.1, 3.1.2
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 page is loaded. 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.
WCAG 2.4.2
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 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 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.)
WCAG 21.3.1, 2.4.1
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; }
WCAG 1.3.1, 2.4.6
Use lists to identify series of related items.
What: HTML includes "ordered" (<ol>) and "unordered" (<ul>) lists, each of which can contain list items (<li>) and "nested" lists.
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.
WCAG 1.3.1
Ensure that reading order is logical.
What: "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.
WCAG 1.3.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 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, hiding overflow, or supressing scrollbars.
WCAG 1.4.4
Color
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 (16px) text must have a contrast ratio of at least 4.5:1. Large (24px or 18px bold) text, must have a contrast ratio of at least 3:1. Contrast requirements do not apply to text that is invisible, purely decorative, within a disabled form field, or part of a logo.
For instructions on how to measure contrast ratios, see our Color Contrast Guide.
WCAG 1.4.3
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.
WCAG 1.4.1
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).
WCAG 1.3.3
Images
Use text to display text.
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.
WCAG 1.4.5
Provide "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 complex images, suchs as charts and maps - use alternate text to provide a concise name for the image and provide the complete information presented in the image below it or on a page reachable from a link on or below the image. (Don't use longdesc.)
- 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. Avoid using text characters to simulate images, such as using "->" (dash greater than) to simulate an arrow, since there is no way to provide alternate text.
WCAG 1.1.1
Tables
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.
WCAG 1.3.1
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.
WCAG 1.3.1
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.
WCAG 1.3.1
Links
Ensure that link text is 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.
WCAG 2.4.4
Forms
Provide labels 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 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 instead.
WCAG 1.3.1, 2.4.6, 3.3.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.
WCAG 1.3.1, 2.4.6, 3.3.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.
WCAG 2.4.3
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.
WCAG 2.4.7
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.
WCAG 3.3.1
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."
WCAG 3.3.3
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.
WCAG 3.3.4
Interactions
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.
WCAG 2.1.1
Do not change content or focus unexpectedly.
What: Scripting can be used to add or change content on a web page, 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, or they may miss imporant changes.
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 or other instruction to direct the user to the changed element.
Changes to focus, location, or the current window should only 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.
WCAG 3.2.1, 3.2.2
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.
WCAG 2.2.1
Multimedia
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.
WCAG 1.1.1, 1.2.1
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).
WCAG 1.4.2
Provide a text equivalent for any 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.
WCAG 1.1.1, 1.2.1
Provide 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.
WCAG 1.2.2, 1.2.4
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."
WCAG 1.2.3, 1.2.5
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.
WCAG 2.2.2
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.
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.
WCAG 4.1.2
Sites
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.
WCAG 3.2.4
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.
WCAG 3.2.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.)
WCAG 2.4.5