A care directory that only some people can use is not doing its job. Many of the people who need this site are older, are navigating a disability, or are helping someone who is. Accessibility is the product, not a compliance checkbox.
Where we stand. We build to the Web Content Accessibility Guidelines 2.1, Level AA. We have not had an independent audit, so we do not claim full conformance. Below is an honest account of what we have done and what we know is still wrong.
What we have done
- The pages work without JavaScript. Every public page — search, listings, categories, city pages, guides — is rendered on the server. Scripts add maps and smoother forms; they are not required to read a page or follow a link.
- The menus are real buttons and links. The navigation can be operated by keyboard, reports its expanded state to a screen reader, closes on Escape, and returns focus to the control you opened it with.
- A skip link. The first thing a keyboard user reaches is "Skip to content", so getting to the page itself doesn't mean tabbing through three menus first.
- Semantic structure. Landmarks mark the header, navigation, main content, and footer, and lists are marked up as lists so screen-reader users can skim them the way sighted users do.
- Visible focus. Whatever the keyboard is on is outlined, on every link, button, and form field.
- Text you can resize. Type is set in relative units and the layout reflows down to a phone-width screen and up to 200% zoom without content being lost or clipped.
- Colour is never the only signal. Availability, verification, and licence status are carried in words as well as colour, and body text is set at a contrast level intended to clear the 4.5:1 threshold.
- Decorative images are hidden from screen readers rather than announced as meaningless filenames.
- Forms have real labels tied to their fields, and errors are reported in text next to the form, not only by colour.
What is still wrong
Listing these is more useful than claiming they don't exist:
- Maps. The provider and search maps use a third-party mapping library that is difficult to operate by keyboard and announces poorly to screen readers. Every address and phone number shown on a map is also available as text on the same page, so no information is map-only.
- Provider photos. Images synced from providers' public business listings arrive without descriptive alt text. They are currently marked as decorative, which is correct for a screen reader but means a genuinely informative photo goes undescribed.
- The dashboards require JavaScript. The provider and admin dashboards are built in the browser and will not work with scripting off. They are behind a sign-in and are not part of the public directory.
- Heading order. On some listing pages the headings skip a level — an h1 followed directly by h3s on the result cards. It reads correctly but makes a screen reader's heading outline less useful than it should be.
- No independent audit yet. Everything above is our own testing, mostly keyboard and screen-reader spot checks. It is not the same as an assessment by someone who uses assistive technology daily.
If something blocks you
Tell us and we will fix it. Email hello@rightcaremn.com or use the contact form, and if you can, include the page address, what you were trying to do, and the browser or assistive technology you were using.
We aim to acknowledge accessibility reports within two business days. Anything that stops someone reaching care information is treated as urgent; everything else goes on the list and gets fixed in order.
If the fix will take time, we will tell you what it is and offer another way to get the same information in the meantime — including, if it helps, someone reading the listing details to you over email.
Elsewhere on the web
Parts of the experience are not ours: map tiles, fonts, and providers' own websites, which we link to but do not control. Where a third-party component blocks access to information, our commitment is to make that information available another way on our own pages.