Jordan had been using the platform for two years by the time the standard was announced. Not easily — with a screen reader that could parse about half of what the interface contained, and a set of workarounds so habitual they had ceased to feel like workarounds. Every week: export the dashboard data to a spreadsheet to read it, update the spreadsheet offline, re-enter the changes manually. Three extra steps for every task a sighted colleague completed in one. The platform was not designed to exclude Jordan. It was not designed for Jordan at all.
The standard arrived as a regulatory document with an eighteen-month compliance window. Jordan did not know about it immediately. There was no reason to. Standards are announced to the organisations that have to meet them, not to the people who will benefit from them.
In Sam’s team, the announcement landed differently.
The response the organisation had prepared
Sam was not against accessibility. Nobody in the team was against accessibility. The resistance was to the timing, the resource, and the assumption that eighteen months was enough to rewrite the parts of the product the standard required. The roadmap was committed. Three major features were already in progress. The compliance work was not budgeted. The concern was not that the standard was wrong but that it had arrived at the wrong moment.
That concern was genuine in its own terms. Within nineteen months, the team would need to audit the full product against the standard’s requirements, identify every failure point, prioritise the remediation work, retest with assistive technology, and document the compliance case. For a product of any complexity, that is not a small undertaking. The estimate that came back from the initial audit was uncomfortable.
What was also in that audit, if anyone looked carefully enough, was a list of things the team had wanted to do but had never been able to prioritise. The keyboard navigation issues that the accessibility standard required to be fixed had been in the backlog for eight months. The plain language requirement had been discussed at two design reviews and deferred both times. The colour contrast failures had been flagged by one of the designers the year before, logged, and then — as things are logged — left there.
The standard had not introduced new problems. It had made existing ones compulsory to address.
There is a pattern here that runs across the history of technology regulation. When the Disability Discrimination Act was introduced, the adjustments it required were widely resisted as disproportionate by the industries subject to them. The Web Content Accessibility Guidelines were described as technically unrealistic for large, complex products. The EU Accessibility Act was described in similar terms by the industries preparing for its June 2025 deadline. Each time, the argument is that the standard is too far ahead of where organisations are. Each time, the organisations that meet the standard find they were closer than they thought — and further from where they should have been.
From compliance to floor
The reframing that changed the team’s view was not philosophical. It came from the user testing.
The standard required testing with the people it was designed to protect. The team arranged the sessions. For most of them, they were the first time anyone had watched someone use the product with a screen reader.
What they saw was uncomfortable. They watched someone work through the same tasks the team had been designing for two years. The time it took, and the places where the screen reader fell silent because there was no text equivalent for a visual element. The workaround that had developed for the dashboard export — not because it was a natural way to work, but because it was the only way to work. The product had been declared a success on every internal metric. From outside the design assumptions that had produced it, it was a product with a secondary interface for a significant portion of its potential users, and that secondary interface was made of spreadsheets and manual re-entry.
The user testing did not produce guilt. It produced information. The team had not known. Now they knew. The standard had been the mechanism that produced the knowledge, and the knowledge changed what the work meant.
The reframe - from compliance burden to design floor - followed from that session. The standard was not telling the team how good the product could be. It was telling them how bad it was no longer permitted to be. One instruction sets a ceiling. The other raises a floor. The team had been treating the standard as the former. It was the latter. Once they understood that, the work changed from meeting a requirement to building from a new foundation.
What the floor revealed
The improvements came in waves. Screen reader compatibility - the most technically complex of the required changes - produced the first unexpected consequence. Making every interface element accessible to a screen reader required auditing the entire navigational structure of the product. The audit found redundancies, dead ends, and paths through the product that nobody had designed and that made no sense to any user. Fixing the screen reader compliance required fixing the navigation. The navigation that emerged was better for everyone.
The plain language requirement produced the second wave. Error messages rewritten for cognitive accessibility were clearer to all users. Support call volume for error-related queries fell within months of the changes going live. The calls had been telling the team something about the product that the product’s own metrics had not surfaced.
Colour contrast was the third. The standard required ratios that the team’s existing palette did not meet. The redesign of the colour system produced a product that performed better in direct sunlight, on low-quality displays, and - as subsequent user testing confirmed - for users over fifty whose colour sensitivity had shifted with age. The team had been designing for a calibrated monitor in a dim office. The contrast requirement forced a wider assumption about where and how people use things.
This is the curb-cut effect: standards designed for a specific group produce improvements that serve a wider population than the standard required. The lowered kerb that allowed wheelchair access also helped people with pushchairs, delivery workers with trolleys, and cyclists. The plain language, the contrast ratio, the keyboard navigation did the same thing. Jordan could use the product. So could everyone else, more easily than before. The floor that had been raised for Jordan turned out to be below where the product should have been all along.
The team had not set out to make a worse product than they were capable of. They had made the product their design process was equipped to produce, for the users their design process had in mind. The standard forced a wider design process. The wider design process produced a better product.
That sequence is not unique to accessibility. External requirements have forced expanded scope and produced better outcomes in electrical safety, food labelling, and data protection. The resistance is always first. The improvement follows.
What a standard is really testing
The question a well-designed standard asks of a technology product is not only whether it is accessible to people with disabilities. That is the specific requirement. The deeper question is whether the product assists the people who use it — all of them, not only the ones whose needs were visible in the original design brief.
A product that cannot be used by someone with a screen reader was, by definition, only helping the users whose circumstances it had accounted for. Meeting the standard did not add an accessibility layer to a complete product. It completed the product for the first time.
The second question is whether the product adds something real to the capability of the people who use it, or only enables interaction. Plain language that reduces cognitive load does not just make the product reachable - it makes it more useful. The user who previously needed three support calls to understand an error message needed none after the change. That is not accessibility as a separate category. That is a better product, full stop.
The third question - the one that runs underneath the history of the Disability Discrimination Act, the Web Content Accessibility Guidelines, and the EU Accessibility Act - is adaptability. A product designed for one profile of user, however carefully designed, is not adaptive. A product that has been required by a standard to respond to a wider range of human circumstance has, in meeting that requirement, become demonstrably more so. The standard did not produce adaptability. It required the work that produced it. That is what a well-designed standard does: it requires the work the organisation would not otherwise do, for the people the organisation had not otherwise considered.
My Opinion
Technology follows the path of least resistance. So does design. We build for the user we imagine, in the circumstances we assume - and that user does not exist. Real people are older, less sighted, less confident, using screens in conditions we did not test for. A standard forces the reckoning with that gap. It should not have to.
Four questions for the next standard
Think of a regulatory or technical standard that applies to technology you build or use. Has meeting that standard improved the product for a wider population than the standard required? If you do not know - would it be worth finding out?
If your organisation is currently resisting a new accessibility or ethical design standard, what is the specific argument against it? Is that argument based on evidence of what the standard would cost and produce - or on an assumption made before the work was done?
If you are involved in setting standards - in government, in industry bodies, in procurement specifications - are the people the standard is designed to protect part of the process by which it is written? And if not, how confident are you that the standard actually requires what those people need?
The argument against technology standards is consistently the argument of the organisation that has not yet had to meet them. What would it take for your organisation to be the one that argues for higher standards rather than against them - and what would that mean for the people your technology is supposed to serve?
Jordan can use the platform now. Not with workarounds. Just - use it. The standard required that as a minimum. The team went further because, once they understood what the floor was, they found the ceiling was higher than they had thought. The standard did not limit what was possible. It clarified what was no longer acceptable.
Authors note
Jordan is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.