Web Accessibility: Semantics, Focus and Verifiable Tasks
Accessibility means that people with varied abilities and tools can perceive, understand and operate a product.
- Author
- absequ
- Published
- Updated
- Category
- UI and UX
- accessibility
- ui and ux
- practical guide
Accessibility means that people with varied abilities and tools can perceive, understand and operate a product. For a website, this includes semantic structure, keyboard interaction, readable presentation and useful feedback. It is not achieved by adding a few ARIA attributes after the visual design is finished.
On this page
The mental model
Start with native elements and a logical document order. Headings describe the structure, landmarks identify major regions, and labels connect inputs with their purpose. A visual grid can position content in columns, but keyboard and screen-reader order still follows the document. Avoid visual arrangements that make these orders contradict each other.
WCAG provides testable success criteria, while WAI guidance and interaction patterns help explain implementation. Automated checks can detect some failures, such as missing accessible names, but cannot determine whether a workflow is understandable or whether alternative text communicates the right information. Manual task testing remains necessary.
A practical workflow
Give each page a clear primary heading and one appropriate main landmark. Name controls by their actual action. Maintain visible focus and ensure an expanded panel or modal communicates its state. When a modal closes, focus should return to a sensible trigger rather than disappearing into the document.
Test typography and layout with enlarged text, narrow windows and both themes. Avoid fixed heights for long text and prevent content clipping. Color may reinforce meaning, but error and success states also need text or another perceivable cue. Respect reduced-motion preferences and avoid making animation essential to understanding content.
Worked example
<button type="button" aria-expanded="false" aria-controls="details">
Show delivery details
</button>
<section id="details" hidden>
<h2>Delivery details</h2>
<p>The confirmation explains the next step.</p>
</section>
<!-- The interaction must update both hidden and aria-expanded together. -->The relationship between the trigger and panel is explicit, but markup alone does not implement the interaction. In a real component, update state consistently and verify keyboard activation. Do not add role=button to the native button or create nested dialog landmarks inside a dialog already supplied by a component library.
For images, decide whether each asset communicates information or is decorative. Meaningful images need an alternative appropriate to their context. Audio and video require suitable alternatives such as transcripts or captions; a file being playable does not mean that its information is accessible to everyone.
Failure modes and security
Avoid claiming complete accessibility or a conformance level based on a single scan. Document which pages, states, browsers and assistive technologies were checked. A passing color contrast calculation does not prove that content order, error recovery or focus behavior is correct.
Do not put private user data into screenshots or recordings collected during accessibility testing. Include authenticated and error states using synthetic data. Preserve accessibility when dependencies or shared layouts change: a global header or drawer regression can affect many pages at once.
Practice and verification
Complete an enquiry flow using only a keyboard, then repeat it with enlarged text at a narrow width. Check the heading outline, input labels, validation messages and focus restoration. Inspect the accessibility tree as well as visible pixels. Record concrete failures and add focused regression coverage. Use WCAG criteria to describe the issue precisely, while explaining the practical barrier a user encounters.