Source: [AI-generated internal tools: check accessibility through the whole task — Skills for Business]() [← All articles](https://skillsforbusiness.ai/blog/) Development · Guide # AI-generated internal tools: check accessibility through the whole task Review AI-generated workplace interfaces beyond their screenshots. Check keyboard access, labels, focus and error recovery across a complete employee task. [Skills for Business](https://skillsforbusiness.ai/blog/editorial/)31 October 20267 min read On this page 1. [Research illustrates why the rendered behavior matters](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#research-illustrates-why-the-rendered-behavior-matters) 2. [Write the employee task before reviewing the interface](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#write-the-employee-task-before-reviewing-the-interface) 3. [Check the dialog as an interaction, not a decorated panel](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#check-the-dialog-as-an-interaction-not-a-decorated-panel) 4. [Combine scans with observed task completion](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#combine-scans-with-observed-task-completion) 5. [Give the coding assistant a reproducible defect](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#give-the-coding-assistant-a-reproducible-defect) 6. [Keep the release record narrower than the claim](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#keep-the-release-record-narrower-than-the-claim) 7. [Sources](https://skillsforbusiness.ai/blog/ai-generated-internal-tools-accessibility-task-checks/#sources) What to take away - Define an employee task and test its changing states, including validation errors, cancellation and completion. - Combine automated findings with keyboard and assistive-technology checks; a clean scan is not a complete accessibility assessment. - Record the environment and what was actually checked, keeping unavailable checks explicitly unverified. Before releasing an AI-generated internal tool, check whether an employee can complete a real task using a keyboard and appropriate assistive technology. Follow the task through its changing states: opening a form, finding controls, correcting an error, submitting successfully and returning to the surrounding work. A polished screenshot shows only one part of that experience. For a business using coding assistants or AI interface builders, the decision is what evidence allows a generated workflow to move beyond a demonstration. Accessibility belongs in that decision alongside functional behavior. An equipment form that works only with a mouse still leaves some employees unable to make the request themselves. This guide proposes an initial acceptance review using a fictional equipment-request dialog. It is not a comprehensive accessibility audit or a claim about legal conformance. We have not tested an AI builder, generated a working application or conducted a screen-reader evaluation for this article. ## Research illustrates why the rendered behavior matters Ahmed and colleagues’ [From Code to Compliance case study](https://arxiv.org/html/2501.03572v2), in its July 2025 revision, examined a GPT-4o-generated television-series webpage and iterative attempts to fix it. The authors combined automated tools with manual keyboard and screen-reader-extension checks. They reported that some issues required more complex correction than others. The study involved one model, a particular page and prompting process, with subjective author judgments in manual evaluation. It does not estimate today’s error rate across AI builders, and it is not evidence of testing with disabled employees. Its useful lesson for this guide is methodological: inspect interaction and context as well as automated findings. W3C’s [Easy Checks guidance](https://www.w3.org/WAI/test-evaluate/preliminary/) includes keyboard access, visible focus, forms, labels and error handling. It explicitly says these preliminary checks are not definitive: a page can pass them and still contain significant barriers. We therefore use a bounded task review as an entry point, with more thorough evaluation where required. ## Write the employee task before reviewing the interface For the fictional tool, define the task as: “Request a standard keyboard, correct a missing department, confirm the request was recorded, and return to the request list.” Use synthetic records and a test environment. The review should not send real orders, change employee records or expose personnel information to an unapproved testing service. List the states the task reaches, not just the pages in the navigation. A request form may look correct when empty yet become difficult to use after a validation message appears. A confirmation may be visible on screen while remaining undiscoverable to someone using a screen reader. These are proposed failure cases to investigate, not incidents we observed. Agree which browsers, operating systems and assistive technologies the team needs to support. Record the combination used in each check. A pass in one setup is evidence about that setup, not a guarantee for every screen reader, browser or input method. Give the developer observable expectations. “Make it accessible” is a useful goal but an insufficient acceptance record. Specify what someone should be able to find, understand and activate at each step. Let accessibility specialists help define appropriate requirements rather than asking an AI assistant to invent the standard of success. ## Check the dialog as an interaction, not a decorated panel The [WAI-ARIA modal-dialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) describes moving focus inside an opened dialog, containing its tab sequence, supporting Escape to close, providing a name and returning focus appropriately when it closes. Focus containment during an active modal is intentional; the user must still have a keyboard-operated way to close it and continue the workflow. The following is our proposed task checklist for the fictional tool. It translates that interaction guidance into business states and adds the example’s validation and completion requirements. | Task state | Observation to check | Failure to investigate | | --- | --- | --- | | Open request | Keyboard opens the dialog; focus moves inside and its purpose is identifiable | Dialog appears visually while focus stays behind it | | Enter details | Controls have understandable labels and can be reached and operated | An icon or custom selector has no usable keyboard behavior | | Submit with missing department | The error is discoverable, identifies the problem and permits correction | A red border appears without an understandable explanation | | Submit corrected request | The employee can discover confirmation and verify the recorded request | A temporary visual message is the only completion evidence | | Cancel and resume | Keyboard closes the dialog and focus returns to the agreed logical place | Focus disappears or the employee cannot continue from the request list | For this invented design, cancellation must not create a request. That is an additional functional requirement, separate from focus behavior. A review should preserve both: a dialog can be keyboard-operable while submitting the wrong data, or functionally correct while blocking keyboard use. Do not treat the presence of an ARIA role as proof that the interaction works. Inspect the actual behavior in the rendered application. A visual overlay and a `dialog` label cannot by themselves establish that focus, keyboard handling and the background content behave as intended. ## Combine scans with observed task completion Run an appropriate automated accessibility checker on the relevant states and investigate its findings. Where practical, include those checks in the development workflow so known failures are detected again after changes. Keep the configuration and results with the tested version rather than retaining only a green badge. Then perform the keyboard task without switching to the mouse when navigation becomes inconvenient. Follow focus, activate controls, trigger the error and recover. Record the exact step that fails. A report such as “after opening the selector, Tab moves behind the dialog and the department cannot be chosen” is more actionable than “accessibility needs improvement.” Have a knowledgeable evaluator perform the corresponding screen-reader task in a supported setup. Check whether the dialog’s purpose, field labels, validation feedback and completion result can be understood in context. A name being present in the accessibility tree does not settle whether it is meaningful to someone completing this task. Glenda Sims’ [2024 Deque practitioner article](https://www.deque.com/blog/the-goldilocks-zone-achieving-an-accessible-digital-future-in-the-ai-age/) argues for combining automation with human scrutiny rather than relying exclusively on either. Deque sells accessibility products; its product-performance and speed claims are vendor statements, not independent validation. We use the mixed-review perspective without adopting those claims or recommending a particular product. ## Give the coding assistant a reproducible defect When a check fails, supply the relevant component, the starting state, the actions taken, the observed result and the expected behavior. Use approved synthetic data in screenshots or recordings. Include the test environment, because differences in browser and assistive technology can matter to reproducing a report. Ask for a scoped correction and an explanation of which behavior it changes. In the fictional dialog, a focus-return failure should not become an unrestricted redesign of the request system. Review the code change, then repeat the failed step and the surrounding task. A correction to initial focus could affect navigation elsewhere in the dialog. AI can help draft tests, explain a pattern or suggest a repair. Its statement that the result is “fully accessible” is not a test outcome. Our [guide to checking AI-generated regression tests](https://skillsforbusiness.ai/blog/ai-generated-tests-intended-regression/) explains why a passing test needs to detect the intended defect. Here, automated tests also need appropriate human evaluation of the experience they approximate. Do not assume that repeating the same checklist mechanically covers every interface. A date picker, rich-text editor and simple text field have different interaction expectations. Prefer established components appropriate to the task, and verify their integration after the assistant changes styling, labels or state handling. ## Keep the release record narrower than the claim For each reviewed task, record the application version, relevant state, environment, checker results, manual steps, observed outcome and unresolved issues. Distinguish an automated scan, a keyboard check, a screen-reader evaluation and feedback from people with disabilities. They provide different evidence and should not be collapsed into “tested.” If screen-reader evaluation was unavailable, mark it unverified and arrange the missing review. Do not substitute a model’s opinion or a screenshot inspection and describe it as completed. If users participated, record the actual scope and findings without implying that a small group represents every accessibility need. Treat a blocker in a necessary employee task as a release issue to resolve, even when the demonstration looks attractive. When requirements or observed behavior remain uncertain, involve an accessibility specialist and the product owner. Broader evaluation should address the applicable accessibility requirements beyond this short guide, including aspects such as visual presentation and content that this example does not comprehensively cover. Start with one important workflow and preserve the checks that reveal its failures. Revisit the affected states when generated changes alter controls, validation or navigation. The useful release evidence is specific: what people could complete, in which environment, what failed and what remains unchecked. ## Sources & further reading Sources checked for this article. Research findings and vendor claims are distinguished in the text. 1. [From Code to Compliance: Assessing ChatGPT's Utility in Designing an Accessible Webpage — A Case Study](https://arxiv.org/html/2501.03572v2)Ahmed et al.; arXiv · Accessed 1 November 2026 2. [Easy Checks — A First Review of Web Accessibility](https://www.w3.org/WAI/test-evaluate/preliminary/)W3C Web Accessibility Initiative · Accessed 1 November 2026 3. [Dialog (Modal) Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)W3C WAI-ARIA Authoring Practices Guide · Accessed 1 November 2026 4. [The Goldilocks zone: Achieving an accessible digital future in the AI age](https://www.deque.com/blog/the-goldilocks-zone-achieving-an-accessible-digital-future-in-the-ai-age/)Deque; Glenda Sims · Accessed 1 November 2026 Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/) ## Keep reading [Parallel AI coding: assign ownership before adding more agents](https://skillsforbusiness.ai/blog/parallel-ai-coding-ownership-integration/)[AI agent timeouts: design retries that do not duplicate work](https://skillsforbusiness.ai/blog/ai-agent-timeouts-safe-retries/)