VGAR Interaction Requirements
Interaction
- Accessible Forms (INT-001)
- Error Messaging (INT-002)
- System Messages (INT-003)
- Modal Windows (INT-004)
- Onchange / Onfocus (INT-005)
- Buttons and Links (INT-006)
- Control Moving Content (INT-007)
- No Blinking/Flashing (INT-008)
- Give Users Time (INT-009)
- Custom Controls (INT-010)
- Diverse User Needs and Preferences (INT-011)
Custom Controls (INT-WEB-010)
Make sure all controls have a programmatically determinable name, role, and value
Browsers and assistive technologies can present issues when rendering custom controls. If custom controls are used, they MUST all be named and labelled appropriately using ARIA.
Custom controls must also behave the same way a corresponding native control does by being announced the same way by a screen reader and accepting the same keyboard interaction.
If a custom control requires custom keyboard interaction then instructions must be provided to clearly communicate keyboard commands to the user.
Requirements
Name Custom Controls (INT-WEB-010-01)
If a custom control is used in place of a native control, the control's name MUST be made available to assistive technology using a method such as aria-label or aria-labelledby.
<span id="label1">Label 1</span>
<div role="textbox" aria-labelledby="label1"></div>
Emulate Native Controls (INT-WEB-010-02)
When using a custom control in place of a corresponding native control, the custom control MUST fully describe everything a native control would to assistive technology (e.g. name, role, state, value, and properties). For example:
- ARIA Input: role="textbox"
- ARIA Textarea: role="textbox" and aria-multiline="true"
- ARIA Radio: role="radio" and aria-checked="true"
- ARIA Checkbox: role="checkbox" and aria-checked="true"
- ARIA Dropdown: role="listbox" with role="option" and aria-selected="true" and aria-owns="ID1 ID2" where the IDs are in a space delimited list of the IDs of all of the options if those options are not children of the control in the DOM
<!-- Native Radio buttons group -->
<span id="radioGroupLabel">Greatest comic multiverse</span>
<ul tabindex="0" role="radiogroup" aria-labelledby="radioGroupLabel"
aria-activedescendant="radio-1-1">
<li id="radio-1-1" role="radio" aria-checked="true">Marvel</li>
<li id="radio-1-2" role="radio" aria-checked="false">DC</li>
<li id="radio-1-3" role="radio" aria-checked="false">Other</li>
</ul>
<!-- Native Dropdown -->
<div id="listboxLabel">Choose your favorite color</div>
<div role="listbox" tabindex="0" id="listbox1" aria-activedescendant="listbox1-1"
aria-labelledby="listboxLabel">
<div role="option" id="listbox1-1" class="selected">Green</div>
<div role="option" id="listbox1-2">Orange</div>
<div role="option" id="listbox1-3">Red</div>
</div>
Custom Control Interaction (INT-WEB-010-03)
When using a custom control or element in place of a corresponding native control (e.g., select) or element (e.g., table), the user MUST be able to interact using the same keyboard commands they would with the native equivalent unless text instructions are made available to ALL users (i.e. visually and to assistive technologies) preceding the control or element.
Expand / Collapse State (INT-WEB-010-04)
When using an expanding and collapsing UI element, such as an accordion style menu, the current state of each expanding or collapsing element MUST be announced to assistive technology (e.g. Screen Readers).
<button id="button1" class="buttonControl" aria-controls="expandingContent"
aria-expanded="false">
<span class="hidden">Show Content</span>
OR
</span class="visible">Hide Content</span>
</button>
<div id="expandingContent" style="display:none;" tabindex="-1">
<!--some content goes here-->
<!-- NOTE: Toggle CSS and tabindex attribute value based on
the button's aria-expanded value functionality -->
</div>
Test Procedures
Screen reader (INT-WEB-010-01-T)
Interact with each custom control using a screen reader. Confirm that each custom control's name reads properly.
Screen reader (INT-WEB-010-02-T)
Interact with each custom control using a screen reader. Confirm that each control properly emulates the native control, announcing appropriate name, role, state, values, and properties.
Screen reader (INT-WEB-010-03-T)
Interact with each custom control or element using a screen reader. Confirm that interaction is possible using the expected native keyboard commands or that clear instructions are provided to the user before the element.
Screen reader (INT-WEB-010-04-T)
Interact with all expanding and collapsing controls and elements using a screen reader. Confirm that the current state of each expanding or collapsing control is read when the element receives focus and when any user action is taken on the element.
For instance, tabbing to an expanding navigation item should read the element name and the current state (e.g. Expanded or Collapsed). When ENTER is pressed on the element the new state should be read.
Related Content
WCAG Success Criteria
W3C Techniques
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
- G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user settable properties to be directly set, and provide notification of changes
- ARIA4: Using WAI-ARIA role to expose the role of a user interface component
- ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
Common Failures
- F59: Failure of Success Criterion 4.1.2 due to using a script to make div or span a user interface control in HTML without providing a role for the control
- F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
- F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
- F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
- F79: Failure of Success Criterion 4.1.2 die to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
- F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
- F89: Failure of Success Criterion 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link
These materials and steps outlined on this website are provided “AS IS” and are intended for illustrative purposes only. They should not be relied upon for marketing, legal, tax, financial, regulatory or other advice. You are responsible for the legal aspects of any implementation of the concepts illustrated herein. Further, Visa neither makes any warranty or representation as to the completeness or accuracy of this information, nor assumes any liability or responsibility that may result from reliance on such information. You should not act or rely on such content without seeking the advice of a professional. All brand names, logos and/or trademarks are the property of their respective owners, are used for identification purposes only, and do not necessarily imply product endorsement or affiliation with Visa.