Skip to main content

Interface accessibility

An accessible interface lets more people reach the same goal with the input mode and settings that suit them. It is not a special version: it is a robust structure that provides several paths to the same information and action.

Start with semantics​

The browser exposes role, name, state and value to assistive technology. Choosing the right HTML element is therefore a functional decision:

  • <button> triggers an action in the page;
  • <a href> goes to another resource or route;
  • <form> groups a submission;
  • <label> names a field;
  • <nav>, <main>, <header> and <footer> structure regions;
  • <h1> to <h6> describe hierarchy, not arbitrary font size.

A clickable <div> does not automatically gain a button’s keyboard behaviour, focus, role or name. Before adding ARIA and handlers, ask whether a native element already expresses the behaviour.

Name controls​

Every control needs an understandable name outside its visual context. A visible label is the strongest base:

<label for="search">Search for a concept</label>
<input id="search" name="search" type="search"
       aria-describedby="search-help">
<p id="search-help">For example: keyboard focus or architecture.</p>

A placeholder is an example, not a label. For an icon button, keep visible text when the action matters; if the icon stands alone, give it an explicit stable name.

Keyboard and focus​

A keyboard journey must allow people to:

  1. reach every interactive action with Tab;
  2. see where focus is;
  3. activate a button with Enter or Space according to its native behaviour;
  4. open, use and close a component without a mouse;
  5. understand the new focus location after navigation or an error.

Do not remove focus into an insufficient color or send it to the top without a reason. After a form error, focus the first invalid field or the summary that explains the correction. After a modal closes, restore focus to the opener.

Dialogues and menus​

A modal needs a title, dialog role, explicit close action, keyboard close when appropriate, focus contained while open and focus restoration. A menu must be reachable, understandable and closable without hover.

Do not add role="dialog" to a block just because it looks like a card. ARIA describes a contract; an incorrect role can announce a false structure.

Messages and dynamic changes​

Not every visible change is announced. For short feedback, role="status" or aria-live="polite" can announce the result without interrupting reading:

<p id="save-status" role="status" aria-live="polite"></p>

The message should say what happened and what comes next: “Answer saved. Open the next card.” is more useful than “OK”.

Contrast and multiple signals​

Check body text, large text, control borders and focus, help and error copy, icons and non-text graphics, and disabled states in their actual context. A state must not rely on color alone: combine color with text, icon, shape, position or changed content.

Images, audio and video​

  • Informative images need alternative text that conveys the same information.
  • Decorative images use alt="" and do not interrupt reading.
  • Teaching video should provide synchronised captions and a transcript.
  • Important visual information must also be available in text or audio.
  • A chart needs a summary and, when necessary, accessible data.

Responsive, zoom and motion​

Content must remain usable at narrow width, high zoom, larger text and different orientation. Avoid horizontal scrolling for a sentence or field. Respect prefers-reduced-motion; an animation must not be the only proof that an action worked or hide content. Time limits should be extendable or removable when the task allows it.

Test in the most profitable order​

  1. Keyboard: Tab, Shift+Tab, Enter, Space, Escape and arrows where relevant.
  2. Structure: headings, landmarks, names and DOM order.
  3. Zoom and responsive: 320 px, 200% zoom, long copy and a real mobile.
  4. Contrast: text, focus and states in their real appearance.
  5. Assistive technology: at least one screen reader on the main journey.
  6. A person: observe a task; do not conclude from an automated score alone.

Automated tools find many structure and contrast problems, but they cannot always tell whether a message is understandable or the journey matches the person’s intention.

Example: answer saved​

<button type="button" aria-controls="answer" aria-expanded="false">
  Reveal answer
</button>
<p id="answer" hidden>A representation that helps predict a system.</p>
<p role="status" aria-live="polite"></p>

The native button receives focus, aria-expanded can follow visibility, the answer is connected to the control and the status region announces feedback independently of color or motion.

Report an accessibility defect​

Include environment and input mode, exact steps, expected result, observed result, impact on the task, proposed fix and verification method.

At 320 px, after opening the Paths menu with keyboard, Tab leaves the menu and
focus disappears. Expected: focus stays in the menu or closes to its button.
Observed: the person no longer knows where they are. Verify with Tab,
Shift+Tab and Escape in Safari and Firefox.

Checklist​

  • Use native HTML roles when possible.
  • Every field has a visible label, help and connected error.
  • Every action has an understandable name and observable feedback.
  • Focus is visible, ordered and restored after a dialog.
  • Dynamic changes are announced without unnecessary noise.
  • States do not rely on color or hover alone.
  • Images, audio and video have appropriate alternatives.
  • Content works at 320 px, 200% zoom and with long copy.
  • Motion respects the reduced-motion preference.
  • The main journey was checked with keyboard and assistive technology.

Reliable sources​

Apply these checks in the interactive UI/UX path, then revisit UI foundations and CSS rules.