Accessibility Isn’t a Checkbox: Lessons from Spotify’s Encore Overhaul

When Spotify’s Encore design system team set out to improve accessibility, they didn’t just run automated scans and call it done. They brought in Tamas, a blind engineer and web accessibility expert, to work directly with the team. The collaboration—alongside Encore engineer Rose and product manager Arielle—produced a stack of practical lessons about what accessibility really means for a design system, and why it’s rarely a simple pass/fail proposition.

The project’s goal was straightforward on paper: give teams as much out-of-the-box accessibility as possible, and when full enforcement isn’t feasible, provide the best possible guidance. In practice, the team found that even the most careful component design has limits when you can’t predict how a component will be used across dozens of products.

Enforcing vs. Educating: The Core Tension

The biggest challenge for the Encore team was reconciling two competing needs. On one hand, baking accessibility directly into components is the most reliable way to ensure it happens. On the other, Encore’s components are stateless and deliberately flexible—they need to work across a wide range of contexts. Building every version of every component with full accessibility baked in simply isn’t scalable.

That leaves documentation and examples as the primary tools for situations where enforcement isn’t possible. The team accepted that they can’t have it both ways: expecting every product team to understand accessibility deeply doesn’t guarantee consistent quality across the board, but neither can a design system shoulder the entire responsibility. The practical middle ground is to build in whatever safeguards are possible while clearly documenting where the remaining responsibility lies.

Why Native Semantics Win—Even When Styling Is Painful

One recurring friction point the team observed: developers often avoid semantic HTML because native elements like <button> require CSS reset work. Using a <div> instead feels cleaner initially. Tamas pushed back hard on this pattern.

When you skip the button element, you inherit responsibility for implementing spacebar and enter key handling, focus management, and ARIA roles—all of which must be kept in sync with the visual behavior. Over time, maintaining that custom JavaScript and styling typically creates more work than simply styling the native element. The native version might need more initial restyling, but it eliminates a whole class of accessibility issues that can arise from custom implementations.

Compliance Is Not the Same as a Good Experience

A key realization throughout the project was that passing compliance checks doesn’t equal a well-designed experience for assistive technology users. Rose noted that pure compliance misses context—a valid tab index number still might not make sense in a particular application. Automated scans can flag a range of issues, but they can’t tell you whether keyboard navigation is optimal for a given layout.

The team shifted from treating accessibility as a set of compliance criteria to treating it as user experience work. That means asking questions like whether users should tab through every interactive element sequentially, or whether arrow-key navigation would be more efficient for a particular pattern. Tamas pointed to the chip component, which tends to get repurposed for all sorts of edge cases, as an ongoing example of unpredictable usage that makes enforcement difficult.

New Standards Don’t Automatically Mean Better Accessibility

Both engineers emphasized that modern, widely adopted web standards can still introduce accessibility problems. Flexbox, for example, made it much easier to visually reorder content in ways that break logical document flow. Just because a technique is popular and browser-standard doesn’t mean it can’t promote poor practices.

There’s also a dangerous middle ground: developers who care about accessibility and add attributes or roles without actually testing the result can make things worse. Incorrect ARIA usage is actually an increasing problem, according to WebAIM’s ongoing research into the top million websites. More sites are applying invalid roles and semantics to their <div> elements without understanding which ARIA rules apply where.

Practical Steps for Teams Without a Dedicated Expert

Tamas and Rose offered concrete advice for teams that don’t have an accessibility specialist on hand:

  • Learn basic screen reader testing. You don’t need mastery of 50 commands—knowing around 10 to 15 to tab through content, activate elements, and navigate by heading or landmark is enough to identify fundamental problems. It may feel overwhelming at first, but getting past the initial intimidation pays off quickly.
  • Break the assumption that all keyboard users are screen reader users. Many people use keyboards due to fatigue, arthritis, or invisible disabilities that make precise mouse movements painful. A keyboard-only user and a screen reader user have different needs.
  • Use free reference materials. WebAIM’s screen reader testing guides and its Million report (charting accessibility trends across top websites) are good starting points. Missing alt text and insufficient color contrast remain persistently common issues.
  • Recognize that you’ll never be finished. Accessibility knowledge evolves, and new tooling keeps changing what’s possible. Building accessibility into a regular workflow—rather than treating it as a one-time milestone—is the realistic approach.
  • If budget is low, start with one person. Having a single team member who develops expertise and shares documentation creates a multiplying effect that benefits the entire organization.

Teams that entirely own their accessibility also benefit from clear communication practices. One practical adjustment from the collaboration: describing what’s on screen verbally rather than relying on visual cues or cursor movements. This helps not only blind collaborators but also everyone else in the room.

As the team sums it up, accessibility is ultimately about building a culture where it’s part of day-to-day conversation—not a checklist item that happens when it gets asked about, or a task for a single person to police. With more people testing basic screen reader flows and making incremental improvements, the quality bar rises across the board. The design system can provide strong defaults where it can, and guidance where it can’t—but the responsibility for each product’s overall accessibility ultimately rests with the teams who build it.