Accessibility statement

The standard we work to

We build against WCAG 2.2 Level AA. We have not commissioned an independent audit, so this is a statement of what we test and what we have found — not a claim of certified conformance. Where we fall short of AA we would rather say so here than let you discover it.

What is in place

• Skip to content — the first focusable element on every page jumps past the navigation.
• Visible focus — every interactive element shows a high-contrast focus ring when reached by keyboard, and focus is never removed for cosmetic reasons.
• Keyboard operation — navigation, menus, accordions, forms, the booking flow and dialogs can be operated without a mouse. Dialogs close on Escape and return focus.
• Semantic structure — one H1 per page, headings in order, landmark regions, labelled navigation, and breadcrumbs on inner pages.
• Reduced motion — if your device asks for reduced motion, ambient movement, scroll reveals and the studio reel stop animating.
• Calm mode — a control in the footer switches off all ambient motion, grain and the reading bar for anyone who prefers a still page, whatever their system setting says. The choice is remembered in your browser.
• Colour contrast — text and interface colours are checked programmatically against WCAG AA ratios, and failures are fixed before release rather than logged.
• Text scaling and zoom — layouts use relative units and reflow to 320px and at 200% zoom without horizontal scrolling or lost content.
• Images — meaningful images carry alt text; decorative ones are hidden from assistive technology.
• Languages — pages are available in English, Arabic, Urdu, Hindi, French, German and Spanish, each served with the correct language attribute, and Arabic and Urdu render right-to-left.
• Forms — every field has a real label, errors are announced in text rather than by colour alone, and nothing depends on placeholder text.

How we test

Accessibility checks run as part of the release process, not as an annual exercise:

• Automated contrast and structure checks run across the full page set — 109 pages at the time of writing — at desktop and mobile widths, in both light and dark colour schemes.
• Keyboard operation of the header, menus, forms, booking and dialogs is checked by hand whenever those components change.
• Reduced-motion and Calm mode are verified with the preference switched on.
• Right-to-left rendering is checked on the Arabic and Urdu versions of the same pages, not only on English.

Current results

This is the live output of that crawl, not a summary of it. Every published page is fetched exactly as a visitor receives it and checked against the criteria below. Where something fails, the affected pages and an example of the offending markup are shown — because an audit that reports a number without saying where is half a tool.

Known gaps

These are the things we know are not yet at the standard we want:

• Heading order on service pages. Forty-three service pages jump from the page heading straight to a third-level heading, because the body was written without a section level. It is a real structural defect, it is listed in the results above with the pages it affects, and the fix is an editorial pass rather than a line of code — so it is scheduled rather than patched with a hidden heading that would satisfy the checker and help nobody.
• No independent audit. All testing to date is our own. An external review by someone who uses assistive technology daily would find things our tooling does not.
• No screen-reader certification. The site is built to work with screen readers and is checked structurally, but we have not run a formal test pass with NVDA, JAWS and VoiceOver across every template.
• Third-party components. Embedded demos, external product links and any third-party widget are outside our control and may not meet the same standard.
• Documents. PDFs produced by the site’s tools are readable but have not been audited for tagged-PDF accessibility.
• Machine-assisted translations. Several language versions are produced with machine translation and reviewed for sense rather than by a native-speaking editor on every page.

If something does not work

Tell us and we will fix it. Accessibility problems are treated as defects, not feature requests.

• Email hello@astackra.com with the page address and what happened.
• Tell us what you were using — browser, device, and any assistive technology — if you can. It usually halves the time to a fix.
• We aim to acknowledge within three working days and to tell you either the fix or the plan.
• If the fastest route is for us to send you the content in another format while we fix the page, ask and we will.

Accessibility in the work we build

The same approach applies to client projects: semantic structure, keyboard operation, contrast checks and reduced-motion support are part of the build rather than a post-launch audit item. If your project has a specific obligation — a public-sector requirement, a procurement condition, a VPAT — say so at the start, because it changes design decisions, not just testing.

This statement

This statement was prepared by ASTACKRA on 30 September 2026 and is reviewed whenever the site’s templates or navigation change materially. It describes astackra.com only.