Accessibility and performance: why they should be designed together

Accessibility and performance are often assigned to different moments in a project.

First the website is built. Then someone tries to speed it up. Finally, perhaps, someone checks whether it works with a keyboard. That order is convenient because it spreads problems over time. It is not a very effective order.

The two areas share many of the same decisions: how much JavaScript to load, how to build markup, which images are truly needed, how interactive components behave, what happens on a slow connection or without a mouse, and whether content remains available when a script does not run.

Content should exist before the effect

An accordion, popup, tab or carousel should not depend on a JavaScript performance merely to make the primary information readable. When content already exists in the markup and the script adds interaction progressively, a site has a stronger starting point: fewer unnecessary dependencies, clearer fallbacks and more predictable behaviour.

That is one of the principles behind Lumen ARIA Blocks, the Gutenberg plugin I published on WordPress.org. Its blocks keep content server-rendered and add interaction progressively; assets load only when their block is present. Keyboard use, focus, ARIA states and reduced-motion preferences are not details to add later. They change how a component is designed.

That does not automatically certify a complete website. It does mean that some technical contracts have been placed where they belong: inside the component and in the release process.

Useful speed, not only a score

Reducing bytes and requests matters, but it is not enough to create a good experience. A page can receive a high score while leaving someone without form labels, visible focus, or useful feedback when an error blocks an action.

Likewise, an accessibility fix that adds libraries, animations or redundant controls without a clear reason can make a website slower and harder to maintain.

That is why it helps to work from shared decisions:

• semantic HTML before unnecessary ARIA roles;
• properly sized and compressed images without removing useful text alternatives;
• interactive components with real focus management;
• JavaScript loaded only where it is needed;
• motion that respects `prefers-reduced-motion`;
• forms with understandable labels, errors and states;
• testing on devices and connections less forgiving than the developer’s workstation.

Maintenance is part of quality

A website does not remain accessible and fast simply because it was on launch day. Core software, plugins, browsers, content and images change. Even a seemingly small edit can introduce low contrast, a layout regression, an incorrect redirect or an asset that blocks loading.

For e-commerce and WordPress systems such as IvoryLab Guitar Shop, quality also means controlled updates, checkout and payment checks, LCP/Core Web Vitals, accessibility, analytics and compatibility. It is not the most photogenic part of a project, but it prevents having to explain why a sale or contact quietly disappeared.

That is why accessibility and performance belong both to on-site SEO and WordPress maintenance. Not as separate checklists, but as requirements of a system that needs to keep working for real people.