Jemima Abu: Give coding agents accessibility rules from the start

Jemima Abu asks the audience to close their eyes and unlock a phone, then to imagine doing so for the first time without knowing where the keys are. The exercise introduces the difficulty of relying on interfaces that assume everyone can see them.

Abu defines accessibility as building products that people can use regardless of disability. Visual, motor, cognitive and hearing disabilities can all expose barriers that a developer using the product in one familiar way might miss.

She cites a finding that 96% of leading websites have accessibility issues and recounts common objections from developers: accessibility takes too long, clients do not request it, or managers have other priorities.

To test her own hypothesis, Abu asked an agent to implement a Figma design twice: once without accessibility guidance and once with a skill she wrote. In her example, the guided run took five minutes rather than 15 and cost 58% less.

Abu immediately qualifies the comparison: it was a one-off experiment in an uncontrolled environment, not evidence that accessible code is always cheaper or faster. Her point is that specific instructions can help an agent follow the desired approach.

Abu introduces herself as a product engineer and certified accessibility professional. She compares an AI agent to a young child sent on an errand: a map, shopping list and clear boundaries help the child reach the intended destination.

For a coding agent, the equivalent is clear guidance about the code and behavior expected. Without it, the agent may generate a large collection of generic elements instead of the semantic structure the developer wanted.

Abu argues that human bias can become AI bias. Developers who test only on their own devices may overlook screen-reader users or people who navigate with a keyboard, and generated code can repeat patterns found in existing code.

She says agents may also produce more custom code than necessary. An accordion-style disclosure can often use the native HTML details element instead of a custom JavaScript implementation, taking advantage of browser-provided behavior.

Her blueberry muffin analogy illustrates why accessibility should be built in from the start. Adding ARIA labels after a site is complete, she argues, is like pushing blueberries onto an already baked plain muffin.

Abu recounts a person switching from one bank to another because the first bank’s app was inaccessible. The customer did not necessarily prefer the second bank’s features; they needed a product they could actually use.

That creates a selection problem for teams: saying no current users rely on assistive technology may overlook people who tried the product, found a barrier and left. Abu compares it to a shop wondering why nobody enters when it has no door.

She also raises legal exposure associated with inaccessible websites and refers to the Americans with Disabilities Act. The precise obligations depend on the organization, service and applicable law; the talk’s broad formulation should not be treated as a legal determination.

Her first recommendation is to define accessibility requirements for the product. A web application and a mobile application may have different needs, so the developer or product manager should identify the relevant standards before prompting an agent.

Second, audit the existing codebase. Abu compares an agent entering a messy project to a new roommate who sees dirty dishes and assumes that is the household norm; existing patterns can become the examples the agent follows.

Third, use a design system or reusable component library. When an accessibility issue is fixed in a shared component, the improvement can reach many pages rather than requiring each instance to be repaired independently.

Fourth, make the requirements mandatory in the agent’s normal workflow. Deadlines make accessibility easy to forget, so the agent should repeatedly receive guidance to build for people with different ways of using the product.

Abu shows a lightweight accessibility skill: use semantic HTML, reach for ARIA when appropriate, and ensure interactive elements work with a keyboard. She says her examples focus on the web and should be adapted to the product.

She also mentions modern web guidance that helps agents choose current browser features, such as details for disclosures. These instructions can improve the starting point, but she cautions that prompts alone do not make a product fully accessible.

During questions, Abu names two frustrations: teams ignoring basic needs, such as keyboard handlers, and teams treating an accessibility overlay as a complete solution. An overlay, she says, resembles adding blueberries after the muffin has already been baked.