Teach Your AI Agent to Build Products Everyone Can Use - Jemima Abu, CAIS

Close your eyes, unlock your phone, open the notes app and type hello world. Jemima Abu, a product engineer and certified accessibility professional, gave the room that exercise, then scaled it back. Forget the note. Could people enter their lock password with their eyes closed? She gave them 30 seconds.

With the screen out of view, it was hard to tell what a gesture had done. Even gathering answers exposed a similar problem. Abu couldn't see people nodding, so she asked them to answer aloud. Muscle memory could help someone swipe up and tap familiar key positions. What would happen on a phone they'd never used? A first-time user would need a way to discover where those keys were.

Accessibility means building products that people can use regardless of disability. The phone exercise isolates one assumption about sight. An interface can just as easily depend on a movement someone can't make, a sound they can't hear or an interaction they find difficult to understand. A feature can be present on the device and still be out of reach.

Abu cites a figure of 96% of the top one million websites having accessibility issues. When she asks developers why accessibility gets put off, she hears that a manager won't sign off on extra time, a client hasn't asked for it, or the company has other priorities. Those answers treat accessibility as time added to a build. Abu wanted to see what would happen if an agent received the guidance before it started.

How much work did the agent do on the same Figma design under each condition? On the first run, Abu asked it to implement the design and left the approach up to the agent. That took 15 minutes. On the second, she supplied a skill she'd written specifically for accessibility. That run took 5 minutes, used fewer tokens and cost 58% less.

Abu catches herself before turning that result into a general savings claim. This was a one-off comparison in an uncontrolled environment. The figures describe the work of generating the implementation. How well people could use each result is a separate question. Her reason for giving an agent a skill is more specific: it can settle implementation choices the agent would otherwise have to make for itself.

Abu compares a coding agent to a toddler on a first errand. In the Japanese show Old Enough, a parent sending a child to the supermarket might have walked the route with them, drawn a map or supplied a shopping list. The child knows where to go and what to bring back. A Figma design gives an agent a destination, too. It still leaves room for the agent to reproduce what it sees with a pile of div elements.

Consider where the agent's examples come from. A developer tries a feature on a laptop, clicks through it successfully and ships. Someone navigating with a screen reader or using a keyboard alone may encounter a problem the developer's test never exercised. Models learn from human-written code, including code shipped after just such a test. An agent can reproduce the omission, and a developer using the same test can approve it again. Abu cites 16% of the world's population as having some form of disability.

Take an accordion, where activating a heading reveals or hides content. A custom implementation can use JavaScript to manage that interaction. For a simple disclosure, HTML already provides the details element. The browser handles opening and closing it, which leaves less code to generate and less behavior for the developer to get right. Abu expects an agent to favor the more common custom implementation. A skill can tell it when to choose the native element.

Leaving accessibility until the end reminds Abu of someone serving a plain muffin with blueberries shoved on top. Adding labels to a finished site has much the same limitation. A label can tell someone what a control is called. If the control still responds only to a click, a keyboard user who knows its name still can't operate it.

At a conference, Abu heard from someone who moved from Bank A to Bank B because they couldn't use Bank A's app. Bank A could have had better features and still lost that customer. Being able to use the service settled the choice before a feature comparison mattered.

That departure is easy for a business to misread. A team looks at its customers and concludes that nobody uses assistive technology. People who tried the app, couldn't navigate it and left are missing from the very group the team is looking at. Abu compares it to a shopkeeper wondering why nobody comes into a store that has no door. Inaccessible websites also carry legal risk. She points to US lawsuits under the Americans with Disabilities Act.

1. Define the product's accessibility requirements. A web app and a mobile app can call for different standards and different ways of meeting them. Whoever specifies the work, whether a developer or a product manager, needs to identify the requirements that apply and include them when asking the agent to build.

2. Audit the code the agent will copy. A new roommate who finds dishes piled in the sink learns something about the house rules. Existing components send an agent much the same signal about what the team accepts. Look for accessibility faults in that codebase. An agent can also do a separate pass to find and fix problems in the examples it would otherwise follow.

3. Fix shared components in a design system. A simple reusable library is enough. Suppose 150 pages use the same component. Fix its implementation in the library and all 150 pages get the correction. Independently generated copies would each need attention.

4. Make the guidelines part of every run. Three hours before a deadline is a poor time to rely on someone remembering the keyboard requirement. A standing instruction gives the agent that requirement while it chooses and builds each control, including on the rushed job.

What should the agent do differently the next time it builds a web control? Abu's lightweight skill gives it an implementation preference and a condition the result has to meet.

• Choose elements for their meaning. Start with semantic HTML. For a section that expands and collapses, details tells the browser what interaction to provide.
• Require keyboard operation. Every interactive element must work with the keyboard alone. For the accordion, someone using a keyboard must be able to reach the control, open the content and close it again.

A complementary modern web guidance skill points the agent toward browser features it might overlook. It can suggest details for an accordion or bring popover to the agent's attention when it needs to show content over a page. The accessibility instruction tells the agent how a person must be able to use the control. The browser guidance helps it find an implementation. Abu's examples at 12:29

These prompts reflect Abu's work on the web and need adapting for other platforms. Even on the web, following them can address familiar barriers while leaving others in place. Whether someone can complete a task with the finished product remains the measure of success.

Asked about her biggest frustration with accessibility, Abu starts with a developer giving a div the job of a button and leaving out keyboard handling. Someone with a mouse can activate the control, so the developer may never encounter the failure. The person trying to use the keyboard encounters it every time.

Then she remembers the accessibility overlay, often a small stick-person icon in the corner of a page. It brings her back to the blueberries on top of the muffin. A team can install a conspicuous accessibility widget while leaving that same control unusable. The repair belongs in the control, where the person pressing a key needs something to happen.