Aracharat Ventures LLP · India
Contact

Assurance · WCAG 2.2 AA · Checks and fixes

Find out what your site does to people who can't use it the way you do — then let us fix it.

We test by hand with a keyboard and a screen reader, because the things that actually lock people out are the things a scanner scores green. Every finding comes tied to a specific element, a specific success criterion and a specific fix — and if you want, we make the fix ourselves and hand you the pull request.

Where we stand today. Our formal certification as an accessibility auditor is in progress. Until it is issued we do not sign conformance statements — what we sell right now is testing and remediation: we find the barriers, we show you them working against a real screen reader, and we help your team clear them.

इस पेज का हिन्दी अनुवाद अभी तैयार हो रहा है। · Hindi translation of this page is in progress.

Request a sample report
Is this you
This is for you if
  • You want to know what is actually broken before a buyer, a regulator or a user tells you.
  • You have a product team who will fix what we find — or you would rather we did the fixing.
  • You are being asked accessibility questions in procurement and cannot currently answer them.
  • Someone has complained, or you would rather they didn't have to.
This is not the page if
  • You need a signed conformance statement or a certified audit today. Our certification is still in progress and we will not pretend otherwise — come to us for the testing and the fixes, and for the statement once it is issued.
  • You want an overlay widget that promises compliance in one line of JavaScript. Those do not fix the underlying problems, and we will not sell you one.
  • You need a physical-premises or document accessibility review. This is web and app only.
What we test

Automated tools find about a third of it. We look for the rest.

Scanners are good at contrast ratios and missing alt attributes. They cannot tell you that your modal traps focus behind it, that your error message is announced to nobody, or that your carousel is unusable at 200% zoom. Those need a person.

Keyboard only

Every route driven without a mouse: focus order, visible focus, skip links, focus traps in dialogs and menus, and whether anything can be reached but not left.

Screen readers

NVDA and Windows Narrator, VoiceOver on macOS and iOS, TalkBack on Android. Names, roles and values on every control; live regions that announce once, not endlessly.

Colour and contrast

Text, icons, focus indicators and state changes checked against 4.5:1 and 3:1 as applicable — in light theme, dark theme and Windows High Contrast.

Zoom and reflow

200% browser zoom and 320 CSS pixels wide with no horizontal scrolling and no lost content, plus text spacing overrides that break most fixed-height layouts.

Forms and errors

Labels tied to inputs, required fields declared programmatically, errors that name the field and the fix, and focus moved to the first problem rather than left behind.

Motion and timing

Reduced-motion support, animations that can be paused, and anything on a timer that a slower reader cannot finish.

Structure and semantics

Heading order, landmarks, list and table markup, page titles and language attributes — the scaffolding a screen-reader user navigates by instead of scrolling.

Media

Captions, transcripts, audio description where it is needed, and player controls that work from a keyboard.

  • WCAG 2.2 Level AA
  • EN 301 549
  • Section 508 context
  • Manual + assistive tech
  • Axe / Lighthouse as a floor, not a ceiling
What you get

A backlog, not a PDF that gets filed — and hands on it if you want them.

  1. 01

    Scope agreed

    We pick the journeys that matter — sign-up, checkout, the three screens everyone actually uses — rather than crawling every URL you own.

  2. 02

    Manual audit

    Each journey driven by keyboard and by screen reader on real devices, with automated scans run alongside to catch the mechanical issues.

  3. 03

    Findings you can assign

    Every issue: the element, the criterion, who it affects, how to reproduce it, and a concrete fix. Ranked by user impact first and effort second.

  4. 04

    Walkthrough with your developers

    A session where we demonstrate the failures live. Watching a screen reader hit the wall does more than any document.

  5. 05

    Remediation — yours or ours

    Your team fixes it with our findings, or we do the work: patches against your codebase, raised as pull requests your developers review and merge. Most of it is markup, focus handling and contrast, not a rebuild.

  6. 06

    Re-test

    We verify each closed item and give you an updated written record of what now passes and what does not — an internal document, not a certificate, until our certification comes through.

We will say what we cannot say. Where a finding depends on a third-party component you don't control, or on a design decision that is yours to make, the report says so plainly instead of padding the count. The same applies to our own status: no conformance statement carries our signature until we are certified to sign it.

Next step

Send us one URL and the journey that matters most.

We will come back with a scope, a price and two real findings from that page, free — so you can judge the quality of the work before you buy it.

Request a sample report