Main Content for Page

VPAT Checklist - User Input, Forms, and Dynamic Content

Article Index

Page 6 of 6

User Input, Forms, and Dynamic Content

Accessibility Techniques for Device-Independent User Input
Topic Technique WCAG AA Requirement
Keyboard Focusable with Tab Key: Links, buttons, and interactive controls MUST be keyboard-focusable. Required WCAG 2.1.1
Logical Tab Order: The navigation order of focusable elements MUST be logical and intuitive. Required WCAG 2.4.3
No Positive tabindex Values: tabindex of positive values SHOULD NOT be used. Best Practice  
Visual Focus Indicator: All focusable elements MUST have a visual focus indicator when in focus. Required WCAG 2.4.7
Enhanced Visual Focus Indicator: Focusable elements SHOULD have enhanced visual focus indicator styles. Best Practice  
Color Contrast of Visual Focus Indicator: The contrast of all large visual focus indicators (at least 3px by 3px) against the background) SHOULD be at least 3 to 1. Required WCAG 1.4.11 (WCAG 2.1)
Keyboard Functionality: Functionality MUST be available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard. Required WCAG 2.1.1
Keyboard Traps: Keyboard focus MUST NOT be locked or trapped in a particular page element and the user MUST be able to navigate to and from all navigable page elements using only a keyboard. Required WCAG 2.1.2
Keyboard Shortcuts: Page-specified shortcut keys and accesskeys MUST NOT conflict with existing keyboard shortcuts in the browser, operating system, or assistive technologies. Required WCAG 2.1.4 (WCAG 2.1)
Custom Keystroke Instructions: When custom keyboard behavior is required to use a component, keyboard instructions MUST be provided. Required WCAG 3.3.2
ARIA Widget Instructions: ARIA widgets that require more than just the Tab key to interact with may be confusing to users (even when the widgets follow the WAI-ARIA Authoring Practices), so you MAY provide keyboard instructions. Best Practice  
Keyboard Focus Management During Interactions Set Keyboard Focus: The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction. Required WCAG 2.4.3
No Lost Focus: The focus MUST NOT become lost or reset to the top of the page, except when loading or re-loading a page. Required WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination element MUST contain discernible text (either standard text or programmatically-associated text). Required WCAG 1.3.1
Mouse

Click Target Size: The click target size SHOULD be at least 44 by 44 CSS pixels.

Note: Allowed exceptions include the following circumstances:

  • The target is available through an equivalent control of at least 44 by 44 CSS pixels
  • The target is inline (in a sentence or block of text)
  • The target size is user-customizable
  • The smaller target size is essential to the information or functionality
 Best Practice  
Visual Hover Indicator: An enhanced visual hover indicator SHOULD be provided. Best Practice  
Voice Visual Labels Match Programmatic Labels: The visual labels for links, buttons, form elements, and other controls SHOULD match the programmatic labels (to allow easy and intuitive voice commands). Required WCAG 2.5.3 (WCAG 2.1)
All the keyboard requirements above apply. Required multiple
Touch Touch Functionality: Functionality MUST be available using standard touch methods, unless the functionality cannot be accomplished in any known way using a touch device. Required WCAG 2.5.1 (WCAG 2.1)

Touch Functionality with Screen Reader Enabled: Functionality MUST be available using screen reader touch methods (e.g. single tap or double tap actions), unless the functionality cannot be accomplished in any known way using a touch device.

Note: The touch actions with the screen reader turned on are completely different from the touch actions when the screen reader is turned off.

 Required WCAG 2.5.1 (WCAG 2.1)
Single pointer: Functionality MUST work with a single pointer (e.g. a single finger), unless multipoint activation is essential. Required WCAG 2.5.1 (WCAG 2.1)
Touch cancellation: Touch events MUST NOT be activated on a down event (use up events instead), to allow users to cancel, abort, or undo touch events, unless the down event is essential. Required WCAG 2.5.2 (WCAG 2.1)
Gesture-Only Functionality: Features MUST NOT depend on swipe or gesture motions as the only activation method. Required WCAG 2.5.1
(WCAG 2.1)
Motion Actuation: Features MUST NOT depend on kinetic motion of the device (e.g. shake, raise, lower, tilt). Required WCAG 2.5.4
(WCAG 2.1)
Focus Trap: Touch/gesture focus MUST NOT be locked or trapped in a particular page element and the user MUST be able to navigate to and from all navigable page elements using standard touch actions. Required WCAG 2.1.2

