Accessibility statement for this site

Last reviewed 24 July 2026. Reviewed at least every six months and after any significant change to the site.

The standard we target

We aim to meet WCAG 2.1 Level AA across this site. That is the level US courts and settlement agreements usually reference, and it is the level we hold client sites to, so it is the level we hold ourselves to.

How we built it

• Semantic HTML with real landmarks, headings in order, and a visible "skip to main content" link as the first focusable element.
• Every form control has a real, visible <label>; hints are associated with their field using aria-describedby.
• Every link and button is named by its own visible text. There are no icon-only controls that a screen reader would announce as just "button".
• No JavaScript is required to read the site, use the navigation, or submit either form. With scripting off, everything still works.
• Every text-and-background colour pair in the palette was computed against the WCAG relative-luminance formula and clears 4.5:1 in both the light and dark schemes — the tightest pair is 5.3:1 — and that calculation runs in our test suite, so a colour change that broke it would fail the build. The site follows your system light/dark preference rather than forcing one.
• Focus is never hidden: a 3px focus ring is drawn on every interactive element and browser defaults are not suppressed.
• Type is set in relative units and the layout reflows without horizontal scrolling at narrow widths, so browser zoom and larger default text sizes work.
• Zoom and pinch-scaling are not disabled, which is a failure we find on a large share of the stores we scan.
• Motion is minimal, and the one transition on the page is switched off for anyone whose system asks for reduced motion.
• Nothing is conveyed by colour alone; severity in our reports is labelled in words as well as coloured.

How we test it

Two ways, and we are specific about which is which:

1. Our own scanning engine, on every change. Every page of this site is scanned by the same engine we sell, in our automated test suite. The build fails if any page scores above zero on machine-detectable WCAG 2.1 A/AA failures. We dogfood, and it is enforced rather than promised.
2. Rendered browser checks. We render each page in a real browser and confirm that the focus ring is visible on interactive elements, that focus order is document order (there is no positive tabindex anywhere — the scanner enforces that too), and that no page scrolls sideways at a narrow viewport. Both forms are plain HTML with native controls and a real submit button, so they work from the keyboard with no script running at all.

What we have not verified yet

This is the section most accessibility statements leave out. As of the date above:

• We have not completed a full manual screen-reader pass across NVDA on Windows, JAWS, and VoiceOver on macOS and iOS. The site is simple enough that we expect it to behave, but expecting is not testing, and we will not write "tested with screen readers" until we have done it and can say which ones.
• We have not had an independent third-party accessibility audit of this site. Our own scanner is not an independent opinion of its own output.
• Contrast ratios were computed from our stylesheet rather than sampled from rendered screenshots on multiple displays.
• We measured reflow down to a 500-pixel-wide viewport, which is the narrowest our tooling can render. We have not measured it at 400% zoom (a 320-pixel equivalent) on real devices, so we are not claiming WCAG 1.4.10 Reflow as verified — only that nothing on the page is fixed-width below that point.
• The scan-result page renders content taken from the site you asked us to scan. That content is escaped and reformatted into our own accessible layout, but the words inside a sample of your markup are your words, not ours.

An automated scan finds specific failures; it cannot prove that none remain. That is true of our site exactly as it is true of yours, and we would rather write it down than let a green number imply something stronger.

Known limitations

• Some pages use a sticky header. On a very short viewport with large text this reduces the reading area; the page still scrolls and no content is cut off.
• The colour scheme follows your operating system. There is no in-page toggle yet, so if your OS is set to light mode you get light mode.

Tell us if something blocks you

If any part of this site is difficult or impossible for you to use, please email parveen@mendaccess.com and describe what happened, the page, and the assistive technology or browser you were using if you know it. A person reads it.

We aim to acknowledge within two business days and to tell you within ten business days either that it is fixed or when it will be. If you need information from this site in another format while we fix it, ask and we will send it to you directly.

We do not have a formal enforcement or escalation procedure beyond that, because we are a very small practice and there is no layer to escalate to. If our answer is not good enough, say so and it goes straight back to the person who signs the work.

Preparation of this statement

This statement was prepared on 24 July 2026 by Mend Access, based on a self- assessment using our own scanning engine and manual keyboard and zoom testing. It was not prepared or reviewed by an independent third party.