Skip to content
gasguide

Accessibility statement

What gasguide.app conforms to today, what it does not, and how to tell us when something blocks you. Written from an internal audit dated — not from a conformance claim we have not tested.

Conformance status

gasguide.app is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means some parts of the product do not fully meet the standard. The barriers we know about are listed below, with the scale of each one. We target WCAG 2.1 Level AA (which also covers the Section 508 ICT Refresh, and the EN 301 549 requirements that reference WCAG), and we are not there yet.

Standard targeted
WCAG 2.1 Level AA
Conformance claimed
Partial — see known gaps
Date assessed
Method
Internal self-assessment (source review + manual walkthrough). No third-party audit.

Known gaps

These are the barriers we have measured. This list is deliberately specific: a vague statement is not usable by a procurement reviewer and not usable by someone deciding whether they can do their job in this product.

  • Most form errors are not announced to screen readers

    WCAG 2.1 — 3.3.1 Error Identification (A), 3.3.3 Error Suggestion (AA), 4.1.3 Status Messages (AA)

    The application contains 121 <form> elements across 84 files (re-counted 2026-08-21 excluding comments; the earlier figure of 124 counted three references that appear in source comments rather than in rendered markup). Before this audit, aria-invalid appeared exactly zero times in the source: validation errors were rendered as red text with no programmatic link to the field that failed, and focus stayed on the submit button. Sixteen of those 121 forms have now been fixed — sign-in, sign-up, password reset, the two authentication-code forms on the two-factor challenge, adding or editing a credential, the credential share-link builder, credential expiry alert preferences, the support and demo-request forms, the change-email and delete-account forms, onboarding, and the newsletter and daily-question sign-ups. They mark the failing control aria-invalid, point it at that field's own error text with aria-describedby, announce it via role="alert", and move keyboard focus to the offending field. The remaining 105 have NOT been converted and still fail these criteria: 27 of them are in employer/organization administration and 78 are in the admissions tools, internal admin screens and the remaining account pages.

  • A small number of inputs have no accessible name

    WCAG 2.1 — 4.1.2 Name, Role, Value (A), 3.3.2 Labels or Instructions (A)

    Placeholder text is not a label: it disappears on typing and is unreliably announced. A re-scan on 2026-08-21 — resolving label wrappers and computed htmlFor/id pairs, which an earlier scan could not follow — found fourteen controls in customer-facing and internal screens with no accessible name at all. Five have since been fixed: the two-factor ENROLMENT code field (previously an unnamed edit box on the screen that decides whether you can get back into your own account), the CE cycle start date, the mock-interview answer box, the page-notes field and one admin filter. The nine that remain are all in internal admin tooling (API keys, campaigns, the assistant console, the crop studio, and the demo and support row editors) and have not been fixed. Earlier fixes covered the two-factor CHALLENGE fields, the assistant chat input and the store waitlist email.

  • One colour token falls below the contrast minimum

    WCAG 2.1 — 1.4.3 Contrast (Minimum) (AA)

    The --fg-4 token measures 2.7:1 on the dark surface and 2.0:1 on the light surface, against a 4.5:1 requirement. It is used in 11 places, almost all of them separator glyphs (a middot or bullet between two pieces of text) which carry no information, plus one line of text on an internal admin page. No user-facing sentence depends on it, but it is below threshold and is listed rather than explained away.

  • Heading levels skip on two page templates

    WCAG 2.1 — 1.3.1 Info and Relationships (A)

    The CE lesson page and the news article page each jump from a level-1 heading straight to a level-3 heading for a single trailing section ("References" and "Related"). A screen-reader user navigating by heading level will perceive a missing level. Not yet fixed: the global stylesheet sizes headings by element, so re-levelling them changes their appearance and needs a design pass alongside it.

  • 3D anatomy models have no text equivalent

    WCAG 2.1 — 1.1.1 Non-text Content (A)

    The interactive anatomy viewers render into a WebGL canvas that exposes no text alternative and cannot be explored by a screen reader. Two of the three viewers (the labelled regional viewer and the full-body viewer) surround the canvas with keyboard-operable, labelled controls — camera rotation and reset, plus a searchable structure list in the labelled viewer. The plain viewer has no such controls. Equivalent anatomy content exists as labelled 2D figures with captions inside the lecture pages, but that equivalence is not signposted in the interface.

  • Silent animation clips have no text alternative

    WCAG 2.1 — 1.2.1 Audio-only and Video-only (Prerecorded) (A)

    Course pages embed short silent <video> clips described in the interface as "clips showing the physiology in motion". They carry information, they have no captions, descriptive audio, or text description, and their only accessible text is the file name rendered underneath. That is a failure, not a decorative exception. Lecture narration, by contrast, is served as <audio> with no <track> element but IS a reading of the lecture text present on the same page — an adequate text alternative in substance, though it is not labelled or linked as one.

  • No third-party audit, no VPAT, no automated gate

    Process, not a success criterion

    This assessment was performed internally by the engineering team on August 19, 2026 by reviewing the application source and walking the primary flows. It did NOT include an independent third-party audit, testing with people who use assistive technology day to day, or a screen-reader pass across the whole product. There is no automated accessibility check in continuous integration, so regressions are not currently caught before release. We do not publish a VPAT or Accessibility Conformance Report.

