Handbook · Case Study

Role

Product Designer

Timeline

Jan 2026 - Ongoing

Tools

Notion
Figma
Webflow
Procreate

Skills

Content strategy
Technical writing
Information architecture
Accessibility expertise
Product design
Project scoping

The A11y Handbook explains where accessibility barriers actually come from and how to prevent them. Not what to fix after launch. Not checklists to follow. Understanding that changes how you build from the start.

I created the handbook because the resource I needed did not exist. Standards documentation too dense to parse. Blog posts too shallow to build understanding. Nothing explained which early decisions create barriers or when those decisions happen in actual work.

Identifying the problem

Most accessibility resources fall into two categories. Dense standards that tell you what fails but not where failures come from. Shallow tips that tell you what to fix but not how to prevent problems.

Neither builds understanding. Teams follow checklists without knowing why. Fix problems without learning where they started. Repeat the same barriers in the next project.The gap is not awareness. Everyone knows accessibility matters.

The gap is understanding. Which decisions create barriers. When those decisions happen. What each role controls.

This created a practical problem for me as a designer who works with design and code. I needed to understand accessibility deeply enough to make informed decisions during design work, not just audit outcomes after implementation. The resources available either assumed I wanted to become a WCAG expert or gave me surface-level tips that didn't explain systems.

Finding what was missing

Before writing anything, I spent time analyzing existing resources to understand exactly what was missing:

WCAG documentation provides comprehensive success criteria but assumes you already understand barriers. 1.4.3 defines contrast thresholds for text legibility, 4.5:1 for standard text and 3:1 for large text, but not why contrast matters for real users, which design decisions cause it to fail, or how to build it into the design process from the start.

Blog posts and articles tend toward either extreme detail on specific techniques or generic advice like "consider accessibility early." The detailed posts help when you already know what you're looking for. The generic posts don't help at all.

Accessibility courses often focus on auditing and remediation. Learn to find problems. Learn to fix them. Valuable skills, but doesn't teach prevention. By the time you're auditing, the decisions that created barriers already happened.

The pattern was clear: resources either assumed expert-level knowledge or provided beginner-level tips. Nothing built understanding from first principles. Nothing explained the relationship between early decisions and accessibility outcomes.

Shaping the scope

The handbook needed clear boundaries. I set constraints early:
‍
No checklists. No quick tips. No "5 ways to improve accessibility."

‍The handbook would explain systems instead:

Where barriers form during normal work
Which decisions create them and when
What each role controls
How to prevent problems before they exist

This constraint forced better work. Cannot give quick fixes, so explain where problems come from. Cannot list rules, so show which decisions matter.

Focus on prevention over remediation. Most resources teach you to find and fix barriers. The handbook would teach you to recognize which decisions create barriers so you prevent them during normal work.

Concept-first, implementation second. Start with understanding principles, not memorizing requirements. You can't apply WCAG criteria meaningfully without understanding what barriers are.

Role-based responsibility. Content, design, and development all create accessibility. Show what each role controls and when those decisions happen.

These constraints shaped everything that followed.

Designing the structure

The structure needed to build understanding progressively. Abstract concepts first, then concrete application.

I settled on seven major sections, each serving a specific purpose:

Fundamentals - What accessibility actually is. Not compliance. Not charity. Whether people can use what you build. This section establishes the frame: accessibility is about decisions, not disabilities.

WCAG Levels - Level A, AA, AAA explained as severity thresholds, not achievement tiers. Understanding what each level addresses helps prioritize, but compliance is floor not ceiling.

The Four Principles - Perceivable, Operable, Understandable, Robust. These describe how products fail when barriers exist. Framework for recognizing problems.

People and Disabilities - Who experiences barriers and how. Visual, motor, cognitive, auditory impairments. Temporary and situational barriers. Understanding impact changes priorities.

Roles - Where barriers originate. Content creates structure. Design creates patterns. Development implements both. This section maps decisions to roles and shows timing.

Putting It Together - How everything connects. Where barriers actually come from. Common objections and reframes. Synthesis of the framework.

Where to Start - Application. Different starting points. What to prioritize. Testing methods. How to build it into practice.

Each section builds on previous understanding. You cannot apply standards without understanding barriers. You cannot prevent barriers without knowing where they come from.

The writing process

Writing began with the hardest constraint: no checklists. This meant every section needed to explain systems, not list actions.

I started with "Design" role section because I understood it best. Writing about heading hierarchy forced me to explain not just "use semantic headings" but why headings matter (screen reader navigation), when that decision happens (content strategy), and what breaks when they're wrong (users can't jump between sections).

That pattern repeated across all sections. Not "ensure sufficient contrast" but why contrast ratios exist, which design decisions affect them, when those decisions happen, and what fails when contrast is insufficient.

Three rules guided every section:

Direct - Short sentences. Active voice. No jargon unless necessary, then defined immediately. Write like explaining to a colleague, not presenting to a conference.

Grounded - Real barriers. Concrete decisions. No abstract theory disconnected from actual work. Every principle connected to actual implementation decisions.

Honest - Every word earns its place. No filler. No buzzwords. If a sentence doesn't teach something or connect ideas, delete it.

First drafts were too long. I wanted to be thorough, to cover edge cases, to qualify statements. Each section ballooned to 3000+ words. Too much. Overwhelming.

The editing process became ruthless. Cut everything that doesn't directly serve understanding.
‍
"Accessibility is important" → delete, obvious
"This helps create more inclusive experiences" → delete, vague
"Consider your users' needs" → delete, empty advice
"Many experts recommend..." → delete, appeal to authority without substance

