Accessibility still needs a human review

An AI-generated interface can look finished very quickly. The spacing feels intentional, the colors work together, and the form has all the requested fields. It is easy to move from that visual confidence to a broader assumption that the experience is ready.

Accessibility asks different questions. Can someone use the interface with a keyboard? Does a control have an understandable name? Can a person recover from an error? Does the reading order still make sense when the visual arrangement changes?

I use AI-assisted development as part of my work, including implementation in my preserved Hoopes Vision website and personal projects. I also think that assistance makes a deliberate review process more important. A screen that looks right is an artifact to inspect, not a conclusion about who can use it.

Start with the task and the interaction

Accessibility work becomes more practical when it is connected to a real task. A checklist is useful, but the product team also needs to understand what someone is trying to accomplish and which interactions stand between them and completion.

Consider a hypothetical event registration form. A participant needs to choose an event, provide required information, understand any errors, and know whether registration succeeded. Each step has accessibility implications. The event choice must be understandable, the form fields need labels, and the final state needs to communicate more than a change in color.

I would walk through that task using different input methods and viewing conditions. That reveals connections between issues. A weak focus state may make an unclear field order harder to follow. A validation message may be present but disconnected from the field it explains. Fixing one visible detail may leave the task difficult.

Use standards as a reference, then inspect behavior

The W3C WCAG quick reference organizes accessibility criteria covering areas such as keyboard operation, contrast, labels, errors, and status messages. It is a useful source for turning broad intentions into specific checks.

For a product team, I would translate relevant criteria into acceptance conditions for the actual interface. A modal needs a clear way to close and a sensible focus path. A drag interaction needs an alternative where required. An error needs to identify the problem in a way the person can understand.

That translation should involve people who understand accessibility implementation and testing. My product role is to make the requirement visible, coordinate the work, and inspect the experience alongside the team. It would be misleading to treat a short manual review or a generated code change as a complete accessibility audit.

Give AI a concrete brief

A request to make a page accessible is too broad to be a dependable implementation plan. I would specify the intended semantic structure, the behavior of interactive elements, and the states that need attention. Existing accessible components can provide a better foundation than asking the system to invent everything from scratch.

For a hypothetical filter panel, the brief might identify the controls, how the result count changes, where focus remains, and how the user clears a selection. The implementation can then be reviewed against those expectations. The team has something more concrete than a visual impression of accessibility.

I would also avoid accepting unnecessary complexity. A custom control may be harder to understand and maintain than a native element that already fits the task. The generated result should justify any additional behavior through a real user need.

Review the parts the screenshot cannot show

Keyboard review is one practical starting point. I would move through a representative task without a pointer and observe where focus goes, whether it remains visible, and whether every required action is available. If the order feels confusing, the issue may be in the document structure rather than the styling.

I would inspect labels and accessible names as well. A familiar icon may communicate a meaning visually, but the control still needs a name that explains its action. Several controls with identical names can be difficult to distinguish even when their placement makes sense on screen.

Dynamic content adds another concern. A loading indicator, validation result, or generated answer may change after the initial page is available. The product needs a way to communicate the change without unexpectedly moving the person or repeatedly interrupting them. The appropriate behavior depends on the task and should be tested with the relevant technology.

Responsive design is more than fitting the width

My BYU Humanities work included planning responsive behavior through annotated wireframes with the Riser team. The project carried content priorities across desktop, tablet, and phone layouts. That experience reinforces a useful distinction: changing the layout should preserve the meaning of the content and the path through the task.

For a new interface, I would also inspect text enlargement and narrow layouts. Labels should remain connected to controls, important actions should remain available, and content should not become unreadable because a fixed arrangement assumed a particular screen size.

AI can help create responsive variations, but those variations need review with realistic content. Long names, translated labels, validation messages, and empty states can expose problems that a tidy sample hides. The review should follow the content the product will actually carry.

Include accessibility in the definition of done

If accessibility appears only at the end of a release, the team may discover that important interaction decisions need to change. I would include relevant checks in design reviews, implementation acceptance criteria, and release planning.

That does not mean every contributor performs the same work. Designers can consider focus, state, contrast, and content hierarchy. Engineers can implement semantic behavior and test interactions. Product leadership can make sure the work has time, ownership, and an appropriate release standard. Specialist review can address questions beyond the team's current capability.

Automated tools can help identify some issues, but they should be part of a wider process. A tool can report a missing attribute without knowing whether a task is understandable. A page can pass a set of automated checks while still creating barriers through its language or workflow.

Learn from people using the experience

The strongest review includes people whose ways of using the product differ from the team's assumptions. A technical inspection can identify implementation issues, while research can show where the overall experience remains difficult.

I would connect those findings to product decisions rather than treating them as a separate list of defects. A repeated need to recover from a confusing state may justify simplifying the workflow. A feature that requires complex gestures may need a different interaction. Accessibility work can reveal a better product structure for many users.

AI assistance can make an implementation change faster. The responsibility to understand and verify that change remains with the team. I want the result to be an experience people can use to complete their work, with clear behavior and fewer assumptions about how they will interact with it. That is a practical quality standard, and it belongs in the product from the beginning.