What does conform today

  • Text alternatives for images

    Every <img> element in the application carries an alt attribute — 11 image elements, verified by a source scan of all .tsx files. Decorative SVG icons and status dots are marked aria-hidden so they are not announced twice.

  • Keyboard access + visible focus

    A skip-to-content link is the first focusable element on every page. Focus indication uses a real CSS outline on :focus-visible rather than a box-shadow ring, so it survives Windows High Contrast Mode; a forced-colors media block maps focus and borders onto system colours.

  • Colour is not the only signal

    Credential status — the product's most safety-relevant indicator — always carries text. Every badge renders a written label ("Active", "Expiring soon", "Expired"), coloured status dots are aria-hidden and sit beside text such as "in 12 days" or "9 days ago", and the wallet-health stoplight is paired with a written headline. A user who cannot distinguish red from green loses no information.

  • Body text contrast

    Measured against both theme surfaces: primary text 20.2:1 (dark) and 17.5:1 (light); secondary text 10.3:1 and 5.7:1; tertiary text 5.3:1 and 5.2:1. All clear the 4.5:1 AA threshold for normal-size text. See the known gaps for the one token that does not.

  • Reduced motion + zoom

    The global stylesheet gates motion behind prefers-reduced-motion in 14 separate blocks, covering the animation utilities, skeleton loaders, smooth scrolling and the route-change view transitions. Individual components have not each been re-verified against that setting. Pinch-zoom is not disabled: the viewport permits scaling up to 5×.

  • Appearance preference

    A light (higher-contrast, cream-and-ink) theme can be selected at /account/preferences and now persists across page loads and devices. Until August 19, 2026 that setting stored a preference that was never applied — it was fixed in the same audit that produced this page, and is listed here because it was a real defect, not a feature.

Report an accessibility problem

If any part of gasguide.app blocks you, tell us and we will treat it as a defect rather than a feature request. Include the page address, what you were trying to do, and the assistive technology and browser you were using if you know them. A founder reads this inbox and aims to reply within one business day.

If a reply does not resolve it, escalate to legal@gasguide.app. We do not require you to use a specific format or to identify a success criterion — a plain description of what went wrong is enough.

For procurement and institutional review

We do not currently publish a VPAT or Accessibility Conformance Report, because we have not completed the independent evaluation one should be based on. We will not sign a conformance claim we have not tested. What we can provide to a hospital, health system or nurse-anesthesia program under review is this gap list, the specific checks behind each number, the surfaces your users would actually touch, and a remediation discussion scoped to those surfaces. Email compliance@gasguide.app. Related: /trust for security and compliance posture, /security for controls, and /terms.

This statement describes gasguide.app and the CredBinder credentialing portal operated on the same application by MEDTECH SOLUTIONS USA LLC. It is reviewed when the product changes materially and re-dated only when the underlying checks are re-run. Back home.