We build accessible software for clients and we hold this site to the same standard. If something here does not work for you, that is a defect and we want to hear about it.
The standard we build to
This site targets WCAG 2.2 level AA. That is the same target we set on client projects and the same one most public sector procurement requires.
What we have done
Semantic structure. Real headings in order, landmark regions, lists that are lists and buttons that are buttons. Screen reader users can navigate by heading and by landmark.
Keyboard access. Every interactive element is reachable and operable with a keyboard. Focus is always visible, with a two pixel outline that meets contrast requirements in both themes. A skip link at the top of every page jumps past the navigation.
Colour and contrast. Body text meets or exceeds 4.5 to 1 in both light and dark themes. Interface controls and focus indicators meet 3 to 1. Colour is never the only way information is conveyed.
Motion. Everything that animates respects prefers-reduced-motion. With that setting on, scroll reveals resolve immediately and transitions are removed rather than shortened.
Text. No text is rendered as an image. The layout holds at 200 percent zoom and reflows to a single column at 320 pixels without horizontal scrolling.
Forms. Every field has a visible, associated label. Errors are announced, described in words rather than by colour, and linked to the field they belong to. Nothing relies on placeholder text as a label.
Disclosure widgets. The frequently asked questions and the mobile navigation use native details and summary elements, which are keyboard and screen reader accessible without any JavaScript.
What we have verified
Automated testing with axe runs on every build. Manual keyboard testing on every release. Screen reader testing with NVDA on Windows and VoiceOver on macOS and iOS, on the main navigation and the contact form.
Known limitations
We are honest about the gaps rather than claiming full conformance:
- Code blocks in articles scroll horizontally on narrow screens. This is a deliberate trade against wrapping code in a way that changes its meaning, but it is a friction point.
- Wide data tables in articles scroll within their container. The scroll region is keyboard reachable, but a very wide table remains harder to read at high zoom.
- We have not yet tested with JAWS or with voice control software. We intend to.
Reporting a barrier
Write to info@altuslabshq.com. Tell us the page, what you were trying to do, and what assistive technology and browser you were using if you know it.
We acknowledge within two business days and aim to fix confirmed barriers within ten. If a fix will take longer, we will tell you why and offer another way to get what you needed.
Feedback on this page
If our claims here do not match your experience, that gap matters more to us than the claims do. Please tell us.