Accessibility

Where we stand

Our target is WCAG 2.2 Level AA. We are claiming partial conformance, because the structural criteria have been audited across the site and the perceptual ones have not been tested with the tools and people that can judge them properly. When that testing is done this page will say so, with the date.

Most accessibility statements on the web assert full conformance. Very few of the companies publishing them have run a keyboard pass or opened a screen reader, and a disabled visitor discovers that within seconds. We would rather tell you the truth and then close the gap.

Audited and passing

Checked across 20 representative pages, and re-checked on every deploy by a script in the repository, so a regression fails the build rather than sitting unnoticed:

• Every page declares its language, so a screen reader pronounces it correctly.
• Every page has one h1 and a heading order that does not skip levels.
• Every page exposes a main landmark, so a screen-reader user can jump past the navigation.
• Every form control, link and button has an accessible name.
• No element uses a positive tabindex, so tab order follows the page.
• No duplicate element ids, which would silently break aria references.
• Every image carries a text alternative.
• Interactive targets are at least 44 by 44 pixels on touch.
• Form inputs are 16px on mobile, so iOS does not zoom on focus.
• Animation is written behind motion-safe, so a reduced-motion preference is respected.

What the audit found

One real defect: the pricing page ran an h1 straight into h3 headings for each package, with no h2 between them. For a screen-reader user navigating by heading level, the section structure simply was not there. Fixed by adding a section heading that is announced but not shown, since the page already reads “Packages” visually and showing it twice would be noise.

Worth recording honestly: the audit tool itself was wrong three times before it was right. It flagged a correctly built spam honeypot because it did not understand that aria-hidden removes an element from the accessibility tree, and it twice misjudged checkboxes that were correctly labelled by being wrapped in a label. A testing tool that cries wolf gets ignored, which is worse than no tool, so each false positive was fixed before the real defect was trusted.

Not yet tested

Automated checks catch structure. They cannot judge any of this, and we are not going to imply otherwise:

• Colour contrast measured against rendered pixels in both themes, rather than read off the palette.
• A full keyboard pass: focus order, visible focus indicators, and no traps.
• Testing with an actual screen reader (VoiceOver, NVDA, JAWS) rather than inspecting markup.
• Zoom to 200% and 400% reflow.
• Whether alt text is meaningful rather than merely present, which no automated tool can judge.

Found a barrier?

Email contact@currentads.net with the page and what happened. We aim to reply within one business day and to fix genuine barriers rather than argue about which success criterion they fall under. If something on this site is blocking you, tell us and we will also give you the information another way in the meantime.

Accessibility in client work

When we build or rebuild a client site, accessibility is part of the work rather than an upsell: semantic structure, keyboard operability, form labelling, and contrast are checked before launch. We will tell a client when something they have asked for would create a barrier, and we will not install an overlay widget that claims to make a site compliant automatically. Those products do not deliver what they promise and have themselves been the subject of complaints.