When accessibility costs one prompt

Quick answer

Most narrow accessibility needs were never hard to build. They were wide: the same small change repeated across hundreds of components, which made them cost days of engineering for a small share of users, and small teams usually declined. AI coding agents can now carry out that kind of sweeping, repetitive change across an entire codebase quickly and accurately, so the cost of accommodating one specific need drops from a week to an afternoon of review. We think that makes going beyond the minimum the reasonable default, and we shipped a student setting that shows text labels on every icon button to test it.

The math that leaves people out

Every software team keeps a list of things it would build if it had more time. Accessibility requests end up on that list more often than anyone likes to admit, and the reason is rarely indifference. It is arithmetic.

Suppose a user tells you that your icon buttons don't work for them. Maybe they use voice control and can't say the name of a button they can't read. Maybe they browse at 400 percent zoom, where the hover tooltip that explains each icon lands off screen. Maybe icons simply don't carry meaning for them the way words do. The fix is obvious: show the label. The fix is also everywhere. A real product has hundreds of these buttons spread across dozens of files, each with its own layout that the new text can break.

Disability itself is not rare. The World Health Organization estimates that about 1.3 billion people, roughly one in six, live with a significant disability. What is rare is any one specific need, and specific needs are what software has to handle one at a time.

That is several days of careful, unglamorous work for a need that a tiny share of your users have. For a team of three trying to ship before the school year starts, that tradeoff gets made over and over, and the narrow need usually loses. Nobody decides to exclude anyone. The work just never reaches the top of the list.

Wide, not hard

Look closely at most long-tail accessibility work and a pattern shows up. Very little of it is technically difficult. It is labeling buttons, fixing focus order, removing hover-only controls, giving every status color a text or shape equivalent, making a timed interaction pausable, or keeping a layout intact when text grows. An engineer who has done it once knows exactly what to do the second time.

The cost comes from breadth. The same small judgment has to be applied correctly in two hundred places, each slightly different, without breaking anything nearby. It is the kind of work that is boring enough for people to get wrong and broad enough to eat a sprint.

That description, small judgment repeated across a large surface, matches almost exactly what current AI coding agents are good at.

What changed

Coding models can now work through a whole repository on their own: read the code, find every instance of a pattern, make the change, run the tests, and report what they touched. They can also split the job. One agent builds the shared piece, others sweep different parts of the product in parallel, and another checks the result against an independent inventory.

That changes what an accessibility request costs. The work used to be a week of an engineer's attention. It is becoming a clear instruction, an hour or two of agents doing the sweep, and a human reviewing the diff and testing the result. The review still matters. But reviewing a correct, complete change is a far smaller job than writing it by hand.

When accommodating one person's need costs an afternoon instead of a sprint, there is no longer a cost-benefit analysis to lose. The reasonable answer to "can you make this work for me?" becomes yes.

We tried it on our own product

We didn't want to publish this argument without testing it, so we picked a need that fits the pattern exactly and shipped it.

Honorly students already have device-level accessibility settings for text size, contrast, motion, spacing, font, and focus. They did not have a way to turn icon buttons into labeled buttons. Copy, speak aloud, attach, and a long list of other actions appeared as icons alone, named only for screen readers. That works for many students. It fails a student who uses voice control, because the visible label has to match the name they say. It fails a student zoomed in far enough that tooltips stop helping, and it fails a younger student who simply doesn't know what the icon means.

The new Show button labels setting puts the word next to the icon for every one of those controls, using the same name a screen reader announces, so what a student sees, says, and hears all match.

Building it took one written instruction to an AI coding agent and about thirty-five minutes of its time. A second agent, working separately, inventoried every icon-only control on the student side so we could check the first agent's work against an independent list. It found 57, spread across the chat, the dashboard, and interactive cards like graphs, flashcards, and quizzes. The first agent added the setting, labeled all 57, translated every label into Spanish, Portuguese, and Vietnamese, and ran the full test suite plus browser checks at classroom and phone widths.

