Perceivable
Meaningful colour and contrast, text alternatives for images and icons, captions and transcripts where relevant, and layouts that reflow cleanly at 200% zoom and on small screens.
Accessibility statement
Designed to be usedby everyone.
Accessibility is part of how I design — not a checklist tacked on at the end. This page describes how I approach screen-reader support, keyboard use, WCAG 2.2 alignment, and the automated and manual testing I carry out on the work I produce.
Principles I design to
/ 01Operable
Every interactive element reachable and usable with a keyboard, with a visible focus indicator. No keyboard traps. Motion and auto-playing content are avoided or made pausable.
Understandable
Plain, consistent language. Predictable navigation and state changes. Errors that name the problem and how to fix it, without relying on colour alone.
Robust
Semantic HTML first, ARIA only where semantics fall short. Named, roled and valued components that behave correctly for assistive technology.
/ 02 Screen readers
Designed to be heard, not just seen.
I write markup semantically first — headings in order, lists as lists, buttons as buttons, form fields with real labels. Icons that carry meaning get accessible names; decorative ones are hidden from assistive tech.
Dynamic content is announced through appropriate live regions. Complex widgets follow the ARIA Authoring Practices patterns for dialogs, menus, tabs, disclosures and combobox behaviour, so state and role are always exposed.
JAWS · Windows
Primary Windows screen reader used for regression checks on interactive content.
NVDA · Windows
Open-source Windows screen reader used to sanity-check heading, landmark and form navigation.
VoiceOver · macOS & iOS
Used to verify rotor navigation, form controls and touch gestures on mobile.
/ 03 Keyboard
Everything works from the keyboard.
Every task a mouse can do, the keyboard can do too. I test with Tab, Shift+Tab, Enter, Space and arrow keys, and confirm focus order matches reading order across menus, dialogs and multi-step flows.
Visible focus
Interactive elements always show a clear, high-contrast focus indicator — never removed with outline: none without a replacement.
Logical focus order
Focus follows the visual order of content. Modals trap focus while open and return it to the trigger on close.
Skip links & landmarks
Long templates include a skip-to-content link, and pages use header, nav, main and footer landmarks so keyboard users can jump around.
No keyboard traps
Custom widgets — carousels, media players, drag-and-drop — always offer a keyboard route in and out.
WCAG 2.2 alignment
/ 04I design to WCAG 2.2 Level AA as a baseline, and go to Level AAA where the content and audience make it practical. Below is a plain-language summary of the criteria I hold every project to.
| Principle | What I check | Level |
|---|---|---|
| Contrast (Minimum) | Text against its background meets 4.5:1 for body copy, 3:1 for large text and UI components. | AA |
| Text Resizing | Content stays readable and usable at 200% zoom without loss of content or functionality. | AA |
| Keyboard | All functionality is reachable and operable via keyboard, with no traps. | A |
| Focus Visible | The keyboard focus indicator is always visible on interactive elements. | AA |
| Focus Not Obscured | Focused elements are never hidden by sticky headers, banners or overlays (2.2 update). | AA |
| Target Size | Interactive targets are at least 24×24 CSS pixels, aiming for 44×44 on primary touch actions (2.2 update). | AA |
| Labels & Instructions | Form fields have visible labels, error messages that describe the fix, and clear instructions. | A |
| Name, Role, Value | Every custom control exposes an accessible name, role and current state to assistive tech. | A |
Not every project will hit every AA criterion on day one. Where a gap exists I flag it, log a remediation plan, and share status with the client in plain language.
How I test
/ 05Automated tools catch the obvious problems; people catch the rest. I run both, in that order, on every project.
Automated
Fast, wide coverage
I use automated checkers to catch missing labels, low contrast, broken heading order, and ARIA misuse before anything reaches a human tester.
- WAVE
- Stark
- Colour Contrast Analyser
- axe-inspired checks
- HTML validators
Manual
Human, context-aware
Manual usability testing with screen readers on desktop and mobile, keyboard-only walkthroughs, zoom and reflow checks, and cognitive-load reviews of copy and flow.
- JAWS
- NVDA
- VoiceOver (macOS/iOS)
- Keyboard-only
- 200% zoom / reflow
- Cognitive review
- 01
Design review
Colour, contrast, hierarchy and copy checked in the design file before build.
- 02
Build audit
Automated scan on the built page catches obvious regressions.
- 03
Manual pass
Screen reader + keyboard walkthrough of every key journey.
- 04
Report & fix
Findings logged with severity and WCAG reference, then fixed with the team.
/ 06 Feedback
Found a barrier?
Tell me.
If any part of my site or a project I've worked on is difficult to use with a screen reader, keyboard, or assistive technology, I want to hear about it. Please include the page, the tool or browser you were using, and what you expected to happen.
Phone
07854 221446Last reviewed July 2026