Skip to main content

Interaction

Find interaction requirements for testing mobile experiences.

Layout (INT-1)

Content reflow (INT-1-1)

Content must support reflow without requiring two-dimensional scrolling (except when the content requires a two-dimensional layout for meaning like tables, maps, or diagrams)

How to test

Tool: Visual inspection

  1. Increase display zoom using OS level settings:
    • iOS: Settings > Display & Brightness > Display Zoom > Larger Text.
    • Android: Settings > Display > Screen Zoom, set to maximum.
  2. Confirm that all content is available without requiring two-dimensional scrolling.

Test outcomes

  • Pass: There is not a loss of information, meaning, or functionality and only one scroll dimension is required.

  • Fail: There is a loss of information, meaning, or functionality OR vertical and horizontal scrolling are required to view the content.

  • NA: Content is any of the following:

    • Data tables
    • Photos
    • Maps
    • Charts
    • Games
    • UI with toolbars

Related WCAG criteria

WCAG 2.2 AA - 1.4.10 Reflow

Consistent help (INT-1-2)

If a view includes the help options listed below, they are in the same location on similar views:

  • Human contact details
  • Human contact mechanism
  • Self-help option
  • A fully automated contact mechanism

How to test

Tool: Visual inspection

  1. Locate if any of the listed help options in exist in the view:
    • Human contact details;
    • Human contact mechanism;
    • Self-help option;
    • A fully automated contact mechanism.
  2. Determine if the help is in the same location across similar views.

Test outcomes

  • Pass: Help across similar views is in the same location.

  • Fail: Help across similar views is not in the same location.

  • NA: No help options exist in the view.

Related WCAG criteria

WCAG 2.2 A - 3.2.6 Consistent Help

Forms (INT-2)

Group fields and controls (INT-2-1)

When controls are related/grouped together this grouping should be clearly presented to assistive technology.

How to test

Tool: VoiceOver (iOS), TalkBack (Android)

  1. Locate any input fields and interactive controls that are related and share a grouping relationship (note: this may be apparent visually or it may just be implied).
  2. Confirm that the grouping relationship is communicated by the screen reader.

Test outcomes

  • Pass: All control and input field grouping is communicated by the screen reader.

  • Fail: One or more control/input field grouping is not communicated by the screen reader.

  • NA: No control/input field groupings are present.

Related WCAG criteria

WCAG 2.2 A - 1.3.1 Info and Relationships

Required fields (INT-2-2)

Required fields must be noted and communicated visually through more than color alone, and communicated to assistive technology

How to test

Tool: Visual inspection and screen reader

  1. Locate any required fields or controls.
  2. Confirm that there is a visual indication of each field that is required that is not presented through color alone.
  3. Confirm that the required fields are communicated programmatically to screen reader users.

Test outcomes

  • Pass: All required fields are noted visually through more than color alone and communicated to assistive technology.

  • Fail: One or more required fields are not noted visually through more than color alone or communicated to assistive technology.

  • NA: Required fields are not present.

Related WCAG criteria

WCAG 2.2 A - 1.3.1 Info and Relationships

Check for errors (INT-2-3)

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.

How to test

Tool: Visual inspection

  1. Identify any inputs that have automatic validation.
  2. For each input, verify that errors are described in text.

Test outcomes

  • Pass: Errors are identified and the errors are described to the user in text.

  • Fail: Errors are identified but the errors are not described to the user in text.

  • NA: There are no inputs with automatic validation.

Related WCAG criteria

WCAG 2.2 A - 3.3.1 Error Identification

Highlight in-line errors visually (INT-2-4)

When an error is detected using in-line validation, highlight the field (for example: with a bold red border, error icon with proper alternative text) and place error helper text near it.

How to test

Tool: Visual inspection

  1. Identify any inputs that have automatic validation.
  2. Confirm that when an error is detected using in-line validation, the field is highlighted.

Test outcomes

  • Pass: When an error is detected using in-line validation, the visual UI highlights the field and places error helper text near it.

  • Fail: For one or more client-side validated forms when an error is detected using client side validation, the visual UI does not highlight the field or place error helper text near it.

  • NA: No forms are present.

Related WCAG criteria

WCAG 2.2 A - 3.3.1 Error Identification

Summary before submit (INT-2-5)

If user input is collected across multiple pages in order to execute a transaction of some kind the user must be presented with a summary of the input before submitting. The user must be able to change input prior to final submission after reviewing.

How to test

Tool: Visual inspection

  1. Identify any workflows which gather input from the user and conclude with a submit action (for example: sign up, checkout, transactions, or capture of personal information).
  2. Confirm that there is a step available to the user for reviewing the information prior to the final submit.
  3. Confirm that the user can easily make corrections or changes to the information prior to submit.

