Accessible websites provide perceivable content, operable interactions, understandable behavior and robust implementation. SMEs should combine automated checks with keyboard, screen-reader and real-user testing on priority journeys.
Key takeaways
- Accessibility begins in content and design, not after development.
- Automated scanners cannot prove accessibility.
- Test priority journeys with a keyboard and assistive technology.
- Make accessibility part of component acceptance criteria.
Who this is for: SME owners, designers, content editors and developers improving a business website.
Content and structure
Semantic structure helps people navigate and understand content across visual and assistive experiences.
- One descriptive H1 and logical heading levels
- Meaningful link and button labels
- Plain language and clear instructions
- Useful page titles
- Table headers for data
- Language declared correctly
Keyboard and interaction
Complete every priority journey without a mouse.
- 1Navigate in a logical order using Tab and Shift+Tab.
- 2Confirm focus is always visible.
- 3Open and close menus, dialogs and accordions from the keyboard.
- 4Escape overlays without losing context.
- 5Avoid keyboard traps.
- 6Test errors and success states in forms.
Images, forms and media
Alternatives should communicate the same purpose, not mechanically describe pixels.
| Element | Requirement | Check |
|---|---|---|
| Meaningful image | Contextual alt text | Would the page still make sense? |
| Decorative image | Empty alt | Screen reader skips it |
| Form | Persistent label and clear error | Error is associated with field |
| Video | Captions/transcript as appropriate | Information is available without audio |
| Icon control | Accessible name | Purpose announced clearly |
Responsive and visual checks
Test zoom, text spacing, contrast, orientation and reflow. Content and actions should remain available without horizontal page scrolling at supported narrow widths.
<Image
src={auditChart}
alt="Bar chart showing form completion improved after labels were added"
width={1200}
height={675}
/>
Testing strategy
Use automated tools to find common issues, manual keyboard and screen-reader tests for priority journeys, and periodic testing with disabled users where possible.
How to use this guide with your team
Accessibility work improves when it is part of everyday content, design and development decisions. Retrofitting isolated errors after launch is more expensive and leaves the underlying component system unchanged.
Give non-technical editors clear rules for headings, links, images, tables and video. Many barriers are introduced during routine publishing rather than initial development.
Document known limitations honestly, assign owners and test priority journeys with people and assistive technology whenever possible.
Practical next steps
Use the following actions as a short working session. Record decisions, owners and unresolved questions so the article becomes an implementation aid rather than passive reading.
- 1Include accessibility in component acceptance criteria.
- 2Train editors on accessible content practices.
- 3Test priority journeys without a mouse.
- 4Combine automated and manual testing.
- 5Track limitations and remediation ownership.
Frequently asked questions
Does passing an automated test mean the site is accessible?
No. Automated tools detect only some issue types. Manual and user testing are necessary.
Should every image have descriptive alt text?
Meaningful images need useful alternatives. Decorative images should generally use empty alt text so they do not create noise.
Sources and further reading
Last reviewed: September 1, 2026
