Skip to main content

Accessibility

Learn how to ensure people of diverse abilities can use and interact with our digital products and tools.

Developers can reduce the time spent in manual testing by writing accessible code and using automated tools to check their work. Refer to VGAR to validate and iterate on work throughout the accessibility journey.

Doctype declaration

HTML doctype is a required preamble. Without a valid doctype declaration, browsers tend to use a different rendering mode (such as no-quirks mode, quirks mode, limited-quirks mode, etc.) that is incompatible with some specifications. The doctype is required for legacy reasons. Provide a valid and accurate doctype for all web pages.

Page title

The page element represents the name of a document and identifies the relevance of information contained in a web page. Provide accurate, descriptive, and unique page titles. Use consistent structures for titles across web pages.

VGAR links (internal only)

Language

Identifying the language of a web page helps assistive technologies render text accurately. Provide the attribute specifying the primary language for the contents of an element and for any of that element’s attributes containing text. When content is written in multiple languages, these requirements help assistive technologies present it according to the rules for each language. For instance, screen readers will invoke correct pronunciation rules, visual browsers will display characters and scripts accurately, and media players will show captions correctly.

VGAR links (internal only)

Hidden content

Content that may need to be hidden from sighted users, but not screen readers, must be moved off-screen using CSS.


Wrap this content in a with and . Additionally, set .


Content that may need to be hidden from both sighted and screen reader users should be removed from the DOM using CSS or and .

VGAR links (internal only)

Structure and semantics

Headings are useful for organizing content into contextual sections, establishing content hierarchy, and enabling screen reader users to jump directly to specific content. They need to be defined with valid markup and structured in a proper nesting order to ensure assistive technologies can present them properly.

  • Any text element which conveys information through its visual presentation style must be indicated semantically in code. This includes text styling such as strong, cite, blockquote, sub, and sup, and any other text style which carries secondary meaning.
  • Paragraphs must be marked up as paragraphs.
  • Groups of items, such as a navigation menu or group of tabs, must be marked up as a list.

To ensure that assistive technologies encounter the content in the same order as the logical presentation of the content, it should be structured in a logical order in the HTML code. Do not use CSS to order content. Additionally, any content that is not shown until a specific time or event should be removed from the DOM or parked at the bottom of the DOM.

VGAR links (internal only)

Forms and controls

Ensure that assistive technologies (AT) can gather information on, activate (or set), and update the status of user interface controls in the content.


Form controls that use a label to identify them must have only one label programmatically associated with them.

  • Use , , or for for this label.

Communicate required controls in text either at the beginning of the form or in-line.

  • Use the attribute.

Groups of checkboxes should indicate the required state in text either at the beginning of the form by stating all fields are required, or in the group’s legend instead.

  • Do not use the attribute.

Helper text must be programmatically associated with a form control.

  • Use .

If there are multiple pagination controls on a page, they must have unique labels but still contain the word “Pagination”.

  • Use and .

VGAR links (internal only)

Error identification and suggestions

Controls being validated for errors must include when an error is present.

  • Keyboard focus must be automatically set to the first invalid form control when an error is detected using validation after the user submits the form.
  • When an error is detected using client-side validation, set and add the ID of the error helper text container to the attribute.

When an error is detected using in-line validation, any previous instances must be removed from the DOM and must be set on the container of the .

VGAR links (internal only)

System messages and navigation

System messages must include the and attributes on the message container when added to the DOM. Only add system messages to the DOM after a button press or on page load so that they don’t interrupt the user’s workflow.

At minimum, the page must have a landmark region defined, and , , , , and roles if these content types are present in the page.

  • If a page has multiple landmarks of the same type, such as main navigation and sub-navigation, those regions must have unique names applied using an appropriate naming technique. Do not include the landmark role type in the name.

VGAR links (internal only)

Dialogs

Modal dialog windows must have and on the modal container.

Modal dialogs must have where “dialog-title” would be the modal dialog’s title, such as its main heading.

Modal dialogs should have where “dialog-desc” is helpful information above the first focusable element.

Modal dialogs must have focus set to an appropriate location based on the content presented in the modal dialog.

  • Modal dialog windows must trap focus inside the modal dialog.
  • Dialogs must restore focus to their triggering element when the dialog is closed.

Modal dialogs must allow the user to move through the modal dialog’s focusable elements, “wrapping around” from bottom-to-top and top-to-bottom using the Tab Shift + Tab key and keyboard events.

Modal dialogs must prevent mouse-clicks that occur outside the modal dialog from having any effect on the modal dialog.

If a heading is used in a dialog, the first heading level must be followed by appropriate heading levels.

Dialog windows must have the Esc keyboard event set to close the dialog.

VGAR links (internal only)

Tables

Tables must never be used for layout purposes. Data tables must use proper table headers , and every table header must have the scope attribute set to or , unless it would invalidate a data relationship. If necessary, the header attribute can be used to hard code how headers should be read to screen reader users.

Data tables must be identified for screen readers by including the “title” of the table in its element (the caption may be hidden visually with CSS). If the table has more than 4 table headings, a caption must be included to summarize its layout and functional relationships.

VGAR links (internal only)

Text alternatives

All non-text content must include text alternatives that provide equivalent information, context, and purpose to the user. Non-text content with elements provide the text alternative using the attribute. For non-text content using , use , , or visibly hidden text.

All decorative non-text that provides no contextual value or is already defined by surrounding content must be hidden from screen reader users. For elements, use . For everything else, use .

VGAR links (internal only)

Keyboard interaction

All functionality and content must be available via the keyboard only and should not require the specific timing of keystrokes. If keyboard focus is ever controlled by part of the UI, such as a PDF viewer or modal window, it must allow focus to return to the launching element and browser through keyboard commands only.


Keyboard users should be able to use the Tab key to navigate through the page in the same order as the visual presentation of the content. This tab order should be established by the HTML structure of the page. As the user moves through the page with the keyboard, a highly visible indication of keyboard focus should appear on each element as it receives focus.


Content that remains hidden until it becomes visible on mouse hover must also be shown when it receives keyboard focus and hidden again when focus is removed. Content that appears and disappears in coordination with keyboard focus or pointer hover—such as tooltips, sub-menus, and other non-modal popups—must be dismissable, hoverable, and persistent.

VGAR links (internal only)

Screen reader compatibility

All features and functionality must work with at least one screen reader per platform. Features and functionalities including but not limited to alerts, visual changes on the page, page titles, iframes (used for user interaction, but not system use), landmarks, headings, links etc., must be presented and read accurately by supported screen readers.

VGAR links (internal only)

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 © 2025 Visa. All rights reserved.