Two interfaces can look identical in a screenshot and diverge completely in how they were built. One team chose the right native element on the first commit, wired every label and focus target as the feature went in, and shipped something a screen reader user can operate without a workaround. The other team shipped a demo, waited for an audit, and is now retrofitting roles, key handlers, and focus traps onto a codebase that was never designed to carry them.
The retrofit costs more than the schedule shows. An audit reports the paths a scanner and a tester happened to exercise that day, not every path through the application, so a retrofit habitually patches what was found and leaves the same defect one click deeper in the flow. Building accessible from the first commit makes the fix true everywhere the pattern repeats, not only where someone looked.
| Dimension | Built accessible | Retrofitted after audit |
|---|---|---|
| When the decision is made | At design and first implementation | Months later, against a deadline |
| What gets fixed | The pattern, everywhere it recurs | The instances a scanner or tester happened to find |
| Cost | Marginal, folded into normal build time | High: rework, regression risk, re-testing |
This course installs four habits that make "accessible by construction" a repeatable practice instead of a slogan.
None of these habits need new tools. They need one decision, repeated at each piece of markup: does the platform already solve this? Most of the time it does.