Accessible Components in Practice: Buttons, Forms, Dialogs and Menus

Start with native elements

Native HTML elements come with keyboard support, focus handling and meaning for assistive technology built in. A button can be focused, activated with Enter or Space and is announced as a button. A div styled to look like a button has none of that unless you rebuild it. The first accessibility rule for components is therefore to use button for actions, a with href for navigation, and real form controls for input. ARIA attributes are for filling gaps that HTML cannot express, not for replacing native elements.

Buttons and links

• Use a link when the action navigates to a URL and a button when it does something on the page.
• Give icon-only buttons an accessible name, for example with aria-label or visually hidden text.
• Keep a visible focus style; style :focus-visible rather than removing outlines.
• Use aria-pressed for toggle buttons and aria-expanded for buttons that show and hide content.
• Make touch targets large enough to tap comfortably, around 24 by 24 CSS pixels at minimum and larger where possible.

Forms

Every input needs a programmatically associated label, usually a label element with a for attribute matching the input's id. Placeholder text is not a label: it disappears while typing and often has poor contrast. Group related controls, such as radio buttons, with fieldset and legend.

When validation fails, show errors next to the relevant field in text, connect them with aria-describedby and move focus to an error summary or the first invalid field on submit. Do not rely on colour alone to indicate errors, and keep the user's input so they can correct it rather than retype it.

Dialogs

A modal dialog must take focus when it opens, keep focus inside while open, close with the Escape key and return focus to the element that opened it. It needs an accessible name from its heading. The native dialog element opened with showModal() provides much of this behaviour, including making the rest of the page inert. If you build a custom dialog, you must implement each part yourself and test it with a screen reader.

Menus and disclosure navigation

Many site navigation menus are better built as disclosure widgets than as ARIA menus. A disclosure is a button with aria-expanded that shows or hides a list of ordinary links, and keyboard users move through it with Tab. ARIA menu roles imply application-style arrow-key navigation, which users expect only in genuine application menus. Choosing the simpler pattern usually produces a more predictable experience.

Content and zoom

• Use headings in a logical order so screen-reader users can navigate by heading.
• Provide alternative text that describes the purpose of informative images, and empty alt for decorative ones.
• Ensure text contrast meets WCAG AA: 4.5:1 for normal text and 3:1 for large text.
• Check that pages work at 200% zoom and on narrow screens without horizontal scrolling for text.
• Respect prefers-reduced-motion for animations.

Test like a user

Automated tools catch some issues, such as missing labels and low contrast, but not whether an interaction makes sense. Complete key tasks using only the keyboard, then with a screen reader such as NVDA, VoiceOver or TalkBack, and at high zoom. Fix the barriers that stop a task first.

Checklist

• Native elements are used for actions, links and inputs
• Every control has an accessible name and visible focus
• Form errors are textual, associated and focusable
• Dialogs manage, trap and restore focus
• Navigation uses simple disclosure patterns
• Key tasks are tested with keyboard, screen reader and zoom