Further Reading & Resources
Sources we reference throughout these docs, plus the infrastructure that keeps the site running
This page collects the sources cited throughout the docs along with background reading. Some of these are the basis for specific recommendations; others are just good context if you want to dig deeper. For the technology the site is built on and why we chose it, see Platform & Technology.
Writing & content
| Resource | What it covers |
|---|---|
| Nielsen Norman Group: How People Read Online | Eye-tracking research on scanning behavior, the foundation for most of our formatting advice |
| NNG: F-Shaped Pattern of Reading | The original eye-tracking study on how users scan web pages |
| NNG: Inverted Pyramid | Why the most important information should come first |
| NNG: "Learn More" Links | Why generic link text hurts usability and what to do instead |
| NNG: Minimize Cognitive Load | The design principle behind "calm and approachable" |
| plainlanguage.gov | Federal plain language guidelines, an excellent reference for clear writing |
| Hemingway Editor | Free readability checker (paid Plus tier available for AI features) |
SEO
| Resource | What it covers |
|---|---|
| Google: Creating Helpful Content | Google's own guidelines on what makes content rank well ("people-first content") |
| Google: Title Links | How Google generates and displays page titles in search results |
| Google: Structured Data Overview | What JSON-LD structured data is and how Google uses it |
| Google: Organization Schema | Structured data for nonprofit/organization info |
| Google: Local Business Schema | Structured data for locations like dining centers |
| Google: Job Posting Schema | Structured data for career listings |
| Search Engine Journal: Meta Descriptions | Practical guide on meta description length and best practices |
A note on FAQ schema
Google used to display FAQ answers directly in search results using FAQ structured data. They restricted this in August 2023 to government and health authority sites, and it has since been removed from search results entirely. If you hear someone recommend FAQ schema for SEO purposes, it no longer has any effect in Google Search.
Accessibility
| Resource | What it covers |
|---|---|
| WCAG 2.2 | The current Web Content Accessibility Guidelines (W3C Recommendation, October 2023) |
| WCAG: Contrast Minimum (AA) | 4.5:1 for normal text, 3:1 for large text |
| WCAG: Target Size Minimum (AA) | 24x24px minimum for interactive elements |
| WCAG: Target Size Enhanced (AAA) | 44x44px, what we target as best practice |
| W3C WAI: Image Alt Text Tips | How to write meaningful alt text |
| W3C WAI: Heading Structure | Best practices for heading hierarchy |
| MDN: prefers-reduced-motion | The CSS media query for respecting motion preferences |
| axe by Deque | Automated accessibility testing tool |
| Google Lighthouse | Performance, accessibility, and SEO auditing |
Language & tone
| Resource | What it covers |
|---|---|
| APA: Bias-Free Language (Age) | American Psychological Association guidance on age-related terms |
| National Institute on Aging | Uses "older adults" throughout, a reference for respectful language in aging services |
| Springer: Face Photos and Truthfulness | Research showing claims paired with face photos are perceived as more truthful |
| BrightLocal: Consumer Review Survey | Annual survey on how photos and attribution affect review credibility |
On 'older adults' vs. 'seniors'
There's no universal consensus here. The APA and NIA prefer "older adults." AARP uses both "older adults" and "seniors" across their site. In practice, "seniors" is what most people search for and what many organizations use in everyday communication. Our recommendation: use "neighbors", the word MOWP already uses in its own storytelling, as the warm default on the MOWP site, and don't overthink the rest. Use whatever feels natural to how the team already talks about its community.
Privacy & security
Background for the Privacy & Consent guidelines.
| Resource | What it covers |
|---|---|
| Oregon Consumer Privacy Act (SB 619) | The Oregon privacy law itself: in effect July 2024, applied to nonprofits since July 2025 |
| Washington: My Health My Data Act | Washington's health data privacy law, relevant since MOWP serves Clark County |
| IAPP: US State Privacy Legislation Tracker | Where every state's privacy law stands, updated as laws pass and take effect |
| Global Privacy Control | The browser-level opt-out signal the new site honors on its own |
| Google Consent Mode | How consent signals gate Google tags before they load |
| GA4 Behavioral Modeling | How Analytics models the gap left by visitors who decline consent |
| MDN: HTTP Cookies | What cookies actually are: first-party vs. third-party, and what they can and can't do |
| Cloudflare Learning Center | Plain-English explainers for the security concepts behind the site (DDoS, SSL, CDN, bots) |
Infrastructure & hosting
You don't interact with any of this directly, but it's worth knowing what's in place to keep the site safe, fast, and recoverable.
| Tool | What it does for you |
|---|---|
| Managed hosting | The site runs on infrastructure we manage directly rather than a shared commodity host. We control the full stack, so tuning, patching, and scaling don't wait on a third-party support queue. |
| GitHub | Every change to the site is tracked in version control using Git. If a change causes a problem, we can roll back to an earlier version. All code changes go through a review process before they go live. |
| Cloudflare | Sits between visitors and the server. It provides DDoS protection, a global CDN (so the site loads fast regardless of where someone is), SSL certificates, and caching. Think of it as a security and speed layer that runs on its own. |
| Automated backups | The site and its content are backed up regularly. If something goes wrong (an accidental deletion, a server issue), we can restore from a recent backup. |
| Continuous deployment | When we push a change to the code, it builds and deploys without any manual steps: no file uploads by hand, no one-off server tweaks. Every deployment is consistent and repeatable. |
| Monitoring & error tracking | The site reports errors, slowdowns, and downtime to us in real time, and logs are collected centrally. We usually know about a problem within minutes, often before anyone has a chance to email us, and we can trace exactly what went wrong. |
What this means in practice
If the site goes down, we can restore it. If a change causes a problem, we can undo it. If traffic spikes (a viral social post, a matching gift campaign), Cloudflare handles the load. And if something breaks, we hear about it from our monitoring, not from an inbox. The infrastructure is designed so you rarely have to think about it.
Design references
See the full list of reference sites and design inspiration.