Performance and Accessibility: Two Yields from One Season

The shared harvest

Performance and accessibility are usually treated as separate disciplines: one owned by the engineering team measuring milliseconds, the other owned by the UX team running screen reader tests. But the Venn diagram of techniques that improve both has a surprisingly large overlap.

When you optimize for one, you often improve the other. That's not a coincidence. Both disciplines share the same root goal: making the web work well for everyone, regardless of their device, connection speed, or abilities.

Where the circles overlap

Semantic HTML

Semantic elements are smaller and faster to parse than heavily nested <div> structures with ARIA attributes bolted on. A native <button> is a few bytes of HTML with built-in keyboard handling, focus management, and screen reader announcements. A custom <div role="button" tabindex="0"> requires additional JavaScript for keyboard events, more CSS for focus styles, and more HTML for ARIA states. The semantic version is faster to load, faster to parse, and more accessible by default.

Reduced JavaScript dependency

Heavy JavaScript bundles hurt both performance (longer parse and execution time, delayed interactivity) and accessibility (screen readers and assistive technologies interact with the DOM, not with JavaScript-rendered shadow content). Server-rendered HTML with progressive enhancement serves both goals: faster initial load and a solid, accessible foundation from the first byte.

Image optimization

Properly optimized images improve LCP metrics and page load times. But image optimization for performance (using srcset for responsive images, setting width and height to prevent layout shifts, lazy loading below-the-fold images) also benefits accessibility. Explicit dimensions prevent the content reflows that disorient screen magnifier users. Alt text (an accessibility requirement) also gives search engines context when images fail to load.

Reduced motion

The prefers-reduced-motion media query respects users who experience motion sensitivity (vestibular disorders, migraines, and other conditions triggered by animation). Reducing or eliminating animations also reduces the GPU and CPU work the browser has to do, improving performance on low-end devices. Accessibility preference, performance benefit.

Efficient CSS

Smaller CSS files load faster and reduce render-blocking time. But smaller CSS also tends to mean simpler CSS: fewer specificity wars, fewer overrides, fewer !important declarations. Simpler styling is easier to maintain, easier to test for accessibility, and less likely to produce the visual conflicts that create contrast failures or hidden focus indicators.

The disability-device spectrum

Here's a framing that changes how teams think about both disciplines: disability and device limitations exist on the same spectrum of constrained access.

• A user with low vision needs high contrast. A user on a low-quality outdoor screen also needs high contrast.
• A user who navigates by keyboard needs focus indicators. A user on a TV remote input also navigates by focus states.
• A user on assistive technology needs semantic, well-structured HTML. A user on a 2G connection also benefits from lightweight, semantic HTML that renders fast.
• A user with a cognitive disability needs clear, simple layouts. A user multitasking on a small phone screen also benefits from reduced complexity.

When you build for the extremes of this spectrum, everyone in between benefits. That's universal design in practice.

Measuring both

The tools for measuring performance (Lighthouse, Core Web Vitals, PageSpeed Insights) and the tools for measuring accessibility (axe, WAVE, eiSEO) are converging. Lighthouse already includes both performance and accessibility audits in the same report. eiSEO combines SEO analysis with WCAG compliance scanning.

This convergence reflects reality: the healthiest websites are the ones that score well on both dimensions, because the techniques that drive improvement are the same techniques: semantic markup, efficient assets, progressive enhancement, and thoughtful design for constrained environments.

One field, one season, two yields

You don't need separate budgets, separate sprints, or separate teams for performance and accessibility. Build with semantic HTML. Optimize your assets. Reduce your JavaScript dependency. Test with assistive technology and on slow connections. The investment is shared, and the returns come from both directions.

One season of intentional, well-structured work. Two yields worth harvesting.