Touch Target Size: The click/touch target size SHOULD be at least 44x44 CSS pixels, unless at least one of the following is true:

  • There is an equivalent control on the same page that is at least 44x44 CSS pixels, OR
  • The target is inline (in a sentence or block of text), OR
  • The user agent controls the target size, OR
  • The smaller size of the target is essential to the information being conveyed.
 Best Practice  
Accessibility Techniques for Form Inputs, Labels, and Instructions
Topic Technique WCAG AA Requirement
Labels for Inputs Programmatic Labels: Labels MUST be programmatically associated with their corresponding elements. Required WCAG 1.3.1
Discernible Label Text: Labels MUST be available as programmatically-discernible text. Required WCAG 1.3.1
Meaningful Labels: Labels MUST be meaningful. Required WCAG 1.3.1
Sensory Dependencies of Labels: Labels MUST NOT rely solely on references to sensory characteristics. Required WCAG 1.3.3
Icons as Labels: Icons/graphics MAY be used as the only visual label (without visual text) only if the meaning of the icon is visually self-evident AND if there is a programmatically associated semantic label available to assistive technologies. Required WCAG 1.3.1
Placeholder Text: Placeholder text is allowed, but MUST NOT be used as the only method of providing a label for a text input. Required WCAG 1.3.1
Visible Labels: Labels MUST be visible. Required WCAG 3.3.2
Matching Programmatic Label and Visual Label: The programmatic label MUST include the same text presented in the visual label, to facilitate voice activation. Required WCAG 2.5.3
(WCAG 2.1)
Multiple Labels for One Input: When multiple labels are used for one element, each label MUST be programmatically associated with the corresponding element. Required WCAG 1.3.1
Once Label for Multiple Inputs: When one label is used for multiple elements, the label MUST be programmatically associated with each of the corresponding elements. Required WCAG 1.3.1
Visually Adjacent Labels: A label SHOULD be visually adjacent to its corresponding element. Best Practice  
Programmatically Adjacent Labels: A label SHOULD be adjacent in the DOM to its corresponding element. Best Practice  
Labels for Groups of Inputs Programmatic Group Labels: Group labels MUST be programmatically-associated with the group if the individual labels for each element in the group are insufficient on their own (e.g. a group of radio buttons that has a group label plus individual labels for each radio option). Required WCAG 1.3.1
Discernible Text in Group Labels: Group labels MUST contain programmatically-discernible text. Required WCAG 1.3.1
Meaningful Group Labels: Group labels MUST be meaningful. Required WCAG 1.3.1
Sensory Dependencies of Group Labels: Group labels MUST NOT rely solely on references to sensory characteristics. Required WCAG 1.3.3
Visible Group Labels: Group labels MUST be visible. Required WCAG 3.3.2
Matching Programmatic Label and Visual Label: The programmatic label MUST include the same text presented in the visual label, to facilitate voice activation. Required WCAG 2.5.3
(WCAG 2.1)
Visually Adjacent Group Labels: Group labels SHOULD be visually adjacent to the grouped elements. Best Practice  
Programmatically Adjacent Group Labels: Group labels SHOULD be adjacent in the DOM to the grouped elements. Best Practice  
Instructions About Inputs Programmatic Association of Input Instructions: Instructions for an element MUST be programmatically-associated with the element. Required WCAG 3.3.2
Programmatically-Discernible Text in Input Instructions: Instructions for an element MUST be available as programmatically-discernible text. Required WCAG 3.3.2
Meaningful Input Instructions: Instructions for an element MUST be meaningful. Required WCAG 3.3.2
Visible Input Instructions: Instructions for an element MUST be visible. Required WCAG 3.3.2
Sensory Dependencies of Input Instructions: Instructions for an element MUST NOT rely solely on references to sensory characteristics. Required WCAG 1.3.3
Hidden Input Instructions: If the instructions for an element are not critical, the instructions MAY be hidden until the user requests them. Best Practice  
Visually Adjacent Input Instructions: Instructions for an element SHOULD be visually adjacent to the element. Best Practice  
Programmatically Adjacent Input Instructions: Instructions for an element SHOULD be adjacent in the DOM to the element. Best Practice  
Instructions About an Entire Form, a Group, or a Section Programmatic Association of Group Instructions: Instructions for groups or sections SHOULD be programmatically-associated with the group. Required WCAG 3.3.2
Programmatically-Discernible Text in Group Instructions: Instructions for groups or sections MUST be programmatically-discernible. Required WCAG 3.3.2
Meaningful Group Instructions: Instructions for groups or sections MUST be meaningful. Required WCAG 3.3.2
Visible Group Instructions: Instructions for groups or sections MUST be visible. Required WCAG 3.3.2
Sensory Dependencies of Group Instructions: Instructions for groups or sections MUST NOT rely solely on references to sensory characteristics. Required WCAG 1.3.3
Hidden Form Instructions: If the instructions are not critical to understand the purpose of a group or section, the instructions MAY be hidden until the user requests them. Best Practice  
Visually Adjacent Group Instructions: Instructions for groups or sections SHOULD be visually adjacent to the grouped elements. Best Practice  
Programmatically-Adjacent Group Instructions: Instructions for groups or sections SHOULD be adjacent in the DOM to the grouped elements. Best Practice  
Required Fields

