Accessibility

Acceptance Criteria

1. If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
2. Use alt attributes on img elements.
3. Provide link text that describes the purpose of a link for anchor elements.
4. Use alt attributes on images used as submit buttons.
5. Use label elements to associate text labels with form controls.
6. Use title attribute to identify form controls when the label element cannot be used.
7. Use null alt text and no title attribute on img elements for images that assistive technologies should ignore ex: alt="".
8. Use CSS margin and padding rules instead of spacer images.

Notes

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.

Acceptance Criteria

1. People who are deaf or have a hearing loss can access the auditory information in the synchronized media content through captions.
2. Captions are not needed when the synchronized media is, itself, an alternate presentation of information that is also presented via text on the Web page.
3. Captions not only include dialogue, but identify who is speaking and include non-speech information conveyed through sound, including meaningful sound effects.

Notes

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Acceptance Criteria

1. View the video-only content while referring to the alternative for time-based media.
2. Check that the information in the transcript includes the same information that is in the video-only presentation.
3. If the video includes multiple people or characters, check that the transcript identifies which person or character is associated with each action described.
4. Check that at least one of the following is true:
   • The transcript itself can be programmatically determined from the text alternative for the video-only content.
   • The transcript is referred to from the programmatically determined text alternative for the video-only content.
   • If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions.

Notes

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such.

Prerecorded Audio-only

An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.

Prerecorded Video-only

Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

Acceptance Criteria

1. Use semantic elements & aria landmarks to markup structure. (nav, section, article, etc. instead of div)
2. DO NOT use inline styles.
3. Use standard text formatting conventions for paragraphs. (p)
4. Use standard text formatting conventions for lists. (ul, ol, li)
5. Use standard text formatting conventions for headings. (h1, h2, h3, etc.)
6. Organize a page using headings.
7. Use CSS to control visual presentation of text.
8. Use the aria-describedby property to provide a descriptive label for user interface controls.

Form Acceptance Criteria

1. Identify a required field with the aria-required property.
2. Using OPTGROUP to group OPTION elements inside a SELECT.
3. Using label elements to associate text labels with form controls.
4. Use the title attribute to identify form controls when the label element cannot be used.
5. Provide a description for groups of form controls using fieldset and legend elements.
6. Required fields must be identified.

Table Acceptance Criteria

1. Use table markup to present tabular information. Tables should ONLY be used to markup tabular information.
2. Table markup needs to consist of at least the elements table, tr, th, and td.
3. Use the summary attribute to associate header cells and data cells in data tables.
4. Using the scope attribute to associate data cells with header cells in data tables.
5. Use id and headers attributes to associate data cells with header cells in data tables.

Notes

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

* The region and article roles are not ARIA landmarks. The most useful of these for most websites are header/banner, nav/navigation, main, and footer/contentinfo.

Best Practice

1. 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.
2. 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.
3. In these cases, identical roles should be distinguished from each other using a valid technique for labelling regions.

Acceptance Criteria

1. The DOM order must match the visual order.
2. Use left justified text for languages that are written left to right.

Notes

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Acceptance Criteria

1. Do not use a graphical symbol alone to convey information.
2. Use an image with a text alternative for graphical symbols.
3. See SVG Library Examples on how to use icons.

Notes

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

Acceptance Criteria

None at this time.

Notes

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential opens in new window.

Acceptance Criteria

1. The input field serves a purpose identified in the Input Purposes for User Interface Components section opens in new window; and
2. The content is implemented using technologies with support for identifying the expected meaning for form input data.

Notes

The purpose of each input field collecting information about the user can be programmatically determined when meeting the below acceptance criteria.

Acceptance Criteria

1. Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
2. Provide a mechanism to easily dismiss the additional content, such as by pressing Escape or selecting a close button.
3. Once new styles are set, text must fit within the bounds of its containing box without being cut off or overlapping other boxes.
4. Once content appears, it should remain visible until:
   • The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience;
   • The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or
   • The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.
   • This criterion does not affect the use and display of the title attribute in HTML when it displays as a small tooltip.
   • Modal dialogs are out of scope for this criterion because they must take keyboard focus and thus should not appear on hover or focus.
   • Content which can be triggered via pointer hover should also be able to be triggered by keyboard focus.
   • ARIA: Use role="tooltip"
   • CSS: Use hover and focus pseudo classes

Notes

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the below examples are true.

Acceptance Criteria

