Accessibility Statement

This page says what we aim for on the public Consult NTA website, what we measured, and what we know is still wrong.

We target WCAG 2.1 Level AA, plus the criteria WCAG 2.2 adds at Level A and Level AA. Blind and low-vision visitors are the readers we design for first.

Consult NTA sells accessibility remediation. That makes this statement a test of our own work, so the standard here is the one we would hold a client to: measured, not asserted. The parts that do not pass are named below rather than left out.

1. Report a problem

Send whatever you have. None of this is required, and a report with one line in it is still worth sending:

• The address of the page you were on
• What you were trying to do
• What happened instead
• Your browser and operating system
• The assistive technology you use and its version, if you use one (for example VoiceOver, NVDA, JAWS, Dragon, or browser zoom)

If the site itself is the blocker

Do not fight it. Email the address above and a person will do it with you. We will take your inquiry by email, read you anything you could not reach, send the same information in a format that works better, or set up a call. You never have to complete a form on this site to reach us, to get a quote, or to become a client.

2. Conformance status

The public Consult NTA site partially conforms to WCAG 2.1 Level AA.

Partially conforms means most of the content meets the standard and some parts of it do not. It is a deliberately weaker claim than "conforms", and it is the accurate one here. We are not claiming full conformance, and nothing on this page is a certification.

The reason is content that is not ours. WCAG allows a statement of partial conformance where a page includes content from a third party that we do not control and cannot repair. Four such pieces sit on this site, and each one is named in section 5. Everything we wrote ourselves has been measured against the success criteria on the routes and in the states listed below, and passes.

This is a self-assessment. No outside organization has evaluated the site, and no one has certified it.

3. What we tested, and how

The checks run on every release, against a production build rather than the development server, at 1280px wide and at 375px wide, across all 24 public routes in that run. This page joins the list from the next one. The suite exits with an error on any failure, so a release cannot go out around it. A route that fails to load counts as a failure, not a pass.

Eight automated checkers

• A preflight that refuses to measure a page whose stylesheets did not load. Contrast, target size, reflow, and focus are all geometry and paint, and with no CSS they produce confident numbers that are entirely made up. This one runs first and stops the rest.
• Structure (axe-core): landmarks, heading order, accessible names, roles, and alt text.
• Contrast on solid backgrounds, measured from the real rendered pixels. We do not use axe's contrast numbers on this site. It cannot parse this project's oklch() colour tokens and it reported figures we could not reproduce, so we read the colours back off the painted canvas instead.
• Contrast for text over images and video, scored against the worst case in the luminance range behind the text rather than whichever photo happens to load today.
• Low vision: reflow at 320px, the WCAG text-spacing override, focus visible, and page titles.
• Non-text contrast and input purpose: field boundaries, icon-only controls, and autocomplete on personal-detail fields.
• Announced structure, pulled from Chrome's real accessibility tree, which is the same tree a screen reader consumes. 314 headings and 637 link names were reviewed out of context, the way a rotor reads them.
• The two WCAG 2.2 criteria most at risk here: 2.4.11 Focus Not Obscured, because our site header is fixed to the top of the window, and 2.5.8 Target Size.

On top of those, a keyboard pass: 842 controls tabbed, every one of them with a visible focus indicator.

Eighteen interactive states

Loading a page only certifies the one state it arrives in, and on this site most of the real defects were one click past that. So 18 named states are driven and then checked while in that state. Among them:

• The mobile menu opening, holding Tab inside itself, and closing on Escape with focus returned to the button that opened it. A dialog that closes without restoring focus drops a keyboard user back at the top of the document.
• The contact dialog doing the same.
• The contact page and the scope wizard submitted empty, checking that the error announcement carries actual words and is not an empty live region.
• The scope wizard advanced a step, checking that focus moved with it instead of falling to the top of the page.
• The glossary search filtered, and filtered down to no matches, checking that something is announced when results empty out. A list that silently empties leaves a blind user typing into a void.

A person listening

The site was listened to with VoiceOver on macOS on August 30, 2026 and it read correctly. Automated rules answer "does this satisfy the success criteria". They cannot answer "is this usable if you cannot see it", and those are different questions. Roughly a third of WCAG is machine-checkable at all.

