Accessibility as Engineering

Retrofitting accessibility into this site has been less about fixing a collection of bugs and more about evolving a mental model. As this series concludes, I have realised that accessibility literacy is a shift in how I approach engineering.

Beyond the Checklist#

When I began this initiative, I framed the problem around the 'what': which attributes to add, which roles to define, and which WCAG clauses to satisfy. The shift came from applying a familiar principle: focusing on the 'why' rather than the 'what' in a domain where I had not yet done so.

Accessibility became a fundamental quality of engineering rather than a final compliance pass. Checklists helped me identify specific gaps, but developing a mental model of how the browser interprets structure ensured the implementation remained sound. By understanding how the browser interprets code, I moved from reactive patching to proactive, inclusive design built into the foundation of the system.

The Browser as Stakeholder#

I already thought in terms of stakeholders, but I had not applied that lens to the browser itself. Once I did, it changed how I read my own code. The browser is constantly interpreting it to build the Accessibility Tree, synchronise programmatic state, and respect system-level preferences.

Treating the browser as an active participant in the user experience means working with its defaults rather than against them. This perspective shift makes accessibility feel like a natural extension of software architecture rather than an external imposition or a visual afterthought.

Systems over Intentions#

In my experience, "I will remember to do this" is a dangerous phrase in software development. Systems need memory, and in anything more than a trivial project, that memory must be encoded in the architecture.

By moving accessibility guarantees upstream into the content pipeline, the linting configuration (with eslint-plugin-jsx-a11y), and the automated test suite, I have removed the risk of human error. Automation and architectural constraints are about integrity as much as efficiency. They ensure that the inclusive experience I have built survives the next update, the next redesign, and the next moment of forgetfulness.

What I would do differently#

If I were starting this project again, I would design in accessibility from day zero. This is not a new lesson. Retrofitting any quality concern into an existing system is harder than building it in from the start, but accessibility makes that cost especially visible.

I would also avoid the temptation to over-engineer complex ARIA roles early on. Starting with clean, semantic HTML and landmark disambiguation provides the vast majority of the value with minimal complexity. Accessibility is often a matter of doing less, but doing it more intentionally and with greater technical awareness.

Further Reading#

A handful of resources that were instrumental in shaping my understanding.

Mental Models and Systems Thinking#

These resources helped me move from implementation details to high-level architectural thinking.

• Inclusive Components (Heydon Pickering)(opens in a new tab): A thorough exploration of how to build common UI patterns with accessibility at the core, treating components as small systems with their own invariants.
• Resilient Web Design (Jeremy Keith)(opens in a new tab): A philosophical foundation for building sites that survive the unpredictability of the web, placing accessibility within the broader context of technical resilience.

Browser Behaviour and Semantics#

Understanding the "how" requires understanding how the browser processes and exposes structure to assistive technologies.

• The Accessibility Tree (MDN)(opens in a new tab): The foundational reference for how browsers translate HTML into the structure used by assistive technologies.
• WAI-ARIA Authoring Practices Guide (APG)(opens in a new tab): The definitive reference for how interactive components should behave and communicate state.

Automation and Invariants#

Starting points for encoding accessibility guarantees into the pipeline.

• Unified(opens in a new tab) and Rehype(opens in a new tab): The tools used on this blog and discussed in this series to automate structural integrity via AST manipulation.
• Playwright(opens in a new tab) and axe-core(opens in a new tab): The combination for running automated accessibility audits against a live site to catch regressions in the rendered output.
• Testing Web Accessibility (Deque University)(opens in a new tab): A deep dive into verifying assumptions through both automated and manual audits.