1. Information that is conveyed by color differences needs to also be available in text.
2. Do not identify required or error fields using color differences only. (Please see standard set up for error handling)
3. Using a mouse, hover over the element - check that the background, border, or text color changes. (See link style standards.)

Notes

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Acceptance Criteria

1. Any sound that plays must turn off automatically within three seconds.
2. Provide a control near the beginning of the Web page that turns off sounds that play automatically.
3. Play sounds only on user request

Notes

If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Acceptance Criteria

1. 4.5:1 ratio if:
   • Normal weight text size is UNDER 1.5rem / 18pt / 150% / 24px
   • Bold weight text size is UNDER 1.17rem / 14pt / 116.67% / 18.67px
2. 3:1 ratio if:
   • Normal weight text size is OVER 1.5rem / 18pt / 150% / 24px
   • Bold weight text size is OVER 1.17rem / 14pt / 116.67% / 18.67px

When Text DOES NOT have to meet contrast minimum

• Text is part of an inactive user interface component that is purely decoration, not visible to anyone.
• Text is part of a logo or brand name.

Notes

The visual presentation of text and images of text has a contrast ratio based on the below information.

WebAIM Contrast Checker Tool

Acceptance Criteria

1. Ensure that text containers resize when the text resizes.
2. Use measurements that are relative to other measurements in the content.
   • Using rem units or percent for font sizes.
   • Calculate size and position in a way that it scales with the text.
   • Use predefined Grid system for layout to ensure liquid layout. DO NOT specify layout widths in px.
   • User must be able to change size of all text on page up to 200 percent.
   • Ensure there is no loss of content or functionality when the text resizes.

Notes

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Acceptance Criteria

1. No text should be embedded in an image.

Exceptions to the Rule

1. Customizable: The image of text can be visually customized to the user's requirements;
2. Essential: A particular presentation of text is essential to the information being conveyed. (Logotypes (text that is part of a logo or brand name) are considered essential.)

Notes

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images.

Acceptance Criteria

1. In other words, ALL pages need to be responsive and utilize media queries to reflow.
2. Breakpoints are not only triggered by narrower viewpoints, but also when browser zoom function is used.
3. All pages must fit a minimum of 320px, which is equivalent to a desktop browser window at 1280px wide and zoomed in to 400%.
4. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.
5. It is also important that content is not hidden off-screen. i.e., zooming into a vertically scrolling page should not cause content to be hidden to one side.
6. All content and funtionality must still be available, either directly, or via accessible controls.
7. Do not use fixed sized containers or fixed position content (CSS).

Notes

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions.

Acceptance Criteria

1. All button states must meet contrast ration requirements of at least 3:1.
2. Focus indicator must have sufficient contrast when the component is focused.
3. Disabled or inactive UI components do not have to meet the contrast requirements. i.e., A submit button that is visible but not active until all required fields are completed.
4. Graphical elements that must convey meaning, or are necessary for the user to understand the graphic, must meet contrast requirements.

Notes

The visual presentation of the examples below have a contrast ratio of at least 3:1 against adjacent color(s).

Ways to Test

• Identify each user-interface component (link, button, form control) on the page and:
  • Identify the visible boundaries of the component that indicate it is a component and test the contrast ratio against the adjacent colors.
  • Identify the state indicators and test the contrast ratio against the adjacent colors.
• Identify each graphic on the page that includes information required for understanding the content (i.e. excluding graphics which have visible text for the same information, or are decorative) and:
  • Check the contrast of the graphical object against its adjacent colours;
  • If there are multiple colours and/or a gradient, chose the least contrasting area to test;
  • If it passes, move to the next graphical object;
  • If the least-contrasting area is less than 3:1, assume that area is invisible, is the graphical object still understandable?
  • If there is enough of the graphical object to understand, it passes, else fail.

Acceptance Criteria

1. Bookmarklet to use for testing. opens in new window
2. A user must be able to set text style properties as listed above without losing content or functionality. (This doesnt mean all text needs to be set like this for ALL users.)
3. Once new styles are set, text must fit within the bounds of its containing box without being cut off or overlapping other boxes.

Notes

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting the below examples and by changing no other style property.

Acceptance Criteria (must meet 1)

1. Turn off: A mechanism is available to turn the shortcut off;
2. Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
3. Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Notes

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters.

Acceptance Criteria

1. Identify all functionality on the content.
2. Check that all functionality can be accessed using only the keyboard or keyboard interface.

a, button, or input Acceptance Criteria

1. 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.
2. 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.

