Visa Accessibility - Custom Controls (INT-010)

VGAR Interaction Requirements

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.

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

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

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.