Accessibility

The people using this site (older adults, caregivers, donors) have a wide range of abilities and comfort with technology. Here's how the site is built to work for all of them. The target is WCAG 2.2 Level AA conformance, the current version of the standard, verified with an accessibility audit before launch.

How accessibility works

Most people who need accessibility support bring their own tools. Someone who can't see the screen uses a screen reader (like VoiceOver on an iPhone or NVDA on Windows). Someone with low vision uses their browser's zoom or their device's larger-text and high-contrast settings. Someone who can't use a mouse navigates with the keyboard or with voice. These tools are set up the way each person prefers and work on every website they visit. They don't depend on us adding anything special.

What makes a site work with those tools is how it's built: clear heading structure, real buttons and links, enough color contrast, labels on forms, meaningful alt text. That's the foundation, and it's invisible when it's done right.

There's a second category: accessibility overlays and toolbars, widgets that add a floating button to resize text, change colors, or read the page aloud. The legacy site uses one (Recite Me). These help a slice of visitors, especially older adults who don't use dedicated assistive tools and may not realize their own device already does this. They're a supplement to building the site properly rather than a substitute for it, and the more aggressive "one click fixes everything" versions can interfere with the screen readers people already use.

The accessibility audit tests the finished site with Recite Me turned on. We check that it:

• Does not cover navigation, forms, consent controls, or primary actions on phones and tablets
• Can be reached, opened, used, and dismissed with a keyboard
• Does not disrupt page order, labels, keyboard focus, or screen-reader announcements
• Leaves every core task usable without opening the widget
• Is never the site's only way to meet an accessibility requirement

Who we're designing for

The primary audience includes:

• Older adults (60+) who may have reduced vision, hearing, or motor control
• Family members and caregivers who may be stressed and scanning quickly
• Donors of all ages who expect a professional, trustworthy experience
• Volunteers ranging from students to retirees

Built into the system

Accessibility shouldn't depend on everyone remembering the rules. Where it can be enforced by how the site is built, it is:

• Heading levels are assigned automatically everywhere except long-form copy, where the editor offers h2 to h4. Every page gets exactly one h1.
• Alt text is asked for on every image, with a decorative option for images that carry no meaning of their own.
• Animated numbers report their final value to screen readers rather than counting, and don't animate at all for visitors who've asked for reduced motion.
• Color is never the only thing carrying a message, and contrast is checked against the palette rather than judged by eye.

The interaction bar

Everything interactive is built and tested to the same standard:

• Every interactive element works with a keyboard (Tab, Enter, Escape, arrow keys), with visible focus states and a focus order that follows the reading sequence
• No content is hidden behind hover-only interactions
• Buttons and links are large enough to tap easily on phones and tablets. We target 44 by 44 pixels for anything tappable, custom controls and map pins included
• Anything achieved by dragging works without it. WCAG 2.2 requires a single-pointer alternative to pan-and-zoom, so anywhere we use a map, the same answer is available without one
• Forms have clear labels, error messages, and success confirmations
• The current page is exposed in navigation, not only shown through color or styling
• Layered controls are tested together on small screens. The menu, consent banner, Recite Me, and any other fixed controls cannot cover one another or trap focus