Accessibility Program Architecture — Lacy, Lead UX Designer

01 — Overview

When Responsibility Became Infrastructure

The moment a practitioner becomes an architect

The Origin

In 2024, accessibility was not yet a structured initiative inside the organization. Federal regulatory pressure had increased urgency around compliance — but internally, accessibility was still treated as something reactive. Teams viewed it as a final-stage checklist item rather than a foundational part of product development.

At the time, I was the only accessibility subject matter expert across a department of more than 200 people.

I began as a practitioner — auditing interfaces, documenting issues, collaborating with developers, and validating fixes manually. But the scale of the problem exceeded what any single contributor could sustain. The product ecosystem spanned thousands of screens, multiple platforms, and highly complex workflows used by students, parents, teachers, and district administrators.

The challenge was no longer simply fixing accessibility issues. The challenge was creating a system capable of preventing them.

Role & Scope

This project became the turning point where my role evolved from UX practitioner into accessibility program architect — building organizational capability, operational systems, shared standards, and long-term cultural adoption.

02 — Empathize

Understanding the Gaps No One Could See

Experiencing failure before designing solutions

Product Accessibility Issues

Before defining solutions, I needed to understand where the failures truly existed. I began by experiencing the product through assistive technologies — screen readers, keyboard navigation, zoom testing, and color contrast validation.

The experience was fragmented and often unusable. Forms lacked accessible names. Navigation patterns broke keyboard flow. Semantic structure was inconsistent. Critical workflows could not be completed independently by users relying on assistive technology.

Organizational & Cultural Gaps

I immersed myself in the organization — observing design critiques, engineering workflows, QA processes, and product discussions. What I found was not active resistance, but a widespread absence of shared understanding.

Discipline	Gap identified
Designers	Understood visual systems but not semantic structure
Engineers	Implemented patterns without understanding assistive technology behavior
QA Teams	Lacked accessibility validation criteria entirely
Leadership	Viewed accessibility as compliance, not design quality

To bridge these gaps, I facilitated accessibility exposure sessions across departments — demonstrating broken screen reader experiences live. Accessibility stopped being theoretical. It became tangible.

Atomic Accessibility Research Framework

Turning testing into decisions — I adapted the Atomic Research model into an accessibility-specific framework. Rather than presenting disconnected accessibility bugs, findings were structured through four progressive layers, transforming accessibility from subjective feedback into actionable organizational decision-making.

Experiment

We tested…

Screen reader, keyboard, zoom, voice control
Fact

We observed…

Measurable interaction failures with % data
Insight

This suggests…

User impact and behavioral implications
Recommendation

We should…

Clear, prioritized remediation actions

Accessibility Testing Inputs

Manual Keyboard Testing

Validate complete non-mouse navigation across all flows
Screen Reader Testing

Evaluate semantic interpretation and announcement accuracy
Voice Control Testing

Assess command discoverability and label clarity
Color Contrast Validation

Ensure visual readability across all states
Zoom / Magnification Testing

Validate responsive scaling at 200–400%
Automated Scanning

Detect technical violations at scale across components

Atomic Research Examples

Experiment Screen reader testing on forms

Fact 63% of inputs lacked accessible names

Insight Users cannot complete forms confidently or independently

Recommendation Standardize accessible naming patterns across all inputs
Experiment Navigation usability testing

Fact 20% of users failed to locate key tasks

Insight Navigation hierarchy lacks sufficient clarity

Recommendation Redesign navigation structure with semantic headings
Experiment A/B testing labels and icons

Fact 40% increase in task engagement with icons

Insight Icons meaningfully improve comprehension

Recommendation Expand icon-supported labeling across the system

03 — Define

Reframing Accessibility as a Systems Problem

Shifting from screens to systems

The Foundational Insight

Once I understood the scale of the problem, I shifted from thinking about screens to thinking about systems. The platform contained thousands of interfaces, making one-off remediation impossible at any meaningful pace.

If we remediate the ~60 core components, we can influence thousands of downstream experiences simultaneously.

I mapped the product into its underlying component architecture, categorizing issues across inputs and forms, navigation systems, data tables, validation patterns, structural hierarchy, and interactive states.

Component Ecosystem Map

Layer	Description	Impact
Components (~60 core patterns)	Reusable UI building blocks	Remediation at this level cascades upward through all higher layers
Templates	Reusable layouts built from components	Inherit accessibility fixes automatically
Screens	Thousands of product views	Improved without screen-by-screen intervention
User Journeys	End-to-end flows	Accessible experiences delivered at scale

Accessibility Responsibility Matrix

Alongside the component architecture, I defined the organizational infrastructure required to sustain accessibility long term. Accessibility stopped being a specialized initiative and became operational infrastructure.

Discipline	Responsibilities
UX Design	Accessibility-first component design, semantic annotation, checklist adoption
Engineering	Semantic implementation, ARIA patterns, keyboard interaction models
QA	Accessibility acceptance criteria, screen reader validation, regression testing
Product	Accessibility in definition of done, roadmap prioritization, SDLC integration
Leadership	Reporting structures, compliance accountability, culture investment

04 — Ideate

Scaling Through Capability Instead of Control

From dependency to distributed ownership

The Strategic Shift

Initially, I personally handled most remediation guidance. But centralizing expertise created a bottleneck. If accessibility relied solely on me, it would never scale.

Rather than scaling output, I focused on scaling capability. The goal: build a system that teaches people to fish.

