Accessibility statement

This site aims to meet WCAG 2.2 level AA. Below is what was actually tested and what was not, because a statement that only says “we are committed to accessibility” tells you nothing you can check.

What is tested, automatically, before every deploy

• axe-core runs against every page in the sitemap at 390 pixels and at 1440 pixels wide, covering WCAG 2.0 A and AA, 2.1 A and AA, and 2.2 AA, plus the best-practice rules.
• Horizontal overflow is checked at both widths, and the element responsible is named rather than the failure just being reported.
• Interactive targets smaller than the WCAG 2.2 minimum of 24 by 24 pixels are treated as failures. Anything that meets that but is under 44 pixels is reported as a note, since 44 is the level AAA target and worth knowing about.
• Any element that animates into view is checked to be visible after the animation should have settled, so content cannot end up permanently hidden by a script that did not run.
• A structural pass checks heading order, one h1 per page, alt attributes on every image, form labels tied to their controls, and links that have an accessible name.

These checks are run before release alongside a visual review. They do not replace testing with people who use assistive technology.

What is built in rather than tested for

• Every page works with a keyboard alone, and the focus indicator is visible on a background that it contrasts against.
• A skip link is the first thing in the tab order on every page.
• Body copy uses readable sizing. Smaller supporting labels are used for prices, captions and navigation details.
• Colour is never the only way something is communicated.
• All motion stops entirely when your system is set to reduce motion, and no content depends on an animation having run.
• Light and dark are designed separately and tested separately, rather than one being an inversion of the other.
• The accordion on this site is a native details element, so assistive technology already knows what it is.
• Form errors appear next to the field they concern, are announced, and say what to do rather than that something is invalid.

What has not been tested

Automated tools catch a minority of accessibility problems. The following are honest gaps rather than omissions:

• No testing with a real screen reader. No NVDA, JAWS or VoiceOver pass has been run on this site, so what is claimed above is that the semantics are correct, not that the experience has been listened to.
• No testing with users who have disabilities. Automated checks are not a substitute for that and it would be dishonest to imply otherwise.
• No voice control testing, and no testing with a switch device or an eye tracker.

Known limitations

• The case study screenshots are images of other websites. Their alt text describes what the screenshot shows, but the detail inside a screenshot of a page cannot be fully conveyed in a sentence.
• The three diagrams on the automation case studies are built in HTML, as lists and text, so a screen reader reads every step and figure in order.

If something does not work for you

Please tell me, and be as specific as you can bear to be: the page, what you were using, and what happened. Email evanalmond@gmail.com or ring 07355 607308. I will reply within five working days, and if it is a genuine defect I will fix it rather than explain why it is acceptable.

If you would rather have the content of any page another way, ask and I will send it.