Notes

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

To implement this technique, first determine what functionality is available to users on the page. In this step, it is important to consider functions performed using both the mouse and the keyboard together.

Making Actions Keyboard Accessible by Using the Onclick Event of Anchors & Buttons

Examples: https://www.w3.org/TR/WCAG20-TECHS/SCR35.html opens in new window

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.

It is necessary when adding handlers to other events.
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).

Acceptance Criteria

1. Tab through content from start to finish.
2. Check to see that keyboard focus is not trapped in any of the content.
3. If keyboard focus appears to be trapped in any of the content, check that help information is available explaining how to exit the content and can be accessed via the keyboard.

Notes

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Acceptance Criteria

1. If Moving, blinking, scrolling:
   • Starts automatically AND
   • Lasts more than five seconds AND
   • Is presented in parallel with other content
     • Then, there must be a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential.
2. If Auto-updating information:
   • Starts automatically AND
   • Is presented in parallel with other content
     • Then, there must be a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Notes

None at this time.

Acceptance Criteria

1. Turn off: The user is allowed to turn off the time limit before encountering it.
2. Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting.
3. Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times.
4. Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible.
5. Essential Exception: The time limit is essential and extending it would invalidate the activity.
6. 20 Hour Exception: The time limit is longer than 20 hours.

Notes

None at this time.

Acceptance Criteria

1. Ensure no component of the content flashes more than three times in any 1-second period.
2. Any video scene involving bright flashes is edited so that the flashes occur no more than three times in any 1-second period.

Notes

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Acceptance Criteria

1. Use user interface components that are highlighted by the user agent when they receive focus
2. Use CSS to change the presentation of a user interface component when it receives focus
3. Highlight a link or control when the mouse hovers over it
4. Provide a highly visible highlighting mechanism for links or controls when they receive keyboard focus

Notes

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Acceptance Criteria

1. Create links to skip blocks of repeated material:
   • Add a link at the top of each page that goes directly to the main content area, or
   • Add a link at the beginning of a block of repeated content to go to the end of the block.

Notes

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

Use ARIA Landmarks to Identify Regions of a Page

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.

ARIA Landmark Role Values

• 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.)

Use heading elements at the beginning of each section of content to convey the structure

• Heading markup can be used for the following:
  • To indicate start of main content
  • To mark up section headings within the main content area
  • To demarcate different navigational sections like top or main navigation, left or secondary navigation and footer navigation
  • To mark up images of text that are used as headings
  • To allow users the ability to navigate a page by sections or skip repeated blocks of information
  • Make the h1, h2, h3 etc be meaningful
  • When headings are nested hierarchically, the most important information is given the highest logical level, and subsections are given subsequent logical levels.(i.e., h2 is a subsection of h1). Providing this type of structure will help users understand the overall organization of the content more easily.

Acceptance Criteria

1. The descriptive title of an HTML Web page is marked up with the <title> element so that it will be displayed in the title bar.

Notes

Web pages have titles that describe topic or purpose.

Acceptance Criteria

1. Place the interactive elements in an order that follows sequences and relationships within the content
2. Give focus to elements in an order that follows sequences and relationships within the content by:
   • Creating a logical tab order through links, form controls, and objects
   • Making the DOM order match the visual order

Notes

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Acceptance Criteria

1. Provide link text that describes the purpose of a link.
2. Provide a supplemental description of the purpose of a link using one of the following techniques:
   • Supplementing link text with the title attribute.
   • Using CSS to hide a portion of the link text. (can use class visually-hidden)
3. Identify the purpose of a link using link text combined with programmatically determined link context using one of the following techniques:
   • Identifying the purpose of a link using link text combined with its enclosing list item.
   • Identifying the purpose of a link using link text combined with its enclosing paragraph.
   • Identifying the purpose of a link in a nested list using link text combined with the parent list item under which the list is nested.
   • DO NOT use a null alt on an image where the image is the only content in a link.

Notes

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Acceptance Criteria

1. Provide links to navigate to related Web pages
2. Provide a search function to help users find content
3. Provide a list of links to all other Web pages

Notes

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Acceptance Criteria

1. Providing descriptive headings opens in new window.
2. Providing descriptive labels opens in new window.
3. Use required form control. View examples opens in new window of required form controls.

Notes

Headings and labels describe topic or purpose.

Descriptive Headings

An HTML page that describes the range of tasks for disaster preparation may have the following headings: Note that the level 2 headings have the distinguishing information at the beginning (ie, instead of "Preparation for floods", "Preparation for fires", etc).

