Accessibility
Forged Med targets WCAG 2.2 Level AA. This page says how far we have got, what we have measured, and — at the same length — what we have not.
36
Supports
Met, by the methods stated in the report.
10
Partially supports
Some of it is met and the gap is named.
1
Does not support
Not met. Named in the report, with what we offer instead.
0
Not evaluated
Every criterion now has a stated basis. That is not the same as verified.
6
Not applicable
No prerecorded media, flashing, or motion-driven controls to govern.
Eleven of 53 criteria are something less than full support, and this is a self-assessment: no independent firm has audited it and no person who uses a screen reader daily has been asked to try it. We say so here because an accessibility statement is read by somebody deciding whether their staff can do their job, and a row that says “Supports” because a linter was quiet is worse than an empty one. An empty row prompts a question. A false one ends it.
The standard
WCAG, and why not “ADA compliant”
There is no such thing as ADA certification. Anybody offering one is describing something that cannot be issued — so we measure against the standard regulators and courts actually apply, and report against it in the format a buyer asks for. Regulation cites WCAG 2.1 AA; we assess against WCAG 2.2 AA, which contains every 2.1 criterion and six more, because that is what a buyer asks about now.
ADA Title II and Title III
The Department of Justice adopted WCAG 2.1 Level AA as the technical standard for public entities in 2024, and courts have used it as the yardstick for places of public accommodation for years. A medical practice is one.
Section 1557 of the Affordable Care Act
HHS requires health programmes and activities to meet WCAG 2.1 Level AA on their web and mobile surfaces. That obligation sits on the practice, and software that cannot meet the standard makes it impossible for them to.
Section 508
Any federal purchaser asks for a conformance report in the VPAT format before buying. This one is written to that structure, which is what makes a row that says “Partially Supports” — and the sentence explaining exactly what is partial about it — publishable rather than embarrassing. Every criterion in scope has now been evaluated; none is left saying nobody looked.
What is in place
Seven things that hold on every change
Each of these is a check that fails a build, not a policy somebody remembers.
Every screen is scanned five ways, on every change
axe-core runs in a real browser against every page in the product — the public site, the clinical screens, the patient portal, both sign-in pages, the compliance console, and our own staff console — in a light theme, a dark theme, at a 320-pixel width, at 200% zoom, and with the text-spacing overrides a person with dyslexia may be running. A failure stops the merge.
Every screen is walked with a keyboard
Not a sample: every route in both applications, except one address that only redirects to a sign-in page that is itself walked. A script tabs from the top of each page and checks that every control that can take focus is reached, that Tab always moves on, that focus follows the page rather than jumping about, that something on screen changes when focus lands, and that each control answers to the words printed on it. A click handler on something that cannot take focus at all is caught by a rule in the source instead, and whether a focus change is easy enough to see is a judgement no script makes. That last one found a real failure on every signed-in screen we have. The same walk checks that nothing fixed to the screen hides the control you are on, and that help is in the same place on every page.
Dialogs are opened and scanned open
A dialog is where the product asks you to approve emergency access to a record or confirm a prescription, and it does not exist until you press something. Of the 31 files that show a dialog, 23 are opened with the keyboard, scanned in both themes, checked for a name, and checked to close on Escape and hand focus back. The other eight — the prescription-signing dialog among them — are listed under the gaps below.
Every page has a unique title and a first-level heading
Enforced at build time rather than reviewed. Forty-nine screens once shared a single browser title, which for anybody navigating by tab, history or bookmark meant every page in the product was called the same thing.
Keyboard and focus behaviour is tested
Focus is trapped inside an open dialog and returned to whatever opened it; Escape closes; tabs move with the arrow keys. These are unit tests on the shared components, so they hold everywhere those components are used.
Motion respects the system setting
Animation is reduced to nothing when the operating system asks for reduced motion.
A skip link, on every page
First thing in the tab order, so a keyboard user reaches the content without passing the whole navigation.
What is not
The gaps, before you find them
This is the half of an accessibility statement that usually goes missing, and the half worth reading.
Nobody independent has audited this
It is a self-assessment. No external accessibility firm has been engaged, and no person who uses a screen reader daily has been asked to try the product. Where the report says "Supports", it means our engineers assessed it and found it met — not that anybody outside this team agreed.
No screen-reader walkthrough has been done
This is the largest remaining gap and we would rather name it than bury it. Everything we measure is about whether a control can be reached; none of it establishes that what a screen reader announces when you get there makes sense. That needs somebody who uses one daily, and nobody has been asked.
Automated testing finds between a third and a half of issues
A tool can prove that alternative text is present; it cannot tell you whether it is accurate. The same goes for whether a heading is descriptive and whether an error message explains what to do. Ten criteria are marked "Partially Supports", and five of those are there for exactly this reason: they turn on whether a piece of writing is good, not whether it exists.
Eight dialogs are reasoned about rather than opened
Each needs a state our test fixtures cannot produce — a prescription ready to sign, an attestation that has come due, a chart the server refuses to open, a session that has genuinely gone idle. The reasons are written down one by one, and a dialog nobody has written a reason for fails the build.
A session ends twelve hours after sign-in
Every time limit is warned about and can be extended with one action — inactivity a minute ahead, the session’s hourly lifetime two minutes ahead — in the practice app and the patient portal alike. Twelve hours after signing in, the session ends and you must sign in again; that is warned ten minutes ahead so work can be saved, and it is the one limit that cannot be extended.
Video visits do not have live captions
The platform records this for every visit and tells the patient before they join. A practice can bring a spoken-language or sign-language interpreter into the call, or arrange a live captioner; the video service itself captions nothing.
Section 1557 taglines are not supplied
Each practice’s nondiscrimination notice is published on its sign-in pages and patient portal, and signed-in patients can ask for an interpreter, a sign-language interpreter or an alternate format. The taglines in the fifteen languages a practice’s state requires are not supplied: a translation that is subtly wrong reads as compliant and tells a patient something untrue, so the practice adds its own, and the admin screen says what is missing until it has.
The product is available in English only
A patient record can store a preferred language and whether an interpreter is needed, and those travel with the record. The interface itself is not translated. That is a limitation of this software rather than of the practice using it, and we would rather say so than let it be discovered.
If something blocks you
Tell us, and here is what happens
A reporting address with no commitment behind it is a suggestion box.
Email accessibility@forgedmed.ai. Tell us the page, what you were trying to do, and what happened instead. If you use assistive technology, saying which one and which browser helps us reproduce it — and if you would rather not, send it anyway.
- We acknowledge within two working days — a person, not an autoresponder.
- We tell you what we found within ten working days, including when we think it is a genuine barrier and when we do not, and why.
- If it is a barrier, we say when it will be fixed and, where one exists, what to do in the meantime.
A barrier you hit is worth more to us than another scan. Automated testing has already found what it can find here; the things left are the ones only a person meets.
The report
Conformance report
Format: VPAT® 2.5 Rev, WCAG edition. Version 1.6, 28 September 2026.
The full criterion-by-criterion report covers all 53 applicable Level A and Level AA success criteria, states which of seven evaluation methods produced each answer, and says what each method cannot see.
Procurement teams: ask us for it at accessibility@forgedmed.ai and we will send the current version. It is maintained in the same repository as the product, so it moves when the product does rather than once a year.
Questions about anything else on this page: get in touch.