If someone — a board member, a grant application, a member with a screen reader, a demand letter — has raised the question of accessibility on your Wild Apricot site, you've probably already discovered the strange silence: Wild Apricot publishes no accessibility documentation at all. Not a conformance statement, not a VPAT, not so much as a help-center article on writing alt text. Users have been asking in Wild Apricot's own forums since 2021 without an official answer.
That silence doesn't mean a Wild Apricot site can't be made substantially accessible. It can. But it does mean nobody hands you the map. I'm a certified Wild Apricot partner who does WCAG remediation on these sites, and this is the honest version of that map: what you control, what your theme controls, and what's locked inside the platform where neither you nor any vendor can touch it.
The Three Layers of a Wild Apricot Site
Every accessibility fix on Wild Apricot lives in one of three layers, and knowing which layer you're in tells you whether the fix is a checkbox, a project, or an impossibility.
1Content you edit — a checkbox. Page text, headings, images, and links inside content gadgets. Most day-to-day accessibility wins and losses happen here, by the people who update the site.
2The theme — a project. Colors, fonts, focus indicators, skip links, heading hierarchy in templates. Fixable — properly, in the theme override layer, so your fixes survive Wild Apricot's platform updates. Done wrong — pasted into pages inline — the same fixes rot. The classic version: the theme's link color fails contrast, so someone "fixes" it by hand-coloring every link on the homepage a darker blue. It looks solved — until a volunteer adds a new page, which arrives wearing the old theme color, and now the site has both. Fix the color once in the theme layer and every page, present and future, inherits it.
3System markup — an impossibility. The login form, member directories, event registration internals, store product listings. Wild Apricot generates this HTML, and no administrator setting and no vendor can rewrite it. This is the layer where honesty matters most, because anyone who promises you a fully-conformant Wild Apricot site is either unfamiliar with layer 3 or hoping you are.
The Alt-Text Trap: How Wild Apricot Silently Hides Your Images
Here's the finding that surprises every client we show it to.
Wild Apricot's editor does have an alt-text field — hover an image in edit mode, open Settings, and it's there. But Wild Apricot's own documentation describes it as "text that appears when a mouse pointer is positioned over the picture, or when the picture cannot be displayed." A tooltip. Screen readers are never mentioned. Nothing tells your volunteers the field matters.
And when the field is left blank, Wild Apricot doesn't omit the alt attribute — it emits an empty one: alt="". In screen-reader semantics, an empty alt attribute is a deliberate signal that means "this image is decorative — skip it."
Read that again from a blind visitor's chair. Your photos of volunteers at work, your event shots, your board portraits — if nobody typed alt text, they aren't announced as "image, no description available." They are silently erased, marked as if you'd decided they carry no meaning. On one Sonoma County nonprofit's site we audited recently, every photo on the volunteer-opportunities page worked this way. The site looked fine, scanned "mostly fine," and told screen-reader users the page had nothing to show them.
The fix is unglamorous and completely effective: write a short description into that field for every meaningful image, and leave it blank on purpose — documented — for genuinely decorative ones. The discipline is knowing the field exists, knowing why, and giving whoever updates your site a one-page rule for it.
What Can't Be Fixed — and What to Do About It
Layer 3 in practice, from a real audit:
Store product images have no accessible name and no field to add one. Each product photo is a link that says nothing to a screen reader. The workaround is twofold: keep product titles descriptive (they sit beside the image and are readable), and — the engineering option — a small site-wide script can copy each product's title onto its image link, turning a platform limitation into a fixed one. That's hand-written, per-image text injected by code you control. It is not an "AI accessibility overlay," about which more in a moment.
The login form uses placeholder-only labels and other system-generated patterns that only Wild Apricot can change. Some gadgets render layout tables and other legacy markup.
The right response to layer 3 is a published accessibility statement: a page that says what conformance level the site achieves, which limitations come from the platform, and how a visitor who hits a barrier can reach a human. Regulators, courts, and — more importantly — actual users treat a documented, good-faith statement very differently from silence.
About Those "One Line of Code, 90% Compliant" Widgets
Buyer's warning. Search "Wild Apricot accessibility" and most of what you'll find is overlay widgets promising WCAG compliance from a JavaScript snippet. The accessibility community's verdict on overlays is unusually unanimous: they don't repair the underlying markup, they routinely interfere with the assistive technology real users already run, and demand letters increasingly name sites with overlays. If a vendor's pitch is a percentage and a snippet, close the tab. Fix the three layers instead.
Six Tasks You Can Do This Week — No Developer Required
These are concrete, in exact click-path detail, in the order I'd do them. Tasks 1–4 need only admin access and an afternoon. Tasks 5–6 take a little longer but need no code.
1Find your untagged images15 min
Run your homepage and your five most-visited pages through our free Accessibility Checker — it names each hidden image individually and scores the page — or the free WAVE tool for a second opinion. Every image flagged as hidden or missing alt text on a meaningful photo is a task-2 item. Keep the list — it becomes your before/after proof for the board.
2Write the alt text~2 min per image
For each image on your list: open the page in Wild Apricot admin → Edit → hover the image → click Settings → find the Alt text field → type what the image shows and why it's on the page, then save the page. The formula: [who or what] + [doing what / where] — "Volunteers pulling ivy at the riverside preserve," not "IMG_1655" and not a paragraph. If an image is purely decorative (a divider, a texture), leave the field blank on purpose and note it on your list so the next person doesn't "fix" it.
3Check your headings10 min per page
In WAVE, click the Structure tab. You want exactly one h1 per page, with h2s and h3s in order beneath it — no jumping from h1 to h4. In the Wild Apricot editor, heading levels live in the paragraph-style dropdown; making text big and bold is not a heading, and screen-reader users navigate by real headings. (Stock themes routinely ship pages with no h1 at all — check yours before assuming.)
4The keyboard test5 min, zero tools
Click your browser's address bar, then press Tab repeatedly. Two questions: can you see which link is focused at every step, and can you reach everything — menu, forms, buttons — without a mouse? If focus vanishes or you get trapped, write down where. These are theme-layer fixes for your developer, but finding them takes no skill and your list halves the diagnostic work.
5Rename your store products and photo albums30 min
Wild Apricot gives store and album images no accessible name you can edit — so the visible title is doing that job. "Zip Up Hoodie: Forest Green" works; "Item 3" doesn't. Go through Store → Products and your photo albums and make every title say what the thing is.
6Draft your accessibility statementabout an hour
Create a page (link it in the footer) with four short sections: (1) the standard you aim for — WCAG 2.1 AA; (2) what you've done — alt text, headings, contrast fixes, whatever's true; (3) known limitations — name the platform: "some system-generated elements of our Wild Apricot platform, such as the login form, have accessibility limitations we cannot modify"; (4) a contact path — "if you encounter a barrier, email us and we'll provide the information another way." Honest and specific beats polished and vague.
For the broader accessibility fundamentals behind these tasks — contrast ratios, WCAG levels, how scanners work — see our guide to ADA compliance scanning.
When to Bring Someone In
Tasks 1, 2, 5, and 6 are volunteer-doable with the guide above. What's left for a developer: contrast and focus-indicator fixes in the theme override layer, the store-image script, and a verification scan with before/after results your board can file. On a typical small-organization Wild Apricot site that's a bounded, fixed-price project — not an open-ended engagement. If a vendor won't give your board a number, that's a vendor problem, not a platform problem.
And if your compliance requirements genuinely outgrow what the platform can do — layer 3 is immovable — that's a different conversation: see the honest alternatives comparison.
Want the Fixed Number Your Board Needs?
A WCAG remediation on a Wild Apricot site is a scoped project: theme-layer contrast and focus fixes, a full alt-text pass, heading corrections, verification scans, and a published accessibility statement. I quote it as a fixed price, itemized, before you commit. If the free checklist above covers your situation, I will say so.
Ask About Your Site