Programmatic Designation: Required fields SHOULD be programmatically designated as such.

Note: At a minimum, WCAG requires an informative error message about the field after the user submits the form.

 Best Practice  
Visual Indicator: Required fields SHOULD have a visual indicator that the field is required. Best Practice  
Data Input Restrictions

Information About Data Input Restrictions: If a field allows only restricted input (e.g. a certain date format, only integers, no more than 4 characters, etc.), the restrictions SHOULD be communicated in the label or instructions.

Note: At a minimum, WCAG requires an informative error message about the field after the user submits the form.

 Best Practice  
Disabled Fields Awareness of disabled fields: If awareness of a disabled field is essential to understanding the content, an alternative way of communicating information about the disabled field MUST be provided (because disabled fields are not in the normal tab order by default, making it difficult for screen reader users to discover them). Required WCAG 1.3.1
Time Limits

Sufficient Time. Users MUST be allowed sufficient time to complete the form, through at least one of the following methods:

  • No time limit
  • The ability to turn off the time limit
  • The ability to extend the time limit
  • The ability to adjust/customize time limit
  • A minimum of 20 hours to complete the form

Note: This requirement can be waived if the time limit is essential to the meaning or purpose of the form (e.g. a timed auction).

 Required WCAG 2.2.1
Dynamic Forms See the requirements for Dynamic Content (JavaScript, AJAX) Required multiple
Custom Form Inputs (JavaScript/ARIA) See the requirements for Custom Widgets (JavaScript/ARIA) Required multiple
Accessibility Techniques for Form Validation and Feedback
Topic Technique WCAG AA Requirement
Labels and Instructions for Error Prevention

See the requirements and recommendations for Form Input, Labels, and Instructions, including:

  • Labels for inputs
  • Labels for groups of inputs
  • Instructions about inputs
  • Instructions about an entire form, a group, or a section
  • Required fields (in the full list of recommendations)
  • Data input restrictions (in the full list of recommendations)
  • Disabled fields
  • Time limits
 Required multiple
Context-Sensitive Help: Context-sensitive help SHOULD be available. Best Practice  
Critical Error Prevention

