&w=3840&q=80)
Accessibility carries a lot of assumptions that do not hold up when you look at them closely. It is too expensive. It only matters for a small group of users. It will make the product look worse. It is something you handle at the end, once everything else is done.
These assumptions are common, and they shape real decisions about when to prioritise accessibility and how seriously to take it. Most of them are wrong.
Accessibility only matters for users with disabilities
This is the assumption that keeps accessibility permanently low on the priority list. If the audience is small, the business case feels weak. But the audience is not small – and it is not neatly defined.
The same heading structure that helps a screen reader user navigate a page also helps search engine crawlers understand it. Keyboard navigation built for someone with a motor impairment also works for a power user who prefers not to reach for a mouse. Sufficient contrast that serves a visually impaired user also helps someone reading on a phone in bright sunlight. Captions added for a deaf user also work for someone watching a video in a quiet office.
When you design for the edges of the capability spectrum, you improve the experience for everyone in between. This is the point of accessible design.
Accessibility is a project with an end date
A team runs an audit, fixes the flagged issues, marks it complete – and six months later the same categories of problems have reappeared in new features built by developers who were not part of the original fix. This pattern is common, and it happens because accessibility was treated as a deliverable rather than a standard.
Accessibility needs to be present at every stage: in how designs are specified, how code is reviewed, how releases are tested, and how new team members are onboarded. That requires genuine organisational commitment – leadership that treats it as a real requirement, not a compliance checkbox, and processes that make it part of how work gets done day to day.
The teams that sustain accessible products over time are not the ones that ran the most thorough initial audit. They are the ones that stopped treating it as a project.
Accessibility is something you add at the end
By the time accessibility is treated as a finishing step, most of the decisions that determine how accessible a product will be have already been made. Colour contrast is set in the design system. Interaction patterns are established in early sprints. Heading hierarchy is baked into CMS templates. Navigation structure is defined in the information architecture.
None of these are easy to change late in a project. Some require rebuilding rather than patching. Accessibility considered from the start adds a small amount of forethought to decisions that are being made anyway. Accessibility added at the end adds a large amount of rework to decisions that have already shipped.
And in practice, last-minute accessibility fixes often do not happen at all. They get deferred to the next release, and then the one after that.
Building accessibly is too expensive
The cost framing here is usually backwards. The question is not whether accessibility costs money, but when and how much of it is spent.
Fixing an accessibility issue during design is cheap. The same issue found in production costs significantly more. Found in a legal filing, the cost includes not just the fix but legal fees, potential fines and the management time diverted to handling it. Organisations that have been through accessibility litigation consistently find that the remediation cost far exceeds what it would have taken to build correctly the first time.
There is also the quieter cost of not building accessibly: users who leave without explanation, organic traffic lost to structural issues, conversions that never happen. These don’t show up as line items, which makes them easy to ignore. Still, they are real.
Accessible design means the product will look worse
Most of what makes a product accessible is invisible in the rendered interface. Alt text, label associations, ARIA attributes, logical reading order, semantic HTML; none of these have any visual presence at all. They affect how a product is understood and navigated by assistive technologies, not how it looks on screen.
The accessibility requirements that do affect visual design – contrast ratios, focus indicators, text sizing – are real constraints. But they are constraints that experienced designers work with rather than around.
The products that look like accessibility was bolted on are the ones where it actually was. That is a timing problem, not an accessibility problem.
Conclusion
It’s important to note that none of these misconceptions come from bad intentions. They come from assumptions that have never been tested against how accessibility actually works in practice.
When you look at them closely, the pattern is consistent: accessibility is cheaper, broader in impact and more compatible with good design than most teams assume. And it’s not something you can really finish. You need to build it into how you work. That shift in thinking is worth more than any single audit or remediation sprint.