The sweep also turned up problems nobody had asked about. One join-class button had no accessible name at some screen widths, so a screen reader announced nothing at all. About fifteen controls had names that existed only in English, which went unnoticed while those names were invisible. A few tooltips said something different from what a screen reader announced. Each of those got fixed as part of the same change.

Then people reviewed it. Looking at the result in a browser, we caught three layout problems the automated checks had passed, including a round mobile button whose label wrapped one letter at a time. Fixing them took minutes. From the first instruction to a reviewed, working feature took less than an hour.

None of that required a breakthrough. It required someone to decide it was worth doing, and the decision was easy once the cost was this small.

In a classroom, the long tail has a name

In most products a narrow need is a percentage on a dashboard. In a school it is a specific student in a specific class, often with an accommodation written into an IEP or 504 plan, and a teacher who has to make the tools work for that student this week, not next quarter.

That is why this matters to us more than it might to a general software company. A teacher can't hold one child back while a vendor schedules a fix. Software that can adapt quickly to one student's needs fits a classroom better than software that waits until enough users ask for the same thing.

It also connects to how we think about learning in general. Good teaching has always meant adapting to the student in front of you. Software has mostly been unable to do that because every adaptation had to be paid for in engineering time. As that cost falls, software can start to behave more like a good teacher does.

What still requires people

One caution belongs here, because AI-written accessibility code can fail in a familiar way. Accessibility mistakes are easy to make in confident, correct-looking code. WebAIM's annual scan of the top million home pages has repeatedly found that pages using ARIA attributes average more detected errors than pages without them. A model that adds attributes fluently can make a page worse while appearing to improve it. Fast generation makes verification more important.

So the parts that matter most remain human work: deciding what a student actually needs, testing with a keyboard, a screen reader, voice control, and real zoom levels, and above all listening to the people who rely on the feature. Agents make the build cheap. They do not tell you what to build or whether it works for the person who asked.

What we hope becomes normal

Accessibility has a well-known history of features built for a few that turned out to help everyone. Curb cuts, captions, and keyboard shortcuts all followed that path. Microsoft's inclusive design work calls this solving for one and extending to many. Labeled buttons will likely follow it too, helping a tired student on a cracked Chromebook screen as much as the student who needed them first.

Our hope is broader than our own product. If every team can accommodate a narrow need in an afternoon, then "we don't have the resources" stops being a reasonable answer for anyone, including small companies, school IT departments, and solo developers maintaining a tool their district depends on. Meeting the minimum standard becomes the starting point, and going further becomes ordinary.

That is also a commitment we are making for Honorly. If something gets in a student's way, tell us. Teachers can use the Feedback button in the teacher dashboard, and anyone can reach us through our contact page. Those messages go directly to the people who build the product, and a person answers, never a support bot or AI agent. Our support is human around the clock, and that matters most for requests like these.

We are a small team, and we intend to keep acting like one. A request that affects one student in one classroom deserves a real answer, and now it can usually be a fix. It no longer has to compete with a week of engineering time, and we would much rather hear about it than have a student quietly work around it.

Frequently asked questions

How do AI coding agents help with accessibility?

Much accessibility work is a small, well-understood change repeated across hundreds of components: labeling controls, fixing focus order, removing hover-only interactions. Coding agents can find every instance across a codebase, apply the change consistently, and run tests, which turns days of manual work into a short build and a human review.

Can AI make a website accessible on its own?

No. Agents make the implementation fast, but deciding what users need and verifying the result with real assistive technology and real people is still human work. Generated code can add accessibility attributes that look correct and still make the experience worse, so testing matters more, not less.

What does the Show button labels setting do in Honorly?

It is a student accessibility setting, stored on the device, that shows a text label next to every icon-only button in the student workspace. The visible label matches the name screen readers announce, which helps voice-control users, students using high zoom, and students who find icons hard to interpret.

Why does this matter for schools in particular?

In a school, a narrow accessibility need belongs to a specific student, often with a formal accommodation, and the teacher needs the tools to work now. Software that can adapt quickly to one student's needs fits classrooms far better than software that waits for enough users to ask.