# Architecting Accessibility (Manning)

**URL:** <https://forum.devtalk.com/t/architecting-accessibility-manning/248199>\
**Category:** Frontend Learning Resources\
**Tags:** a11y, webaccessibility, inclusivedesign, wcag, digitalaccessibility, webdevelopment, published-book, accessibility, manning\
**Created:** [23 July 2026 13:10 UTC](https://forum.devtalk.com/t/architecting-accessibility-manning/248199 "2026-07-23T13:10:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ManningBooks](https://forum.devtalk.com/user_avatar/forum.devtalk.com/manningbooks/32/1650_2.png) [@ManningBooks](https://forum.devtalk.com/u/ManningBooks)\
**Post date:** [23 July 2026 13:10 UTC](https://forum.devtalk.com/t/architecting-accessibility-manning/248199/1 "2026-07-23T13:10:38Z")

</div>

_Architecting Accessibility_ shows you how to build web applications that work for everyone. Rather than treating accessibility as a checklist, this important book offers simple and practical design decisions to break down the real barriers that challenge users who experience difficulty with sight, hearing, or mobility.

 ![Porter-HI](https://forum.devtalk.com/uploads/default/original/2X/8/8aebbc38003e02fc812060a6965d87a4edb65cf8.jpeg)

### 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](https://www.manning.com/books/architecting-accessibility)

_Don’t forget you can get 45% off with your Devtalk discount! Just use the coupon code “**[devtalk.com](http://devtalk.com)**” at checkout 👍_