Access

Use a button for an action and a link with a destination for navigation. Their built-in semantics and behaviour reduce the amount of keyboard and assistive-technology support you need to recreate.

Structure the document with meaningful headings, lists and landmarks. Give form fields persistent labels and associate helpful instructions with their controls. Custom widgets sometimes need additional behaviour and ARIA, but an accessible name alone does not make a widget complete. Check its keyboard interaction and state announcements too.

Add a clear label, pattern, icon or other cue that preserves the meaning.

For forms, explain an error near the relevant field and connect the message to the control. For charts, use direct labels or distinguishable marks. For text links, an underline is a clear starting point. A greyscale or colour-vision simulation can reveal problems, but it does not replace checking the complete experience.

Test the complete task, including opening menus, choosing values, submitting forms and recovering from errors. Keyboard patterns differ by control: Tab moves between controls, while some widgets use arrow keys within them.

Keep focus visible and avoid obscuring the active control with fixed content. A modal dialog needs managed focus while it is open and an appropriate return point when it closes. Provide alternatives to interactions that require dragging, and test custom widgets rather than assuming their appearance proves their behaviour.

Meaningful labels, understandable reading order and successful task completion need human evaluation as well.

Test representative flows with the relevant assistive technologies and include people who use them. Listen to the names and states of controls, check error recovery and review image descriptions in context. Record the task, environment and observed problem so fixes can be verified. There is no single reliable percentage of issues that every tool will catch.