Designing for Everyone: How Spruce Approaches Accessibility
Small Frictions, Big Barriers
Light grey text on a white background. A button so small it takes three taps to register. A paragraph so wide the eye loses its place halfway through and has to start the line again. Most people hit all three this week without naming any of them.
Those are accessibility failures. They register on most of us as mild annoyance, the digital equivalent of a sticky door. For millions of others they are the difference between using a service and giving up on it. A contrast ratio a sighted twenty-five-year-old reads without effort can be illegible to a sixty-year-old with early cataracts. A ten-pixel tap target a steady hand hits first time can be unhittable for someone with a tremor.
That gap between annoyance and exclusion shapes how the Spruce Digital Experience (DX) team works. Accessibility is not a phase we schedule near the end, and it is not a checklist a developer inherits two weeks before launch. It lives in the first color we pick and the first wireframe we sketch.
WCAG and the Legal Stakes
The technical foundation for nearly all digital accessibility work is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium’s Web Accessibility Initiative. WCAG is organized into testable success criteria at three conformance levels, A, AA, and AAA, with AA functioning as the practical benchmark for most organizations.
One quirk surprises newcomers: the versions coexist. WCAG 2.0, 2.1, and 2.2 are all current standards, and as the W3C puts it, “WCAG 2.2 does not deprecate or supersede WCAG 2.1, and WCAG 2.1 does not deprecate or supersede WCAG 2.0,” though it encourages using the latest version 1. WCAG 2.2, published in late 2023, added nine new success criteria and retains every criterion before it, so work conforming to 2.1 does not become non-conformant overnight 2. The U.S. Access Board, the federal agency responsible for accessibility standards, noted this followed the seventeen criteria 2.1 had added to 2.0 3.
These are guidelines, not statutes, but American law has absorbed them in several places. The Revised Section 508 Standards incorporate WCAG 2.0 Level AA into the software requirements federal agencies and their vendors must meet, a decision the Access Board reached partly because commenters urged it to adopt WCAG “and only WCAG 2.0, as the complete and sufficient set of accessibility requirements for software” 4. In April 2024 the Department of Justice published a final rule under Title II of the Americans with Disabilities Act with specific requirements for state and local government web content and mobile apps 5. That rule sets WCAG 2.1 Level AA as the standard, with compliance dates arriving in 2026 for larger public entities 6.
For private businesses the picture is less tidy. The Department of Justice (DOJ) has not finalized a parallel Title III regulation. Its guidance says businesses and governments “must ensure that the programs, services, and goods that they provide to the public, including those provided online, are accessible to people with disabilities,” while acknowledging the Department “does not have a regulation setting out detailed standards” and instead applies its longstanding reading of the ADA’s nondiscrimination and effective communication provisions to the web 7. In practice, WCAG is the yardstick regulators and courts reach for.
Spruce DX designs to WCAG 2.1 and 2.2 at Level AA as a baseline, treating it as the floor of professional practice the way a structural engineer treats building code. Compliance describes the minimum a product must do to avoid being a legal problem, not the experience a person deserves when they arrive on your site.
Beyond the Compliance Minimum
Contrast, touch target size, and line length are decisions made early, while a palette and layout are still being chosen.
Three criteria come up on virtually every project we touch, and in each there is real distance between the AA requirement and the AAA one.
Color contrast is the first. WCAG 1.4.3 at Level AA requires text to have a contrast ratio of at least 4.5:1 against its background, relaxed to 3:1 for large text at 18 point or 14 point bold 8. In everyday terms, 4.5:1 is the difference between mid-grey text you can read on a train and the pale grey placeholder text you squint at. The AAA equivalent, 1.4.6, raises that to 7:1 specifically “to provide enhanced contrast for readers with low vision” 9. We check ratios while the palette is still being chosen, when fixing one is a five-minute edit to a single file. Once forty screens and a component library sit on top of that color, the same fix means re-testing every component, state, and exported asset: several days of work for a result that cost nothing in week one.
Touch target size is the second. Success Criterion 2.5.5 has long asked, at Level AAA, for pointer targets of at least 44 by 44 CSS pixels 10. WCAG 2.2 added 2.5.8 at Level AA, requiring at least 24 by 24 CSS pixels and stating that it “helps users who might otherwise have difficulty activating small targets because of hand tremors, limited dexterity, or other motor control issues” 11. We spec 44 in wireframes and components, not 24, because a 24-pixel target is roughly the width of a pencil eraser and it is the one that already makes you tap twice on a moving bus. The larger figure matches what platform owners publish: Google’s Android accessibility guidance, from a company with a commercial stake in its own platform, recommends at least 48 by 48 dp separated by 8 dp or more 12, and its Material Design 3 documentation notes that 48 dp works out to roughly 9mm regardless of screen size, inside a recommended 7 to 10mm range 13. Nine millimetres is about the pad of an adult fingertip, which is the actual reason the number exists.
Line length is the third, and the one clients least expect. WCAG 1.4.8 at Level AAA asks that blocks of text not exceed 80 characters per line, and the W3C’s explanation describes the mechanism rather than just the number: “For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text” 14. Eighty characters is roughly the measure of a paperback page; a maximised browser window on a wide monitor can run past 200. Anyone who has re-read the same line twice on such a screen has felt a mild version of the problem. Readers never notice a well-set column; they only notice the bad one, and usually they blame themselves for losing focus.
Exceeding AA here is a choice, not a reflex. We do not chase AAA across the board, because some AAA criteria impose real constraints on content for narrow benefit. Contrast, target size, and measure are different: the research explains who is helped and how, the design cost of the higher bar is close to zero, and the benefit reaches well past the population the criterion was written for.
Why the Same Failures Keep Recurring
Across the products we have had the privilege of revitalizing, the same three problems recur: text that fails contrast, tap targets that are too small, and body copy running the full width of a desktop viewport. It is rarely that nobody cared. It is almost always that nobody owned it early enough.
Independent measurement shows how ordinary this is. WebAIM, a nonprofit accessibility center at Utah State University, audits the top one million home pages annually. Its 2024 report found low-contrast text below the WCAG 2 AA thresholds on 81 percent of home pages, the most commonly detected issue of any kind, averaging 34.5 distinct instances per page 15. The 2025 report showed modest improvement and no change in the ranking: 79.1 percent still had low-contrast text, averaging 29.6 instances, and contrast remained the single most common failure 16. Thirty instances on a single page is most of a working day of manual remediation once you count locating each one, agreeing a replacement value, and re-testing. Four out of five of the web’s most visited pages are carrying that day of work, on the one criterion that costs nothing to satisfy while a palette is still being chosen.
The reason is structural. Contrast, target size, and measure are all decided in design, but in many organizations accessibility is not a design concern. It is handed to developers during the build or discovered in a QA audit two weeks before launch, at which point the fix is not a color change but a cascade through a design system, a regression test cycle, and a difficult conversation about the release date. The defect was cheap for about a day and expensive forever after.
The W3C treats this as a process question rather than a technical one, describing activities meant to “integrate accessibility throughout the web production process,” applied at project and organisational level and repeated over time 17. Our experience matches that. When these decisions live in the design phase, the conversations are shorter, the changes smaller, nobody negotiates with a launch date, and the product that ships is better. The cheapest accessibility fix in any project is the one that never becomes a fix.
Building From an Accessible Kit
Good intentions do not survive deadlines. Systems do. We design from our own fully accessible User Interface (UI) kit, so contrast ratios, target dimensions, focus states, and text measure are already correct before anyone assembles a screen. A designer pulling a button from that kit does not need to remember the 44 pixel rule, because the button is already 44 pixels. The default is the accessible option, which means accessibility stops depending on whether anyone remembered it on a Friday afternoon.
This is not a boutique idea. The U.S. Web Design System states that it includes “accessibility in all phases of our process” and supplies accessible components, implementation guidance, and tooling to extend that accessibility as agencies customise the system 18. The GOV.UK Service Manual gives teams the same instruction in fewer words, telling them to “think about accessibility from the start” and noting that services meeting government accessibility requirements also satisfy the public sector accessibility regulations 19. When two governments building services for entire populations land on component-level accessibility as the answer, the practice has been stress-tested at a scale no single agency can replicate. We use our kit for the same reason they use theirs: it moves accessibility from vigilance to infrastructure.
Who Is Actually Affected
More than one in four US adults report a disability. They are customers, users, and colleagues, not a separate audience.
Success criteria are easy to discuss as abstractions. They are proxies for people.
The Centers for Disease Control and Prevention reported in 2024, using 2022 Behavioral Risk Factor Surveillance System data, that more than one in four US adults, over 70 million people, reported having a disability 20. An earlier CDC analysis using a narrower set of functional disability types put it at one in four adults, or 61 million people 21. The figure deserves care rather than confident repetition. The Northeast ADA Center, a university-affiliated nonprofit, explains why estimates diverge: the CDC’s “one in four” comes from BRFSS and covers adults 18 and over living in households, while the Census Bureau’s American Community Survey uses a different definition and includes children and the non-institutionalised group quarters population, producing a substantially lower percentage 22. A quarter of American adults report some disability under the CDC’s functional definition, and other credible federal instruments, measuring something slightly different, report less. Either way the population is enormous.
The numbers get concrete against the three criteria. The National Eye Institute reports that about one in twelve men have color vision deficiency 23, roughly two men in a twenty-person meeting, which is why color alone can never carry meaning and why contrast has to be tested rather than eyeballed. CDC’s Morbidity and Mortality Weekly Report estimated that in 2023 roughly 15.5 million US adults, 6 percent, had a current ADHD diagnosis, about half diagnosed at 18 or older 24. Layout choices that reduce the effort of tracking a line of text are no marginal nicety for that group. And the tremor and dexterity limitations WCAG 2.5.8 addresses 11 become more common with age, in a population that is ageing.
None of these people sit outside the core user base. They are the customers, the users, the colleagues, and often the person signing the contract.
Good Design for Everyone
The benefits of accessible design refuse to stay inside the boundary of disability. Captions were built for deaf and hard-of-hearing viewers and now get used by anyone watching video in a loud bar or a quiet office. High contrast text was specified for readers with low vision and pays off for everyone squinting at a phone in sunlight. Generous touch targets were sized for limited fine motor control and help anyone holding a coffee on a moving train. This is the curb-cut pattern: build the ramp for wheelchair users, and parents with strollers, delivery workers with hand trucks, and travellers with rolling luggage all take it without thinking about why it exists.
Our approach fits in a sentence. We use WCAG 2.1 and 2.2 at Level AA as our standard of care, we exceed it toward AAA on contrast, target size, and line length because those choices make a real difference to readability and operability, and we start from an accessible UI kit so the correct decision is also the easiest one. We do it because the alternative is a product that quietly turns away a quarter of the adult population.
Accessibility is not a feature we add for some users; it is the standard of craft we apply for all of them.
If you are working on something where accessibility matters, or you are curious how this fits into our broader research and design process, we would be glad to talk.
Spruce DX is the digital experience division of Spruce Technology, helping organizations design and build accessible, human-centered digital products.
