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.

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

Typography and readability

• Body text is large enough to read without zooming (minimum 16px, ideally 18px+)
• Line lengths stay within a comfortable range (50-75 characters per line)
• Headings are clearly distinct from body text in size and weight
• Links are visually distinct from surrounding text (not just color — underline or other indicator)

Color and contrast

The top row passes. The bottom row fails. Notice how the failing examples feel harder to read even before you know the numbers — that gut reaction is what your visitors experience.

• All text meets WCAG AA contrast ratios at minimum (4.5:1 for normal text, 3:1 for large text)
• Color is never the only way to communicate information (no "click the green button")
• Interactive elements have visible focus states for keyboard users
• The color palette is tested for common forms of color blindness
• Use the WebAIM Contrast Checker to verify any new color combinations

Navigation and interaction

• All functionality is accessible via keyboard (Tab, Enter, Escape, arrow keys)
• Focus order follows a logical reading sequence
• No content is hidden behind hover-only interactions
• Buttons and links are large enough to tap easily on phones and tablets
• Forms have clear labels, error messages, and success confirmations

Content and language

• Headings follow a logical hierarchy (h1 → h2 → h3, avoiding skipped levels where possible)
• Images have meaningful alt text that describes what's happening, not just "photo"
• Links describe where they go (see Writing for the Web)
• Plain language throughout — no jargon, no acronyms without explanation
• Reading level targets grade 8 or below (test with Hemingway Editor)

Media

If you're providing video or audio content for the site, plan for captions and transcripts. Not everyone can hear the audio, and many people watch video on mute.

For video, upload to a platform like YouTube or Vimeo — both support captions and auto-generated transcripts that you can review and edit. We'll embed the video from there rather than hosting files directly on the site. This keeps pages fast and gives you a central place to manage your video content.

We handle the technical side (motion settings, autoplay behavior), but we'll need captioned videos or transcripts from you when media is involved.

Language and translation

The current site includes some Spanish-language content, particularly around dining centers and meal requests. The existing approach uses Google Translate, which produces uneven results — especially for the kind of warm, clear messaging we're aiming for.

A few options worth discussing:

• DeepL produces significantly more natural translations than Google Translate. It could be used to translate key pages (Get Meals, Find a Dining Center, Request Meals) into Spanish, with a native speaker reviewing the output.
• Recite Me is the accessibility toolbar currently on the site. It includes translation, text-to-speech, and visual adjustments. The tradeoff is that it's hidden behind an accessibility icon that most visitors won't find or click.
• Dedicated translated pages for the highest-traffic content (especially Get Meals) would serve Spanish-speaking visitors directly rather than relying on a tool they need to discover.

This is an open conversation. The right approach depends on how large the Spanish-speaking audience is and how much content needs translation. At minimum, the pages most likely to be visited by someone in need (Get Meals, eligibility, dining centers, contact) should be easy to access in Spanish.