This is the practical follow-up to If your site isn’t accessible, is it really body-positive?. If you haven’t read that one yet, start there.
Knowing your site has a problem and knowing what to do about it are two different moments. This is the second one.
Accessibility on a wellness website has two parts that practitioners usually treat separately but shouldn’t: the technical standards that govern how your site functions, and the content that tells someone with access needs whether your physical space will work for them. Both are your website’s job. Both are fixable.
Part one: the technical side
WCAG AA is the standard. It stands for Web Content Accessibility Guidelines, level AA — the benchmark used in accessibility law and enforcement across most jurisdictions. You don’t need to memorise it. You need to know what it requires and be able to ask your developer whether your site meets it.
The most common failures on wellness websites:
Colour contrast. Text needs a contrast ratio of at least 4.5:1 against its background for normal text, 3:1 for large text. The soft sage-on-white, blush-on-cream palettes common in this niche fail this regularly. Your developer can check every text element with a contrast calculator — it takes minutes. If you’re building with Matriarch, this is verified before delivery, not after.
Missing or inadequate alt text. Every image on your site needs a text description that a screen reader can announce. Not the filename. Not “image.” A description of what the image shows and why it’s there. Decorative images get an empty alt attribute — alt="" — so screen readers know to skip them. Your yoga pose photo without a description excludes blind clients from understanding what you’re showing them.
Unlabelled forms. Your contact form, your booking form, your newsletter signup — every input field needs a visible label that’s programmatically associated with it. A placeholder that disappears when someone starts typing is not a label. This is one of the most common failures and one of the easiest to fix.
Keyboard navigation. Everything on your site needs to be reachable and operable without a mouse. This matters for people with motor impairments who navigate by keyboard or switch device. Tab through your site yourself — if you get stuck anywhere, your developer needs to know.
Video captions. If you have video on your site, it needs captions. Auto-generated captions are a start but need to be reviewed for accuracy, especially for specialist terminology.
You can run a free audit at WAVE — paste in your URL and it will flag the most common issues visually, with explanations. It won’t catch everything, but it will tell you where to start.
Part two: the venue page
This is the piece most wellness websites miss entirely — and for clients with access needs, it’s often more important than any of the technical fixes above.
Someone using a wheelchair, a mobility aid, or managing an energy-limiting condition needs to know whether your space will work for her before she books. Not approximately. Specifically. The difference between “we’re accessible” on your website and the actual dimensions of your bathroom is the difference between her being able to attend and her having to either guess or email you and wait — which she’s done a hundred times before and is exhausted by.
Your venue page isn’t a compliance exercise. It’s a design problem: how do you give someone enough accurate information to make a decision about whether she can come, without making her ask?
The answer is specificity. Vague reassurance (“our space is welcoming to all”) doesn’t help her plan. Detailed, accurate information does.
The free checklist that accompanies this post covers everything your venue page needs to address — parking, entry, pathways, inside the space, toilets, and additional notes. Download it, take it to your venue, fill it in, and put the answers on your website. Update it when anything changes.
Download the venue access checklist →
If you’re not sure where your venue page should live on your site — a dedicated page, a section on your about page, included with event listings — the answer is: wherever someone would look for it before booking. Usually that means all three.
What to ask your developer
If you’re not building your own site, the practical upshot of both sections above is a brief you can hand to whoever is:
- Does this site meet WCAG AA? Can you show me the audit?
- Are all form inputs labelled correctly?
- Have all images been given appropriate alt text?
- Does the site pass colour contrast checks on every text element?
- Is keyboard navigation fully functional?
- Where should I add venue access information, and how do I update it myself?
If your developer can’t answer these questions or treats them as optional extras, that’s information.
At Matriarch, WCAG AA compliance is verified on every build before delivery. It’s not a question you should have to ask.
Janelle — Matriarch Studio buildwithmatriarch.com