Test outcomes

  • Pass: A summary of user input is provided prior to final submit AND the user can edit or make corrections as needed.

  • Fail: A summary of user input is not provided prior to final submit OR the user cannot edit or make corrections as needed.

  • NA: User input is not collected across pages to execute a transaction.

Related WCAG criteria

WCAG 2.2 AA - 3.3.4 Error Prevention (Legal, Financial, Data)

Error suggestion (INT-2-6)

When errors are detected, suggestions are provided to correct them, unless it would jeopardize the security or purpose of the content.

How to test

Tool: Visual inspection

  1. Locate any errors that can appear.
  2. Trigger each error.
  3. Confirm that, when possible, an error message describes how to correct the error (eg “username field is required” or “phone number must contain 10 digits”).

Test outcomes

  • Pass: Suggestions to fix errors are present.

  • Fail: One or more errors exist but users are not informed how to fix the errors.

  • NA: No errors exist.

Related WCAG criteria

WCAG 2.2 AA - 3.3.3 Error Suggestion

Redundant entry (INT-2-7)

If a view is contained within a process then information provided on the first step of the process is auto-filled in the next steps unless the information is required for security.

How to test

Tool: Visual inspection

  1. Inspect the view to determine if it is a step in a process.
  2. If information is provided in an earlier step in this process, confirm that this information is auto-filled in later steps.

Test outcomes

  • Pass: Information provided during the process will autofill if later steps require the same information.

  • Fail: Fields do not autofill when the same information has been provided on previous steps.

  • NA: The view does not contain any process-based functionality or information reentry is essential or required for security.

Related WCAG criteria

WCAG 2.2 A - 3.3.7 Redundant Entry

Widgets and controls (INT-3)

Gestures (INT-3-1)

Widgets and controls can be operated via a single pointer with a gesture that does not require a specific path, unless a multi-pointer or path-based gesture is essential to the function of the control.

How to test

Tool: Visual inspection

  1. Identify any controls that are operated via a multi-point OR path-based interaction in the application.
  2. Confirm that the same actions can be performed through a single pointer method that does not require a specific path.

Test outcomes

  • Pass: All controls that are operated via a multi-point OR path-based interaction can also be operated through a single pointer method that does not require a specific path.

  • Fail: There are controls that require multi-pointer interaction OR they require a specific path-based gesture where it is not essential to the function of the control.

  • NA: No custom gesture control is present OR the multi-pointer or path-based gesture is essential to the function of the control.

Related WCAG criteria

WCAG 2.2 A - 2.5.1 Pointer Gestures

Name (INT-3-2)

All interactive elements must have a programmatic name accessible to assistive technology

How to test

Tool: VoiceOver (iOS), TalkBack (Android)

  1. Review each interactive element with a screen reader.
  2. For each interactive element, verify the screen reader announces the name of the element.

Test outcomes

  • Pass: All interactive elements have a name announced by the screen reader.

  • Fail: One or more interactive elements do not have a name announced by the screen reader.

Related WCAG criteria

WCAG 2.2 A - 4.1.2 Name, Role, Value

Role (INT-3-3)

All elements with semantic meaning have a valid, accurate programmatic role accessible to assistive technology

How to test

Tool: VoiceOver (iOS), TalkBack (Android)

  1. Locate all elements in the view with semantic meaning. (for example: headings, buttons and links, dialogs, etc…).
  2. For each element with semantic meaning, verify the screen reader announces the role of the element.
  3. Verify that the role announced for the element is valid and matches the semantic meaning of the element (for example: a link announces a link role, a button announces a button role, etc.).

Test outcomes

  • Pass: All elements with semantic meaning have a role announced by the screen reader that matches the semantic meaning of the element.

  • Fail: One or more semantic elements do not have a role announced by the screen reader or the role announced does not match the semantic meaning of the element.

Related WCAG criteria

WCAG 2.2 A - 4.1.2 Name, Role, Value

Value, states, properties (INT-3-4)

States, properties, and values of elements are programmatically available to assistive technology, Any changes to these items are also communicated to assistive technology.

How to test

Tool: VoiceOver (iOS), TalkBack (Android)

  1. Locate all elements in the view which have states, properties, and/or values associated (for example: pressed/invalid state, an error message property on an invalid input, a user-input text string value in a “name” text field, etc…).
  2. For each identified state, property, or value, confirm that the screen reader announces it when interacting with the associated element. Note: If a state, property, or value has changed, the screen reader can determine the change.