Everything above was checked in Chrome. Section 5 says who did the listening, and why that is not the same as an audit.

4. What this statement covers

This claim covers the public site:

• The marketing pages: home, about, services and each service page, case studies and each case study, the blog and its articles, contact, glossary, privacy, terms, this page, the thank-you page, and the 404 page.
• The inquiry funnel, end to end: the scope form, the intake form, and the log-in and sign-up pages. The funnel is in scope because conformance applies to a complete process. A list of services you can navigate that ends in a form you cannot complete is a failed process, not a passing site.
• Two prospect-facing pages: the shareable audit pages and the FHI demo.

What it does not cover, and what we do not claim

• The signed-in client portal
• The admin application
• The link-protected client paperwork: invoices, contracts, proposals, and documents
• Card payment, which renders none of our own interface. It creates a session and hands you to Stripe's hosted checkout page.

Those surfaces need a signed-in session and a separate audit. We have not done that audit, so we make no claim about them either way. If you are a client and one of them is a problem for you, the email in section 1 still applies and we will deal with it directly.

5. Known limitations

These are the gaps in the claim above. They are known, and they are not fixed.

The list of interactive states is curated, not exhaustive

Eighteen states are checked because a person sat down and wrote a recipe for each one. A state nobody wrote a recipe for is not checked. We rejected an automatic crawler on purpose, because it cannot tell a state that matters from a hover, and a confident wrong answer is worse than no answer. We add a recipe when we add an interaction, so the list will always lag the site by a little.

Nobody who uses a screen reader daily has been paid to test this

One person, the owner of this company, listened to the site with VoiceOver and it read correctly. That is worth something and it is not an audit. Someone who uses a screen reader every day finds things in ten minutes that neither our tooling nor an occasional listener will ever find, and we have not commissioned that work. This is the largest known gap in the claim, and it is why the reporting route in section 1 matters more than any number in section 3.

Third-party content we do not control

Four pieces of this site are served by someone else. We control where they sit, how they are labelled, and whether there is another way to get the same outcome. We cannot change what is inside them, and we do not claim conformance for them.

• Google Maps, on the contact page. The map runs in a frame served by Google. We can give that frame a title so it is identified, and we put the street address on the page as text directly above it, so nothing on that page depends on being able to use the map. What happens inside the frame is Google's to fix, not ours.
• Mapbox map controls, on the FHI demo. The zoom and pan controls come from Mapbox. We control the page around them, and the same data is available as searchable lists in the Units and Operators views, so the map is not the only way to read it. The controls themselves we cannot change.
• Calendly, on the scheduling steps. Booking a call runs inside a frame served by Calendly. We can decide where it appears and keep it reachable from the keyboard. We cannot change anything inside it. If it does not work for you, email us and we will book the time by email or call you instead.
• Stripe Checkout, when you pay by card. Paying sends you to a page hosted by Stripe. We render none of it and cannot alter it, so it is Stripe's surface to conform. If it blocks you, email us and we will arrange another way to pay.

Two smaller calls, recorded rather than hidden

• Two card titles clip when the WCAG text-spacing override is applied. We do not count these as failures because the full text stays in the page, so the link name and the destination are complete. The suite reports them on every run rather than swallowing them.
• Two decorative separator characters sit below the contrast floor. They carry no information and are hidden from assistive technology, which is why they are exempt rather than raised.

If one of these is what is blocking you, that is exactly the kind of thing to send us. Report a problem.

6. Technical details

This site relies on HTML, CSS, JavaScript, and WAI-ARIA. Our automated checks run in Chrome. The screen reader pass used VoiceOver on macOS.

Zoom is not restricted. The page never disables pinch-zoom, and it reflows at 320px wide, so 400% browser zoom works without forcing you to scroll sideways to read a line.

Headings are set in Atkinson Hyperlegible, a typeface the Braille Institute designed to make characters harder to confuse at low vision. It is doing work here, not decoration.

7. About this statement

We review this page whenever the site changes in a way that affects it, and at least once a year. The automated checks run on every release, so the counts in section 3 move over time. If they have moved a long way and this page has not, that is a defect on our side, and reporting it is fair game.