Acceptance Criteria

1. When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Notes

Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.

Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.

Acceptance Criteria

1. After text is input in a field, shaking a device shows a dialog offering users to undo the input. A cancel button next to the text field offers the same functionality.
2. A user can tilt a device to advance to the next or a previous page. Buttons or links are also provided to perform the same function.
3. A user can move or pan a device to change the view in an interactive photo. A control is also available to perform these same functions.
4. A user can gesture towards the device to navigate content. Controls are also available to navigate.
5. A user can choose an application setting which turns off Shake to Undo features.

Exceptions

• Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
• Essential: The motion is essential for the function and doing so would invalidate the activity.

Notes

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation.

Acceptance Criteria

1. Ensure all content can be operated without complex gestures.
2. Examples of single-point activation on a touchscreen or touchpad include taps, double taps, and long presses.
3. Examples for a mouse, trackpad, head-pointer, or similar device include single clicks, click-and-hold and double clicks.
4. Pinch gesture for zooming and drag gestures to move the visible area must also contain [+] and [-] buttons to zoom in and out, and arrow buttons to pan in all directions.
5. Slider controls that use swiping or dragging must also have buttons on both sides to allow scrolling or increment/decrement the selected value and update the posiiton.

Notes

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Acceptance Criteria

1. Visible text labels of controls must match their accessible names.
2. The accessible name of a button begins with the same text as the visible label.

Notes

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Acceptance Criteria

1. Check that the value of the control slider (range) can be set with a tap or click using a pointer.
2. Check that single pointer operable controls exist over or adjacent to the content slider that advance to adjacent chunks of content.

Notes

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Acceptance Criteria

1. The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
   • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
   • Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
   • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
   • User agent control: The size of the target is determined by the user agent and is not modified by the author;
   • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

Notes

Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

Acceptance Criteria

1. Use language attributes on the html element.
2. Specify the default language in the HTTP header

Notes

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

If you have to change the language

This example demonstrates the use of the xml:lang attribute defining a quote written in German. This snippet could be included by an XHTML 1.1 document where lang is not allowed.

Acceptance Criteria

1. Use language attributes on the html element.
2. specify the default language in the HTTP header

Notes

The default human language of each Web page can be programmatically determined.

Acceptance Criteria

1. Use labels, names, and text alternatives consistently for content that has the same functionality AND following the sufficient techniques for Success Criterion 1.1.1 and sufficient techniques for Success Criterion 4.1.2 for providing labels, names, and text alternatives
2. Ensure that the text alternative conveys the function of the component and what will happen when the user activates it.
3. Use the same non-text content for a given function whenever possible

Notes

Components that have the same functionality within a set of Web pages are identified consistently.

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 satisfy this Success Criterion.

A single non-text-content-item may be used to serve different functions

In such cases, different text alternatives are necessary and should be used. Examples can be commonly found with the use of icons such as check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the Web page. A check mark icon may function as "approved", "completed", or "included", to name a few, depending on the situation. Using "check mark" as text alternative across all Web pages does not help users understand the function of the icon. Different text alternatives can be used when the same non-text content serves multiple functions.

Acceptance Criteria

1. Open new windows and tabs from a link only when necessary.
2. Give users advanced warning when opening a new window.
3. A page pops up a new window only when the user clicks(or uses spacebar) on a button rather than using onfocus to pop up a new window.
4. A submit button is used to move on to the next data entry screen rather than having the next screen appear automatically when the user tabbed onto a 'done' button.
5. The objective of this technique is to provide a method for activating things that is predictable by the user. Users with cognitive disabilities and people using screen readers or screen magnifiers may be confused by an unexpected event such as automatic form submission or activation of a function that causes a change of context.

Notes

When any component receives focus, it does not initiate a change of context.

Acceptance Criteria

1. Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
2. Providing a submit button to initiate a change of context using one of the following techniques:
   • Providing submit buttons
   • Using a button with a select element to perform an action
   • Describing what will happen before a change to a form control that causes a change of context to occur is made
   • Using an onchange event on a select element without causing a change of context
   • Giving users advanced warning when opening a new window

Notes

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Selecting elements causes data within dropdown to update accordingly. See example on how to set up. opens in new window

Acceptance Criteria

1. Use templates to ensure consistency across multiple Web pages.
2. Create layout, positioning, layering, and alignment.

Notes

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Acceptance Criteria