Web pages that process user input for any of the following:

  • legal commitments,
  • financial transactions,
  • user-controllable data (e.g. user profile, social media posts, OR
  • test/quiz responses

MUST implement at least one of the following error prevention techniques:

  • 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.
 Required WCAG 3.3.4
Error Prevention (All Circumstances)

All web pages that process user input SHOULD implement at least one of the following error prevention techniques:

  • 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.
 Best Practice  
Error Detection on Submit

Error Identification: If an error is automatically detected, the input with the error MUST be identified. Valid techniques include the following:

  • Add aria-invalid="true" to the input
  • Identify the input (referencing the label):
    • in a simple JavaScript alert
    • with information associated with the input via aria-describedby (widely supported) or aria-errormessage (not yet widely supported)
    • with error text added to the input's label (other techniques are more semantically correct, but this is a reliable method)
    • with text on the web page (it may be appropriate to move the keyboard focus to the error message)
    • with an aria-live or role="alert" announcement
    • with information about the error in the page <title> if the submission causes a page reload or a new page load.
 Required WCAG 3.3.1
Dynamic Error Detection Visible Real-Time Error Messages: Real-time error messages MAY be scripted to show on the screen for sighted users, but attempts to announce the real-time messages to screen reader users can be problematic (see the next two rows below). It is usually acceptable to wait to announce real-time errors until after form submission, assuming that no data has been saved yet. Best Practice  
Live Announcements per Keystroke: ARIA live error messages SHOULD NOT be scripted to occur with every keystroke (to avoid overwhelming screen reader users), unless there is a delay built into the script to avoid announcements while the user is actively typing. Best Practice  
Live Announcements on Leaving a Field: ARIA live error messages SHOULD NOT be scripted to occur when a user leaves a field, because the aria-live announcement will may conflict with the screen reader's attempt to read the next element which receives focus, causing some information to be interrupted or not announced at all. Best Practice  
Error Message Characteristics Error Suggestion: 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. Required WCAG 3.3.3
Programmatically-Associated: Error feedback SHOULD be programmatically-associated with the appropriate element. Best Practice  
Meaningful Error Message: Error feedback MUST clearly and accurately describe the error and/or how to fix the error. Best Practice  
Visible Error Message: Error feedback MUST be visible. Required WCAG 3.3.3
Success Messages

Success Confirmation: The web page SHOULD confirm successful submission of data. Possible techniques include the following:

  • a simple JavaScript alert
  • with confirmation text on the web page (it may be appropriate to move the keyboard focus to the error message)
  • with an aria-live or role="alert" announcement
  • with the confirmation message in the page <title> if the submission causes a page reload or a new page load.
 Best Practice  
Accessibility Techniques for Dynamic Content (JavaScript/AJAX)
Topic Technique WCAG AA Requirement
Context Changes Context Changes on focus: The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction.
Context Changes on Input:		 Required WCAG 3.2.2
Finding Added Content Finding Added Content: Silence is bad. When screen reader users activate a feature (link, button, control, etc.), or when an important part of the content changes, they need to hear feedback. One of the basic challenges with dynamic content is to figure out the best way to tell screen reader users about the dynamic changes. Required WCAG 1.3.2
Keyboard Focus Management During Interactions Set Keyboard Focus: The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction. Required WCAG 2.4.3
No Lost Focus: The focus MUST NOT become lost or reset to the top of the page, except when loading or re-loading a page. Required WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination element MUST contain discernible text (either standard text or programmatically-associated text). Required WCAG 1.3.1
Timers Session Timeout:  
Timers with Fixed Deadlines  
Auto Refresh/Reload Page:  
Auto Refresh/Reload Content Items or Sections  
Changes in State Programmatic State Changes: When the state of an element changes (e.g. selected, expanded, inactive), the state MUST be programatically changed via HTML or ARIA attributes, not just visually changed.  
User Input and Feedback Input: See the requirements for Form Input, Labels, and Instructions  
Feedback: See the requirements for Form Validation and Feedback  
User Input Methods

See the requirements for Device-Independent User Input regarding:

  • Mouse
  • Keyboard
  • Touch
  • Voice
 Required multiple
Accessibility Techniques for Custom Controls
Topic Technique WCAG AA Requirement
Name

Name of Interactive UI Elements: Every interactive UI element (e.g. links, buttons, controls for custom widgets, form inputs/elements) MUST have a name, according to the accessible name computation.

Note: The name can come from the native text of the element (e.g. link text, <button> text), a value attribute (e.g. <input type="submit" value="Name goes here">), the aria-label text, the text referred to via the aria-labelledby ID value, or other attributes, such as title (depending on context).		 Required WCAG 4.1.2

Name of Static Semantic Elements: The following semantic elements MUST have an accessible name, according to the accessible name computation:

  • Headings (or elements with role="heading")
  • Images (or elements with role="image")
  • Links (or elements with role="link"), via link text, aria-label (e.g. when the link contains only a background image), or aria-labelledby)
  • Frames, via the title attribute
  • Iframes, via the title attribute
 Required WCAG 4.1.2

Other Semantic Elements Benefitting from a Name: Examples of other semantic elements that SHOULD have an accessible name, according to the accessible name computation include:

  • Landmarks (HTML 5 or ARIA landmarks); Names are especially helpful when there are two of the same type of landmark on the same page, such as two navigation landmarks
  • Tables (via <caption>, aria-label, or aria-labelledby)
 Best Practice  
Role Role Specified: The semantic meaning of elements MUST be communicated via appropriate native HTML element or ARIA role. Required WCAG 4.1.2
HTML versus ARIA Role: When an HTML element exists, the HTML element SHOULD be used instead of the equivalent ARIA role, whenever possible. Best Practice  
Value Static ARIA Properties: Static ARIA properties (e.g. aria-valuemax), MUST be specified. Required WCAG 4.1.2

