Accessibility Statement

01

The standard we aim at

We target the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, across this website, the web app and the Android app.

We have not yet completed a full third-party conformance audit, so we describe our status as partially conformant: some parts meet the standard, some parts have not been formally assessed, and the gaps we know about are listed below rather than hidden.

We have not commissioned a formal WCAG 2.2 AA audit or VPAT yet. We design for deaf and hard-of-hearing learners first and welcome accessibility reports at the contact below.

02

Nothing important is audio only

• A pronunciation result is a number, a coloured per-sound breakdown, and a written explanation of what to change. Never a sound you are expected to judge by ear.
• Articulation guidance names where in the mouth a sound is made, how the air moves, and whether the voice is on — a checklist you can work through by feel and by sight.
• Recording state is shown visually: you can see that the microphone is live and see the level moving.
• Room noise is shown as a visible meter and a percentage, so a learner who cannot hear background noise can still tell that the room is too loud.
• When the recording is too poor to judge, the app says so in writing and explains that it is a microphone problem, not a mouth problem.
• Written feedback is available in English and Hindi.

03

What is implemented

• A skip link to the main content, and a single main landmark on every page.
• Semantic headings in order, so a screen reader's heading list is a usable table of contents.
• Full keyboard operation of this website, including the mobile navigation drawer, which traps focus while open, closes on Escape, and returns focus to the button that opened it.
• Visible focus indicators. We do not remove focus outlines.
• A light and a dark theme, both designed to meet the 4.5:1 contrast ratio for body text.
• Text that scales with your browser or system text-size setting, and layouts built in relative units so nothing is clipped when text grows.
• Reduced-motion support: if your device asks for less motion, background animation and smooth scrolling are switched off.
• Responsive layouts down to 320 pixels wide with no horizontal scrolling, so the site is usable zoomed in.
• Buttons and links that describe their purpose, including icon-only controls, which carry text labels for assistive technology.
• No time limits on a recording, no countdown timers, and no streak penalties for taking a break.

04

Known gaps — stated honestly

These are the things we know are not finished. We would rather you read them here than discover them yourself.

• No independent accessibility audit has been completed. Our assessment is our own.
• Practice requires a microphone and the ability to produce speech sounds, which is intrinsic to what the app does. It is not usable for its core purpose without that.
• Lesson videos: captions and transcripts are added as we publish each lesson; where a video is not yet captioned we say so in the app.
• Screen reader support in the Flutter app has not been formally tested end to end with TalkBack; we treat barriers that stop practice as high priority when reported.
• The app interface is currently available in English and Hindi only.
• Sign language (ISL) guidance clips are on the product roadmap and are not yet built into every feedback state.
• We will expand this list as pre-launch testing finds further gaps.

05

What we have tested with

Pre-launch testing covers current Android and web builds used by the team. We have not yet published a full external assistive-technology matrix; when we do, it will list only tools we have actually used.

We consider testing with deaf and hard-of-hearing learners themselves to be the part that matters most, and we would rather report a small honest matrix than a long unverified one.

06

Report a barrier

If any part of Sign & Talk blocks you, tell us. Write to devesh@vinxign.com with the subject "Accessibility barrier".

It helps if you can tell us:

• What you were trying to do.
• What happened instead.
• The page address, or which screen in the app.
• What you use — browser, screen reader, magnifier, switch device, phone model, whatever applies.

Our commitment: we acknowledge every accessibility report within 2 working days, we tell you what we found and what we intend to do within 7 working days, and we treat a barrier that stops someone practising as a higher priority than a new feature.

If we cannot fix something quickly, we will tell you the workaround and when we expect the real fix.