Test outcomes

  • Pass: All states, properties, and values are announced by the screen reader when interacting with the associated element.

  • Fail: One or more states, properties, or values are not announced to the screen reader when interacting with the associated element.

  • NA: No elements with states, properties, or values are present.

Related WCAG criteria

WCAG 2.2 A - 4.1.2 Name, Role, Value

Name consistently (INT-3-5)

UI controls with the same purpose need to be identified with the same label for consistency

How to test

Tool: Visual inspection and screen reader

  1. Determine whether there are any duplicate UI controls with the same purpose.
  2. Confirm that they are consistently identified with the same label visually and to screen reader users.

Test outcomes

  • Pass: All UI controls with the same purpose are consistently identified with the same label visually and to screen reader users.

  • Fail: One or more UI controls with the same purpose are not consistently identified with the same label visually and to screen reader users.

  • NA: No duplicate UI controls with the same purpose are present.

Related WCAG criteria

3.2.4 Consistent Identification

On focus (INT-3-6)

Changes of context do not occur when focus (keyboard, screen reader, switch) moves to controls

How to test

Tool: Keyboard and screen reader

  1. Place focus (keyboard, screen reader) on each interactive control and input field.
  2. Interact with each control and input field.
  3. Confirm that no changes of context result from moving focus to a control.

Test outcomes

  • Pass: No changes of context result from an on focus.

  • Fail: A change of context results from an on focus.

Related WCAG criteria

WCAG 2.2 A - 3.2.1 On Focus

On input (INT-3-7)

Changing the value of any interactive element does not automatically cause a change of context unless the user has been advised beforehand.

How to test

Tool: Visual inspection

  1. Locate any elements in the view that has a value that can be updated (for example: checkboxes, radio buttons, selects, etc.).
  2. Change the value for each element.
  3. Confirm that unexpected changes do not occur.

Test outcomes

  • Pass: No changes of context occur on value change or the user is advised beforehand.

  • Fail: One or more changes of context occur on value change and the user is not advised beforehand.

  • NA: No interactive elements can accept a value change.

Related WCAG criteria

WCAG 2.2 A - 3.2.2 On Input

Same relative order (INT-3-8)

Components, like links, buttons, or contact forms, that appear on multiple views must appear in the same relative order on every view.

How to test

Tool: Visual inspection

  1. Perform a visual inspection of the view looking for navigation components.
  2. Confirm that components (links, buttons, contact forms, etc.) that appear on multiple views appear in the same relative order on every view.

Test outcomes

  • Pass: Components that appear on multiple views appear in the same relative order on every view.

  • Fail: One or more component that appears on multiple views does not appear in the same relative order on every view.

  • NA: No component appears on multiple views.

Related WCAG criteria

WCAG 2.2 AA - 3.2.3 Consistent Navigation

Touch cancellation (INT-3-9)

Actions completed with a touch input MUST NOT use the down-event to execute any part of the function. -OR- Make sure there is a way for the user to abort or undo the action. -OR- Allow the up-event to reverse any outcome of the preceding down-event

How to test

Tool: Visual inspection

Confirm that there are no actions which are completed using the down-event from touch input OR that there is a way for the user to abort or undo the action OR that the up-event allows the user to reverse any outcome of the preceding down-event.

Test outcomes

  • Pass: No actions are completed using the down event OR there is a way to abort or undo an action completed on the down-event OR the up-event allows the reversal of the preceding down-event.

  • Fail: Actions are completed using the down event AND there is not a way to abort or undo the action AND the up-event does not allow reversal of the preceding down-event.

Related WCAG criteria

WCAG 2.2 A - 2.5.2 Pointer Cancellation

Dragging movements (INT-3-10)

An action that relies on dragging of content can also be achieved by a single pointer without dragging unless dragging is essential to the activity.

Example of single pointer Pass: A quiz relies on users tapping and dragging information into the correct bucket. Users are also able to tap once to select an option, then tap on the correct bucket. Example of essential activity: A medical app requires tapping and dragging an object to a target to accurately measure the user’s precision.

How to test

Tool: Visual inspection

  1. Inspect the view to determine whether any functionality requires a dragging movement to access content.
  2. For any dragging content, confirm that it can be used with a single pointer without dragging.

Test outcomes

  • Pass: All drag functionality can also be performed with a single pointer OR the dragging movement is essential.

  • Fail: Drag functionality cannot be completed with a single pointer.

  • NA: The view does not contain drag functionality.

Related WCAG criteria

WCAG 2.2 AA - 2.5.7 Dragging Movements

Notifications and alerts (INT-4)

Notifications, status messages, etc. (INT-4-1)

