Accessibility Statement

The standard I am aiming at

Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. That is the benchmark courts and regulators reference under the Americans with Disabilities Act, and it is the target this site was built against from the first line rather than retrofitted toward.

What has been built in

• Colour contrast was computed, not eyeballed. Every text and background pair in use was measured against the WCAG formula. One combination in the original palette measured 4.03:1, below the 4.5:1 threshold for normal text, and was changed — the measurement is what caught it, which is the entire argument for measuring.
• Keyboard operation throughout. Every link, button, field and control is reachable and usable with a keyboard alone, with a visible focus indicator. The mobile menu closes on Esc and returns focus to the button that opened it.
• A skip link as the first focusable element on every page.
• Semantic structure. Real landmarks, one h1 per page, and headings in order, so screen-reader navigation by heading works properly.
• The state checker announces its answer. It is a live region, so the result is spoken rather than only appearing on screen.
• Reduced motion is honoured. If your system asks for reduced motion, all animation stops — and, importantly, content that would normally fade in is shown immediately rather than staying invisible.
• Targets are at least 44×44 pixels, and the site is usable at 390px wide without horizontal scrolling.
• Text resizes. Type is set in relative units and survives browser zoom to 200% without loss of content or function.

Where this honestly stands

This site is new, and this section says where it actually stands rather than where I would like it to stand. An accessibility statement that only lists what went well is the kind that makes people cynical about accessibility statements.

• Not yet tested with real assistive technology by a real user. Automated and structural checks have been run. That is not the same thing and should not be presented as if it were.
• No embedded scheduling widget is in use. Requests go through the inquiry form and the phone number, both of which are ordinary accessible controls. Embedded schedulers are a common source of accessibility failures, so if one is added later it will be tested on its own merits before it goes on the site.
• No formal third-party audit has been carried out.

How this was assessed

By structural review of the markup, computed contrast measurement across every colour pair in use, keyboard-only navigation of every route, and rendering at mobile and desktop widths with motion running. Assessed on the date at the top of this page.

Found a barrier? Tell me, and get help anyway

If anything on this site stops you getting what you need, email andres@yourmhs.com. Two things will happen: I will get you the information or the help you were after by whatever means works for you, and I will fix the underlying problem.

You do not need to identify yourself, explain your disability, or use any particular terminology. “The state list is unusable for me” is a complete and useful report.

I aim to respond within two business days.

Content I do not control

Carrier websites, healthcare.gov and any embedded scheduling tool are outside my control. If one of them creates a barrier for you, tell me anyway — I can often get you the information directly, and I would rather know.