Development patterns

Start with native HTML

Browsers already provide keyboard behavior, focus handling, and accessibility information for standard links, buttons, inputs, and headings. Use the element that matches the action: a link navigates, a button performs an action, and a form control accepts input. Native elements reduce the amount of custom behavior your code must maintain.

Build a custom control only when native HTML cannot meet the need. Adding an ARIA role or an accessible name does not add keyboard behavior by itself. A custom component must implement the expected interaction as well as expose its role, name, state, and value.

Make forms understandable and recoverable

Associate every field with a visible label. Place instructions where people can find them before they submit, and identify required fields in text rather than by color alone. Use the appropriate input type and autocomplete values so browsers and assistive technologies can offer useful support.

• Describe the expected format before the field when it matters, such as a date or password requirement.
• When validation fails, identify the field, explain the problem in text, and tell the person how to correct it.
• Keep entered values when possible so a validation error does not force people to start over.
• For a long form, provide a linked error summary and move focus to it after submission when appropriate.
• Announce asynchronous success or failure messages so they are available to assistive technology.

Do not rely on placeholder text as the only label. It can disappear during entry and may be difficult to read. Ensure instructions and error messages are programmatically associated with the relevant field.

Build navigation and menus for real use

Most website navigation is a list of links, so use ordinary links inside a navigation region. The ARIA menu pattern is intended for application-like menus with additional keyboard behavior; applying role="menu" to a regular site navigation without implementing that behavior can make it harder to use.

For a collapsible navigation on small screens, use a button that exposes whether the navigation is expanded and controls the associated region. Keep the button’s accessible name clear, update its expanded state when toggled, and ensure the links can be reached and activated by keyboard.

Make dialogs manage focus

A dialog should have a clear accessible name, and opening it should move keyboard focus into a useful place inside it. While a modal dialog is open, users should not be able to interact with content behind it. Provide a visible close control and support the expected keyboard dismissal behavior where appropriate.

When the dialog closes, return focus to the control that opened it unless the user’s next step makes a different focus target more helpful. Test long dialog content, validation errors, and small screens so the close control and dialog content remain reachable.

Give custom components a complete interaction model

Before implementing a custom tab set, accordion, combobox, or date picker, write down how a person will operate it. Define which keys move focus, which keys activate an option, how the current state is announced, and where focus goes when the component opens or closes. Then implement and test that behavior consistently.

• Expose an accessible name and the correct role for each control.
• Keep the announced state in sync with what is visible, such as expanded, selected, checked, or disabled.
• Use a logical tab sequence and do not create keyboard traps.
• Ensure updates are announced when content changes without a page reload.
• Support the interaction with keyboard alone, not just mouse, touch, or hover.

Prefer a well-supported native control when it provides the needed behavior. A visually polished widget is not complete until its keyboard and assistive technology behavior works too.

Test the implementation, not just the markup

Automated checks can catch some code-level problems, but they cannot confirm that a complete task is understandable and operable. Test the component in the page where it is used: tab through it, activate its controls, trigger errors and success states, resize the viewport, and check it with relevant assistive technology.

Review the Design and Content guide for focus, contrast, labels, and content structure, then use the Testing and Audits guide to plan a broader review. For project-level support, see our accessible web design and development service.