Accessibility statement
Revise Medical builds this site to WCAG 2.2 AA. Our conformance status, how we test, known limitations, and how to report a barrier or get help.
The short version. We build this site to the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. Every page is checked automatically on every change, and every page scored 100 for accessibility in our October 2026 Lighthouse audit. We believe the site substantially conforms, and we list below what we know is not yet right. If anything gets in your way, email hello@revise-medical.com. We aim to reply within two business days.
On this page12 sections
1. Our commitment
Revise Medical wants every person who uses this site, the Revise portal and the Revise app to be able to read it, operate it and understand it, including people who use a screen reader, a keyboard, switch access, voice control, magnification or high contrast settings. Our clients are medical practices and their staff, and some of the people who check a claim or approve a settlement have a disability. A barrier for them is a barrier to getting paid.
We treat accessibility as part of the definition of done. A page that fails an automated accessibility check does not ship, in the same way a page with a broken link or a failing test does not ship.
This statement covers the public Revise Medical website, including the calculators, data pages, guides and forms. Section 8 covers the portal and the mobile app.
2. Conformance status
The Web Content Accessibility Guidelines (WCAG) 2.2, published by the World Wide Web Consortium (W3C), define requirements for making web content usable by people with disabilities. They set three levels: A, AA and AAA. Our target is level AA.
The W3C describes three conformance states. “Fully conformant” means the content meets the standard with no exceptions. “Partially conformant” means some parts do not fully meet it. “Non conformant” means the content does not meet it.
This site is partially conformant with WCAG 2.2 level AA. We believe it substantially conforms: every page passes our automated checks with zero violations and scores 100 in Lighthouse. We use the word “partially” because automated tools catch only part of what WCAG asks, our manual review with screen reader users is not finished, and section 7 lists the gaps we know about. We will claim full conformance only after an evaluation that supports it.
Standards and laws we track
- WCAG 2.2 level AA. Our target. WCAG 2.2 builds on 2.1, so meeting 2.2 AA also meets 2.1 AA.
- Section 504 of the Rehabilitation Act. In May 2024 the U.S. Department of Health and Human Services (HHS) adopted WCAG 2.1 level AA as the standard for the websites and mobile apps of organizations that receive HHS funding, including content they provide through contractors. In May 2026 HHS extended the compliance dates to May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for smaller ones. Many of our clients bill Medicare and Medicaid, so we build to a standard above that rule today.
- The Americans with Disabilities Act (ADA). We follow the Department of Justice guidance on ADA.gov and use WCAG as the measure of an accessible site.
3. What you can expect on this site
- A skip link. The first thing a keyboard user reaches on every page is a “Skip to content” link that jumps past the header to the main content.
- Full keyboard use. Every menu, link, form, calculator and FAQ works with a keyboard alone. The header menus open with Enter or Space, and Escape closes the open menu and returns focus to the button that opened it.
- Visible focus. Whatever has keyboard focus shows a clear outline, on light and dark sections alike.
- Readable contrast. Text and status colors in our design tokens meet the AA contrast ratios.
- Motion you control. If your device is set to reduce motion, animations hold still, the page does not scroll smoothly, and content appears in place.
- Zoom and small screens. We never block pinch or browser zoom. Every page is tested at 390 pixels wide, the width of a common phone, and none of them scroll sideways.
- Labeled forms. Every field has a visible label. When you send a form, the result is announced to screen readers as a status message, and calculator results are announced as they change.
- Charts in words. Charts and diagrams carry text alternatives that state the values or the point they make, and data charts are exposed as tables where that is the clearer form.
- Structure. Each page has one main heading, headings in order, named navigation regions and a declared language, so assistive technology can move through it by landmark and heading.
4. How we build and test
- Automated checks on every change. Our test suite loads every page on the site in a real browser (Playwright) and runs the axe-core engine against the WCAG 2.0, 2.1 and 2.2 A and AA rules. Any violation fails the build.
- Layout checks. The same suite fails the build if any page scrolls sideways at desktop width or at 390 pixels.
- Lighthouse audits. In October 2026 we ran Google Lighthouse on every page with the mobile profile. Every page scored 100 for accessibility.
- Keyboard passes. We work through navigation, menus, forms, the calculators and the FAQs with a keyboard only when we change them.
- Contrast review. Every text and status color in our design tokens is checked against the AA contrast ratios.
- Screen reader review (planned). We will test the site with VoiceOver and NVDA, and with screen reader users, before public launch. Section 7 says this is not done yet.
Automated tools find many problems but not all of them. A clean axe run is a floor, not proof of conformance. That is why we ask for your feedback in section 10.
5. Technical specifications
This site relies on the following technologies to work with your browser and any assistive technology:
- HTML
- CSS
- WAI-ARIA
- JavaScript
- SVG, for diagrams and charts
Pages are generated ahead of time, so the text, links and headings are in the HTML before any script runs. JavaScript adds the menus, the calculators, form sending and the fade-in of sections as you scroll.
6. Browsers and assistive technology
We design for the current and previous major versions of the browsers below, with the assistive technology that people most often pair with them.
| Environment | How we cover it |
|---|---|
| Chrome (desktop and Android) | Automated axe and layout checks run in Chromium on every change. Lighthouse audit, October 2026. |
| Edge | Supported. Shares the Chromium engine our automated checks use. |
| Firefox | Supported. Not yet in the automated suite. |
| Safari (macOS and iOS) | Supported. Not yet in the automated suite. |
| VoiceOver (macOS and iOS) | Target. Structured testing planned before public launch. |
| NVDA (Windows) | Target. Structured testing planned before public launch. |
The site expects JavaScript to be turned on. Section 7 explains what happens without it.
7. Known limitations
These are the gaps we know about today, and what we are doing about each.
- Screen reader review is not complete. We have not yet finished a manual audit with screen reader users. It is scheduled before public launch, and we will update this page with what it finds.
- Illustrative product screens. The portal and app pictures on the marketing pages are illustrations of a demo organization with made-up data. Each is exposed as a single image with a text summary, so the individual rows and numbers inside them are summarized rather than read out one by one.
- The moving ledger. One illustration shows a ledger whose rows change on a timer. To avoid constant announcements, screen readers are not told about each change. It stops entirely under reduced motion and when it is off screen.
- Date pickers. The deadline calculator uses your browser’s built-in date field. How well it works with a screen reader depends on the browser. You can also type the date directly.
- Reflow at 320 pixels. WCAG measures reflow at 320 CSS pixels wide. Our automated check runs at 390. We have not yet automated the narrower width.
- Pages without JavaScript. Some sections fade in as you scroll. With scripts turned off and motion not reduced, those sections stay invisible on screen, though screen readers still read them. Turning on your device’s reduce motion setting shows them. We plan to make them visible by default.
- Third-party content. We link to government sources such as CMS rules, Federal Register notices and federal IDR reports. Some of those are PDFs or data files that we do not control and that may not be accessible. If you need one in another format, ask us and we will help (section 9).
8. The Revise portal and mobile app
The Revise portal and the Revise app for iOS and Android are in build. They are not covered by the conformance status in section 2 yet, and each will get its own accessibility review and statement before clients use it.
- The portal is built to the same WCAG 2.2 level AA target as this site, with the same automated checks.
- Tables of claims, deadlines and payments will be real data tables with headers, and status will be shown in words as well as color.
- The mobile app will follow Apple’s and Google’s accessibility guidelines, including VoiceOver and TalkBack labels, support for larger system text sizes, and touch targets of at least 44 by 44 points on iOS and 48 by 48 dp on Android.
- Clients whose organizations must meet the HHS Section 504 rule can ask us for the evaluation results for the portal and app as they become available.
9. Alternative formats and help
If any page, calculator result or linked document does not work for you, we will get you the same information another way. That can be the page content as plain text in an email, an accessible document, or a call where we walk you through it.
Email hello@revise-medical.com or use the contact form. Tell us what you need and the format that works best. There is no charge.
10. Report a barrier
We want to hear about anything that makes this site hard to use. Email hello@revise-medical.com with “Accessibility” in the subject. It helps if you include:
- the page address (URL) or the name of the page
- what you were trying to do and what got in the way
- the browser and any assistive technology you use, with versions if you know them
Here is what happens next.
- Reply. Our target is to reply within two business days, from a person rather than an automated message.
- Help now. If the barrier blocks something you need, we get you the information another way first and fix the page second.
- Fix. We confirm the problem, fix it and add a check where one can catch it next time. We tell you when it is fixed, or give you a date if it will take longer.
Do not include patient information or other protected health information in an accessibility report. We do not need it to fix a page.
11. Formal complaints
If you are not satisfied with our reply, write to us again and ask for the report to be escalated. A member of our leadership team will review it and respond in writing.
You also have the right to contact a government agency at any time. You do not have to come to us first.
- For complaints under the Americans with Disabilities Act, the U.S. Department of Justice explains how to file a complaint on ADA.gov.
- For complaints about disability discrimination by an organization that receives HHS funding, such as a hospital or practice that bills Medicare or Medicaid, contact the HHS Office for Civil Rights.
12. Assessment, date and changes
Revise Medical assessed this site by self-evaluation: automated axe-core checks on every page on every change, a Lighthouse audit of every page in October 2026, and manual keyboard review. We have not yet had an independent third-party audit.
This statement was written on October 13, 2026 and reflects the site as of that date. We review it whenever we add a section to the site, when a review finds something new, and at least once a year. When we change it, we update the date at the top of this page.