I designed a UX-centered accessibility training model tailored to the organization's workflows and design systems. The first cohort included seven designers who began with foundational accessibility education before participating in collaborative remediation workshops directly.

These workshops were intentionally hands-on. We reviewed live product components together, identified failures, discussed semantic intent, and explored implementation considerations collaboratively. The process revealed deeper organizational gaps — especially between design intent and engineering execution.

Those early participants became advocates themselves, accelerating broader organizational adoption.

Training Evolution Timeline

Phase 1

Audience

UX Designers

Outcome

Accessibility awareness and foundational knowledge
Phase 2

Audience

UX + Engineering + QA

Outcome

Shared standards and cross-functional language
Phase 3

Audience

Organization-wide

Outcome

Embedded accessibility culture and self-sufficiency

Accessibility at Company SharePoint training portal showing role-specific course modules including ARIA Framework, Design Handoff Accessibility Checklist, Accessible Names and Descriptions, Introduction to Accessible Forms, and general beginner guides for all staff — Documentation Hub — The organization-wide training portal built to sustain accessibility knowledge beyond any single contributor — role-specific modules for Design, Engineering, and all staff, with recommended and optional course paths.

05 — Prototype

Building the Infrastructure for Scale

The program itself was the prototype

What Was Built

The prototype in this project was not a screen. It was the program itself — a suite of tools, systems, and documentation structures designed to outlast any single contributor.

Accessibility Design Checklists — Reframed around UX workflows, not WCAG terminology
Annotated Figma Examples — Pattern library of accessible implementations with annotations
Accessibility Documentation Hubs — Centralized shared knowledge, searchable by stage and component
Testing Workflows — Step-by-step QA processes integrated into sprint ceremonies
Training Materials — Role-specific modules for Design, Engineering, and QA
Monthly Accessibility Newsletters — Keeping accessibility visible across the organization
Shared Remediation Standards — Common language and criteria used across all disciplines

Accessibility Checklist Design

Rather than organizing guidance around WCAG terminology, the checklist was reframed around actual UX workflows and deliverables — making accessibility a natural part of existing design behaviors rather than a layer added afterward.

Design Stage	Checklist Focus Areas
Exploration	Content hierarchy, semantic structure, heading levels, landmark regions
Refinement	Interaction states, focus management, accessible naming, labels
Handoff	Keyboard behavior, ARIA annotations, engineering implementation notes

Accessible Design Checklist document showing a structured table with Theme, Checklist, and Success Criteria columns — covering Interaction States and Visual Design and Perception, each mapping checklist items to WCAG success criteria like 1.4.1, 1.4.3, and 2.4.7 — Artifact — The accessibility design checklist reframed around designer workflows — each theme maps actionable items directly to WCAG success criteria so designers get compliance context without leaving their process.

Leadership Recognition

"Lacy demonstrated Lead UX-level ownership by defining and driving adoption of an Accessibility Design Checklist that helps designers consistently address accessibility earlier in the UX lifecycle. She showed cross-functional influence, systems-level thinking, and long-term organizational capability building."

— UX Leadership feedback, reflecting cross-functional influence and systems-level impact

06 — Test

Embedding Accessibility Into Everyday Delivery

From program adoption to cultural standard

Behavior Change Across Teams

As the program matured, accessibility became embedded into daily operations — not as a separate workstream but as an integrated quality standard across every discipline.

Team	Change
QA Teams	Adopted accessibility acceptance criteria as standard sprint gates
Designers	Began proactively identifying concerns before development began
Engineers	Started considering semantic implementation in early technical planning

The Language Inside the Organization Changed

Before

"Does this look right?"

After

"Is this keyboard navigable?"
"Does this have an accessible name?"
"Will a screen reader announce this correctly?"

That shift represented true cultural adoption. Accessibility had moved from external requirement to shared design quality standard.

Adoption Growth

1 SME

Program Launch
7 Designers

Phase 1 Training
25+ Contributors

Full Org Adoption

Growth from one isolated subject matter expert to 25+ active contributors spanning UX, Engineering, QA, and Product.

07 — Outcomes & Key Learnings

Designing Systems That Continue Without Me

Sustainability as the true measure of impact

Summary of Impact

Within two years, accessibility evolved from a fragmented responsibility into a scalable organizational capability. The outcomes below represent systemic change — not individual heroics.

Accessibility integrated into SDLC — Built into sprint ceremonies, not bolted on at the end
25+ trained contributors — Across UX, Engineering, QA, and Product functions
Standardized remediation frameworks — Consistent criteria used organization-wide
Shared knowledge systems — Documentation hubs that remain operational without ongoing maintenance
Design system governance — Accessibility-aware component standards embedded at the source

Most importantly, the system became sustainable. If I left tomorrow — the training, documentation, standards, and workflows would all continue.

Key Learnings

Scale through systems, not heroics — One expert cannot audit, fix, and maintain an enterprise product indefinitely. Systems, standards, and shared language are the only paths to scale.
Empathy precedes adoption — Live demonstrations of broken screen reader experiences changed minds faster than compliance arguments ever could.
Reframe around workflows, not regulations — Accessibility checklists organized by design stage — not WCAG criteria — achieved adoption because they matched how designers already work.
Build advocates, not dependencies — Training early participants to become internal advocates created an organic multiplication effect that no centralized program could replicate.
Sustainability is the final deliverable — The measure of program success is not what exists while you're there — it's what continues when you're gone.

Accessibility at scale is not achieved through expertise alone. It is achieved by building systems, shared language, and organizational capability that allow inclusive design to continue beyond any one individual.