왼쪽으로 이동하기: 설계와 작업 항목의 a11y

Shift left means moving accessibility work earlier, toward design and planning, instead of bolting it on at the very end. 🌱

Fixing accessibility after a feature ships is the most expensive moment to do it. You retrofit code, retest, and rush, all under pressure.

Most accessibility decisions are made in design, long before code. Color contrast, focus order, and labels all begin in the mockup.

Add annotations to designs: heading levels, reading order, alt text intent, and which controls are buttons versus links.

Designers should check contrast while picking colors, not after. A failing palette caught early saves a painful rework later.

Write acceptance criteria for accessibility right in the ticket, so it is part of the work, not an optional extra someone might skip.

When every ticket lists accessibility criteria, the team treats it as normal work rather than a special favor for a few users.

Fix accessibility once in a shared component, like an accessible button or modal, and every page that uses it inherits the win.

Shift left works best when design and engineering collaborate early, sharing one shared understanding of who the page must serve.

Caught early, accessibility is cheap and calm. Caught late, it is a fire drill. The earlier you act, the less it costs.

Shift left is less a tool and more a habit: asking who might struggle with this, every single time you plan something new.

When is the cheapest time to address accessibility?

Shift left moves accessibility into design and tickets, so it is cheap, normal, and shared, not a costly fix bolted on at the end. 🌱