What stayed: explanations of how things work, why barriers form, which decisions create them, where those decisions happen in actual workflows.

Finding the "right" voice

The tone emerged from the constraint of making every word earn its place. When you cut filler, buzzwords, and hedging, what remains is direct explanation.

But directness without empathy feels harsh. The handbook needed to be honest about barriers without being preachy or moralistic about accessibility.

I avoided:

Guilt-inducing language ("you're excluding people")
Inspirational framing ("accessibility is for everyone!")
Moral appeals ("it's the right thing to do")

These might be true but they don't build understanding. They make accessibility feel like charity or obligation rather than competence.

Instead: accessibility is whether products work when people try to use them. Barriers come from decisions. Make different decisions, remove barriers. Professional work, not moral crusade.

This framing came from my own experience learning accessibility. Guilt didn't help. Inspiration didn't help. Understanding where my design decisions created barriers, that helped. I could act on understanding.

Strategy behind the linking

Every section connects to others through embedded links. Not "see Section 4.2" or "refer to the chapter on WCAG." Natural narrative linking.

Example from "Design" section: "Design decisions create visual hierarchy, interaction patterns, spacing, color choices, and layout. These determine whether interfaces are perceivable, operable, and understandable."

The links teach. They show relationships. Clicking "perceivable" takes you to the principle that explains why perception matters. You learn the connection by following it.

This created a web of understanding rather than linear documentation. You can enter anywhere and find connections to related concepts. The framework is a network, not a hierarchy.

Staying consistent with a design system

The website needed to support understanding without distracting from it. I designed with clear principles:

Typography as hierarchy - One font family (system stack for performance). Size and weight create distinction. H1 for section titles. Body text at comfortable size. No decorative fonts competing for attention.

Generous spacing - Content breathes. Sections clearly separated. No cramped layouts forcing rapid scanning. Reading comfort matters for long-form educational content.

Minimal color - Black text on off-white background. High contrast by default (ironic to have an accessibility handbook with poor contrast). Accent color used sparingly for interactive elements.

Clear navigation - Section structure visible. Progress indicators showing where you are. Easy to jump between sections or read linearly. Both approaches supported.

Responsive without tricks - Layouts that adapt naturally to screen size. No breakpoint-specific designs that break between defined sizes. Flex and grid doing what they're meant to do.

Cards for structure - Homepage uses cards to show handbook sections. Each card displays section title and contained topics. Simple. Scannable. No mystery about what each section contains.

The design system itself demonstrates accessibility principles. Semantic HTML. Logical heading hierarchy. Keyboard navigation. High contrast. Flexible layouts. The handbook practices what it teaches.

Illustrations

Each section will include simple illustrations. Outline drawings on solid single-color backgrounds. No decoration. No complexity. Just clear visual examples.

The approach: clean line drawings that show the concept directly. A cramped button layout versus a spacious one. A form without labels versus one with them. Visual comparisons that reinforce what the text explains.

Captions anchor each illustration to the concept it demonstrates. Not decorative. Not supplementary. Part of the explanation.

Illustrations serve understanding. They make concepts visible. They give concrete form to abstract explanations. That's their purpose.

Testing with beta readers

Content complete meant ready for other people to read it. I needed to know if the framework actually built understanding or if it only made sense to me because I wrote it.

Beta reader recruitment focused on the target audience: designers, developers, and content writers at various experience levels with accessibility. Some complete beginners. Some with basic knowledge. Some relatively experienced. All willing to give honest feedback.

What the beta phase revealed:

What worked: The role-based structure helped people understand what they personally control. Designers appreciated seeing where their decisions create barriers. Developers understood which implementation choices matter. The concept-first approach made sense once people adjusted to it.

What needed clarification: Some sections assumed too much baseline knowledge. The WCAG Levels section needed more context about why levels exist. The Robust principle needed clearer explanation because it's less intuitive than the other three.

What was missing: Real examples. Beta readers wanted to see more concrete before/after comparisons. The framework made sense but practical examples would make it stick better.I revised based on this feedback. Added context where needed. Clarified confusing sections. Planned for the "Stories" section to provide the real-world examples beta readers wanted.

Current state and next steps

Core content complete. Twenty-seven sections written, edited, revised based on beta feedback. The framework exists. Understanding built from refusing to use checklists.

Immediate next steps: Interview people with disabilities for the "Stories" section. These conversations will ground the framework in real experience. Not just narratives. Actual barriers encountered in daily life and which design/development decisions created them.

Final technical polish. Performance optimization. Accessibility audit of the handbook itself (the irony of shipping an inaccessible accessibility handbook would be unbearable).

What this project taught me

Building the handbook reinforced lessons about constraint-driven work:

Constraints force better thinking. No checklists meant explaining systems. Harder work. Better outcome.

Understanding comes from teaching. Writing the handbook deepened my own understanding of accessibility. Explaining forces clarity.

Scope determines feasibility. The handbook is possible because it has clear boundaries. Concept-first understanding, not comprehensive implementation guide.

Maintenance matters. Built simple rather than impressive. Static site. Markdown files. Can maintain this long-term without complex infrastructure.

Community amplifies reach. Beta readers, featured practitioners, and people sharing at launch extend impact beyond what I could achieve alone.

The handbook is what I needed and built. Now it exists for others who need the same thing. That's enough.

Making the web accessible to everyone