Static Non-ARIA Properties: Static non-ARIA properties MUST be specified in text (or alternative text).

Note: The static property may be included in the native text of an element, in its label, in associated text (e.g. via aria-describedby), in adjacent text, or in some other way that is available to assistive technologies.

 Required WCAG 4.1.2
Initial State: The initial state of a changeable UI element MUST be programmatically designated (e.g. via ARIA attributes such as aria-expanded="false", aria-selected="true", aria-sort="ascending", etc.) Required WCAG 4.1.2
ARIA State Changes: When the visual and/or functional state of an element changes (e.g. aria-valuenow, aria-pressed, aria-expanded, aria-checked), the ARIA state MUST be change accordingly. Required WCAG 4.1.2 (WCAG 2.0)
WCAG 4.1.3 (WCAG 2.1)

Non-ARIA State Changes: If a state change cannot be communicated via a change in an ARIA attribute, when the state change is the result of a user action or request, the state change MUST be communicated to the user visually AND MUST be communicated to assistive technologies using a technique such as:

  • aria-live announcement
  • ARIA alert (inject text into a pre-existing container with role="alert")
  • Move keyboard focus to the announcement (warning: moving the focus can be disorienting, so should be used with caution)
 Required WCAG 4.1.2 (WCAG 2.0)
WCAG 4.1.3 (WCAG 2.1)
Keyboard Focus Management During Interactions Set Keyboard Focus: The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction. Required WCAG 2.4.3
No Lost Focus: The focus MUST NOT become lost or reset to the top of the page, except when loading or re-loading a page. Required WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination element MUST contain discernible text (either standard text or programmatically-associated text). Required WCAG 1.3.1
Keyboard Conventions See https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard Best Practice  
Instructions Instructions for Custom Widgets: Widgets with non-standard interaction models SHOULD have instructions explaining how to use them. Best Practice  
See also the requirements for Form Input, Labels, and Instructions. Required multiple
Custom Widgets Accordion widgets SHOULD conform to WAI-ARIA Authoring Practices for Accordions. Best Practice  
Alert widgets SHOULD conform to WAI-ARIA Authoring Practices for Alerts. Best Practice  
Alert Dialog widgets SHOULD conform to WAI-ARIA Authoring Practices for Alert Dialogs. Best Practice  
Autocomplete widgets SHOULD conform to WAI-ARIA Authoring Practices for Autocomplete widgets. Best Practice  
Breadcrumb widgets SHOULD conform to WAI-ARIA Authoring Practices for Breadcrumbs. Best Practice  
Button widgets SHOULD conform to WAI-ARIA Authoring Practices for Buttons. Best Practice  
Button (Toggle) SHOULD conform to WAI-ARIA Authoring Practices for Buttons. Best Practice  
Carousel widgets (based on a Tab Panel) SHOULD conform to WAI-ARIA Authoring Practices for Tab Panels. Best Practice  
Checkbox widgets SHOULD conform to WAI-ARIA Authoring Practices for Checkboxes. Best Practice  
Checkbox (Tri-State) widgets SHOULD conform to WAI-ARIA Authoring Practices for Checkboxes. Best Practice  
Combobox widgets SHOULD conform to WAI-ARIA Authoring Practices for Comboboxes. Best Practice  
Dialog (Simple Modal) widgets SHOULD conform to WAI-ARIA Authoring Practices for Modal Dialogs. Best Practice  
Dialog (Simple Alert Modal) widgets SHOULD conform to WAI-ARIA Authoring Practices for Modal Dialogs. Best Practice  
Dialog (Message Modal) widgets SHOULD conform to WAI-ARIA Authoring Practices for Modal Dialogs. Best Practice  
Dialog (Message Alert Modal) widgets SHOULD conform to WAI-ARIA Authoring Practices for Modal Dialogs. Best Practice  
Disclosure (Show/Hide or Expand/Collapse) widgets SHOULD conform to WAI-ARIA Authoring Practices for Disclosures. Best Practice  
Disclosure (Based on Details/Summary) widgets SHOULD conform to WAI-ARIA Authoring Practices for Disclosures. Best Practice  
Feed widgets SHOULD conform to WAI-ARIA Authoring Practices for Feeds. Best Practice  
Grid widgets (Interactive Tabular Data and Layout Containers) SHOULD conform to WAI-ARIA Authoring Practices for Grids. Best Practice  
Link widgets SHOULD conform to WAI-ARIA Authoring Practices for Links. Best Practice  
Listbox widgets SHOULD conform to WAI-ARIA Authoring Practices for List Boxes. Best Practice  
Menu widgets SHOULD conform to WAI-ARIA Authoring Practices for Menus. Best Practice  
Menubar widgets SHOULD conform to WAI-ARIA Authoring Practices for Menubars. Best Practice  
Menu Button widgets SHOULD conform to WAI-ARIA Authoring Practices for Menu Buttons. Best Practice  
Navigation (Hierarchical) widgets with Expand/Collapse widgets SHOULD conform to WAI-ARIA Authoring Practices for Disclosures. Best Practice  
Progress Bar (Bounded) widgets SHOULD conform to WAI-ARIA Authoring Practices for Progress Bars. Best Practice  
Progress Bar (Unbounded) widgets SHOULD conform to WAI-ARIA Authoring Practices for Progress Bars. Best Practice  
Radio and Radio Group widgets SHOULD conform to WAI-ARIA Authoring Practices for Radio Groups. Best Practice  
Slider widgets SHOULD conform to WAI-ARIA Authoring Practices for Sliders. Best Practice  
Slider (Multi-Thumb) widgets SHOULD conform to WAI-ARIA Authoring Practices for Multi-Thumb Sliders. Best Practice  
Spinbutton widgets SHOULD conform to WAI-ARIA Authoring Practices for Spinbuttons. Best Practice  
Tab Panel widgets SHOULD conform to WAI-ARIA Authoring Practices for Tab Panels. Best Practice  
Table widgets SHOULD conform to WAI-ARIA Authoring Practices for Tables. Best Practice  
Table (Responsive, Collapsible) widgets SHOULD maintain data relationships through table structure, list hierarchy, and/or headings. Best Practice  
Table (Sortable) widgets SHOULD be constructed of a standard HTML table, if possible, and make full use of ARIA sort attributes. Best Practice  
Toolbar widgets SHOULD conform to WAI-ARIA Authoring Practices for Toolbars. Best Practice  
Tooltip widgets SHOULD conform to WAI-ARIA Authoring Practices for Tooltips. Best Practice  
Tooltip Dialog widgets SHOULD conform to WAI-ARIA Authoring Practices for Dialogs. Best Practice  
Tree View widgets SHOULD conform to WAI-ARIA Authoring Practices for Tree Views. Best Practice  
Window Splitter widgets SHOULD conform to WAI-ARIA Authoring Practices for Window Splitters. Best Practice  
Accessibility Techniques for CAPTCHA
Topic Technique WCAG AA Requirement
Text Alternatives Text alternative describing the purpose: If the CAPTCHA is not text-based (e.g. image or audio), a text alternative MUST communicate the purpose of the CAPTCHA, so that the user knows that this task must be completed before proceeding to the next step.
Note 1: Ideally the alternative text would allow non-visual users to complete the task, but at a minimum it should inform users of the purpose of the CAPTCHA.
Note 2: If there is an alternative CAPTCHA (e.g. in text elsewhere on the page, or in audio), the user SHOULD be notified that the alternative exists, by mentioning it either in the alternative text for the original CAPTCHA, or in the surrounding text.		 Required WCAG 1.1.1
Text-based CAPTCHA: A method SHOULD be available in a text-based format (either as the main CAPTCHA or as an alternative) that can be converted by a screen reader to braille output.
Note: Although WCAG does not require a text-based CAPTCHA, deafblind users require a text-based method, because neither visual nor audio methods will be sufficient.		 Best Practice  
Sensory Alternatives Sensory alternative: If a non-visual user cannot pass the original CAPTCHA, an alternative method MUST be provided in another sensory modality (e.g. audio). Required WCAG 1.1.1
Keyboard Accessibility User input controls in a CAPTCHA (or in an alternative representation) must meet all the keyboard functionality requirements. Required Multiple
Dynamic Content Any dynamic content in a CAPTCHA (or in an alternative method) must meet all the dynamic content (JavaScript, AJAX) requirements. Required Multiple
Custom Widgets Any custom widgets in a CAPTCHA (or in an alternative method) must meet all the custom widgets (JavaScript, ARIA) requirements. Required Multiple
Color and Contrast Any visual elements in a CAPTCHA (or in an alternative method) must meet all the color and contrast requirements. Required Multiple