Porter-HI1200×1505 99.6 KB

Chris Porter

Accessibility conversations often get pulled toward conformance: did we meet WCAG, did we pass the audit, did Lighthouse complain, did the component technically expose the right ARIA attributes? Those things matter, of course. But the book takes a broader view: accessibility problems usually don’t start at the last QA pass. They start much earlier, in product decisions, information architecture, design systems, component APIs, team ownership, and the way accessibility is treated across the software lifecycle.

A few themes the book gets into:

How accessibility decisions show up in architecture, design, and implementation
Why conformance is necessary but not enough
How teams can make accessibility more durable across components, workflows, and releases
How to think beyond one-page fixes and toward systems that stay accessible as they grow

The book is now available in MEAP, so early readers can follow along as chapters are released and send feedback while the book is still being developed.

I’d love to hear what people here think about this angle. In your experience, where do accessibility issues usually enter the system: design, implementation, product requirements, tooling, QA, or somewhere else entirely?

• Full details: Architecting Accessibility - Chris Porter

Don’t forget you can get 45% off with your Devtalk discount! Just use the coupon code “devtalk.com” at checkout