Skip to content
arrow_back Back to writings
06 MIN READ · 342 words
Listen to Article
click play to listen

Accessibility as an Engineering Pillar

Why accessibility is a technical requirement, not a design afterthought. Implementing automated testing, ARIA best practices, and building keyboard-navigable design systems.

A11Y UI/UX

Web accessibility (a11y) is often relegated to a checklist completed at the end of a project. However, treating accessibility as a core engineering requirement—rather than an afterthought—improves overall code quality, boosts SEO ranking, and ensures compliance with legal standards (like WCAG 2.2).

Semantic HTML over ARIA Attributes

The single most effective way to make a website accessible is to write semantic, valid HTML. Browsers use semantic tags to build the Accessibility Tree, which screen readers parse directly.

<!-- INCORRECT: Non-accessible custom button -->
<div onclick="submitForm()" class="btn-submit">Submit</div>

<!-- CORRECT: Accessible standard button -->
<button onclick="submitForm()" type="submit">Submit</button>

When you use the <button> element:

  • Keyboard focus is handled automatically (users can tab to the button).
  • Screen readers declare the element as a button.
  • The button is activated by pressing the Enter or Space key automatically.

Only use ARIA roles and properties when standard semantic elements cannot satisfy the requirements.

Focus Management and Keyboard Navigation

Users navigating via screen readers or switch controls rely entirely on keyboard accessibility. Interactive elements must:

  1. Have Visible Focus Styles: Never set outline: none; without providing a visible focus indicator.
  2. Support Standard Tab Cycles: Keyboard focus must travel in a logical reading order.
  3. Prevent Focus Traps: Ensure modal overlays capture focus and restore it to the original triggering button upon closing.

Automated Accessibility Testing

To ensure accessibility does not regress during feature updates, integrate automated testing tools into your CI/CD pipelines:

  • Lighthouse CI: Performs static checks for contrast ratios, image alt descriptions, and document heading hierarchies.
  • axe-core / Playwright: Automates browser checks. You can write functional tests that fail if a11y violations are discovered.
// A simple Playwright assertion using axe-core
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('page should have no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

A accessible system is a robust system. By building semantic interfaces, you ensure your software remains usable for all users.