PRACTICAL GUIDE
Implementing accessibility
Connect design and content decisions to HTML implementation, then verify and maintain the result.
START WITH THE TASK
Turn a requirement into a concrete decision.
Choose one component and write down what the person needs to do. For an enquiry form, that includes understanding the fields, entering information, identifying errors, and finding the outcome.
Agree on expected behaviour before implementation. Record the visible label, keyboard behaviour, instructions, feedback, and any state changes. Connect those decisions to the relevant accessibility requirements.
Use this guide’s small HTML example as a starting pattern. It demonstrates a field label and a native button, not a complete form or validation system.
Example acceptance notes
- The email field has a persistent visible label that is associated with it in code.
- Keyboard users can reach the field and button in a logical sequence.
- A rejected entry has a clear explanation and a way to correct it.
- The result can be understood through the relevant visual and assistive-technology checks.
USE MEANINGFUL STRUCTURE
Start with native HTML.
The label’s for value matches the input’s id. That gives the field an associated visible label. A native button provides button semantics and standard keyboard activation; use a link when the purpose is navigation.
Place these elements in an appropriate form and implement the submission and feedback behaviour separately. Adding an ARIA label is not a substitute for making an unclear visible label useful.
Illustrative HTML
<label for="enquiry-email">Email address</label>
<input id="enquiry-email" name="email" type="email"
autocomplete="email">
<button type="submit">Send enquiry</button>Check the pattern in context
- Activate the visible field label and check that it targets the input.
- Tab through the form and check visible focus.
- With a screen reader, check the field’s name and the button’s purpose.
- Submit a controlled test case and inspect errors and confirmation.
- Check at enlarged text and narrow widths before reusing the component.
MAKE THE CHANGE REUSABLE
Build the decision into the team’s work.
Give content a logical heading hierarchy and use labels and links that explain their purpose. Avoid choosing heading levels only for their visual size. Shared components should carry the agreed behaviour into every place they are used.
Example: after fixing an enquiry-field label, inspect other forms using the same component. Record the component change and the manual checks needed when it is updated. A component fix still needs checking in the page where it appears.
Keep the design notes, implementation, and review evidence connected. Automated checks can support regression testing, while keyboard, screen-reader, visual, and task-based reviews cover different aspects of the experience.
Official guidance
KEEP LEARNING
Continue with another guide.
Build on this topic, browse all resources, or talk with us about your work.