When the app sends the user info in a status update or notification it needs to be announced to screen readers without user placing focus there

How to test

Tool: VoiceOver (iOS) TalkBack (Android)

  1. Interact with all notification and status message content using a screen reader.
  2. When the app sends the user info in a status update or notification, confirm that it is announced to the screen reader without the user placing focus there and announced correctly.

Test outcomes

  • Pass: All notifications or status messages are shown to the screen reader and announced correctly.

  • Fail: One or more notifications or status messages is not shown to the screen reader and announced correctly.

  • NA: No notifications or status messages occur.

Related WCAG criteria

WCAG 2.2 AA - 4.1.3 Status Messages

Keyboard compatibility (INT-5)

Focus order (INT-5-1)

When someone navigates using a keyboard or other sequential nav device the focus order is logical

How to test

Tool: Keyboard

  1. Use a keyboard to control the mobile device.
  2. Confirm that when someone navigates using a keyboard or other sequential nav device the order they are taken through the UI preserves meaning and operability.

Test outcomes

  • Pass: Focus order is logical.

  • Fail: Focus order is not logical.

Related WCAG criteria

WCAG 2.2 A - 2.4.3 Focus Order

Visible keyboard focus (INT-5-2)

When a keyboard or any other sequential navigation device is used there is a visible indication of focus that is always on the correct element

How to test

Tool: Screen reader AND keyboard

  1. Use a keyboard to control the mobile device.
  2. Confirm that when a keyboard is used, there is a visible indication of focus that is always on the correct element.

Test outcomes

  • Pass: Focus is always visible and in the correct place.

  • Fail: Focus is not always visible or occurs in the wrong location.

Related WCAG criteria

WCAG 2.2 AA - 2.4.7 Focus Visible

Keyboard support (INT-5-3)

All functionality and content must be available to users via keyboard only, without requiring specific timing of keystrokes

How to test

Tool: Keyboard

  1. Use a bluetooth keyboard to control the mobile device.
  2. Confirm that everything in the app can be performed with a keyboard alone (without the touch screen).

Test outcomes

  • Pass: All features and functionality of the app are keyboard only compatible.

  • Fail: One or more features or functionality is not keyboard only compatible.

Related WCAG criteria

WCAG 2.2 A - 2.1.1 Keyboard

No keyboard trap (INT-5-4)

Keyboard focus must not become stuck when navigating through content.

How to test

Tool: Keyboard

Run through all use cases using keyboard and confirm that when focus is moved to an interactive element, that focus can also be moved away from the element.

Test outcomes

  • Pass: Focus can move through the content without getting stuck.

  • Fail: Focus cannot move through the content without getting stuck.

Related WCAG criteria

WCAG 2.2 A - 2.1.2 No Keyboard Trap

Focus not obscured (INT-5-5)

When a focusable element has keyboard focus, the element is at least partially visible.

How to test

Tool: Keyboard

  1. Tab through everything in the view.
  2. For each focusable element, when it has focus, confirm at least part of the element is visible (not fully obscured by other content or off the screen). Note: If content can be repositioned by the user, only test the initial position.

Test outcomes

  • Pass: Focusable elements are at least partially visible when focused.

  • Fail: One or more focusable elements are fully obscured when focused.

Related WCAG criteria

WCAG 2.2 AA - 2.4.11 Focus Not Obscured

Single character keyboard shortcuts (INT-5-6)

If a single character shortcut is used then users must have the option to either turn it off or remap it to one or more non-printable keyboard characters. -or- Make sure the single character shortcut is only active when the component it affects has focus.

How to test

Tool: Keyboard

Confirm that where a single character shortcut is used that users have the option to either turn it off or remap it to one or more non-printable keyboard characters or make sure the single character shortcut is only active when the component it affects has focus.

Test outcomes

  • Pass: For all single character shortcuts, users have the option to either turn off or remap it to one or more non-printable keyboard characters or the single character shortcut is only active when the component it affects has focus.

  • Fail: For all single character shortcuts, users do not have the option to either turn off or remap it to one or more non-printable keyboard characters and the single character shortcut is active at all times.

  • NA: No single character shortcuts are present.

Related WCAG criteria

WCAG 2.2 A - 2.1.4 Character Key Shortcuts

These materials are intended for illustrative purposes only. They are provided AS-IS and should not be relied upon for marketing, legal, tax, financial, regulatory or other advice. Any links to third party sites are for your information only and do not constitute endorsement by or affiliation with Visa. Visa has no insight into and/or control over third party content and code and disclaims all liability for any such components.

Copyright © 2026 Visa. All rights reserved.