1. If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content, unless a change is initiated by the user:
   • Human contact details;
   • Human contact mechanism;
   • Self-help option;
   • A fully automated contact mechanism.
2. Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.

Notes

Put help in the same place when it is on multiple pages.

Acceptance Criteria

• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

If an Application Causes a Legal Transaction to Occur, Such as Making a Purchase

• Provide a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request.
• Provide the ability for the user to review and correct answers before submitting.

If an Action Causes Information to be Deleted

• Provide the ability to recover deleted information.
• Request confirmation to continue with selected action.

Notes

For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the below criteria is true.

Acceptance Criteria

1. Provide text descriptions to identify required fields that were not completed.
2. Provide client-side validation and alert (if applicable).
3. Provide a text description when the user provides information that is not in the list of allowed values.
4. Provide a text description when user input falls outside the required format or values.
5. Highlight errors where they occur.
6. Need asterisk by required fields. Also, need note stating what asterisk means: Starred(*) fields are required.

Notes

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Acceptance Criteria

1. Provide text instructions at the beginning of a form or set of fields that describes the necessary input.
2. Position labels to maximize predictability of relationships.
3. Indicate required form controls using label or legend.
4. Use label elements to associate text labels with form controls.
5. Provide a description for groups of form controls using fieldset and legend elements.
6. Use the title attribute to identify form controls when the label element cannot be used.

Form Labeling

More Information on ARIA within Forms opens in new window

Meeting Acceptance Criteria on Form Labeling

1. Use <label> element when you can. It has excellent browser and screen reader support, and users can click on the label to select the associated form control.
2. Use aria-labelledby to overcome the 1:1 limitations of <label>.
3. Use aria-describedby in addition to a label when you need to associate descriptive text to the form control.
4. Use a hidden <label> or title or aria-label when a visible text label is not available.

Notes

Labels or instructions are provided when content requires user input.

Acceptance Criteria

1. Create a mechanism that allows users to jump to errors.
2. Make error messages easy to understand and distinguishable from other text in the Web page.
3. When mandatory information has not been provided, including descriptions or examples of correct information in addition to identifying the field as mandatory.
4. Repeat and emphasize suggestions for correcting each input error in the context of its form field.
5. Provide a way for the user to skip from each item in a list of suggestions to its corresponding form field.
6. Provide additional contextual help for the form field requiring change.
7. Accept input data in a variety of formats.
8. Provide success feedback when data is submitted successfully

If a Mandatory Field Contains No Information

• Provide text descriptions to identify required fields that were not completed.
• Identify a required field with the aria-required property.

If Information for a Field is Required to be in a Specific Data Format

• Use aria-alertdialog to Identify Errors.
• Provide a text description when user input falls outside the required format or values.
• Provide suggested correction text.
• Provide client-side validation and alert.
• Provide client-side validation and adding error text via the DOM.

Notes

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Acceptance Criteria

1. A cognitive function test opens in new window (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
   • Alternative: Another authentication method that does not rely on a cognitive function test.
   • Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
   • Object Recognition: The cognitive function test is to recognize objects.
   • Personal Content: The cognitive function test is to identify non-text content the user provided to the website.

Notes

Don’t make people solve, recall, or transcribe something to log in.

Acceptance Criteria

1. Validate web pages.
2. Ensure that opening and closing tags are used according to specs.
3. Ensure that id attributes are unique on the web page.
4. Avoid using duplicate attributes on elements.

Notes

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

Acceptance Criteria

1. Use the title attribute of the frame and iframe elements.
2. Use the title attribute to identify form controls when the label element cannot be used.
3. Use label elements to associate text labels with form controls.

Notes

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

• More information about Abstract Roles
• More information about Landmark Roles
• More information about Live Region Roles
• More information about Structural Roles
• More information about Widget Roles
• More information about Window Roles

Acceptance Criteria

1. If status message advises on the success or results of an action, use role="status". Ex: When providing success feedback when data is submitted successfully.
2. If status message conveys a suggestion or warning, use role="alert". Ex: Validation summary.
3. If status message conveys information on the progress of a process, use role="progressbar".
4. Do not use role="alert" or aria-live="assertive" on content which is not important and time-sensitive.

Notes

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Acceptance Criteria

1. Websites and mobile apps must fulfill the success criteria for Level A and Level AA per the WCAG 2.1 standard.
2. Companies must have a publicly posted, regularly updated accessibility statement explaining accessible content standards and they must provide users with a link to provide feedback.