Review Website Accessibility with AI and NVDA
Use an AI-assisted review to inspect a local game, hear NVDA feedback and turn the findings into specific manual accessibility checks.
Watch the video
I ask GPT-6 Astra to inspect my local tic tac toe game while I follow along with NVDA on Windows 11. The useful result is a set of observations and tests to follow up, including keyboard behavior, focus and spoken game state. This demonstration is not a complete accessibility conformance assessment.
Prepare a page you can test
Start the game on your computer using the run the game walkthrough. In the recording it is available at http://localhost:5173. Confirm the game opens before asking the tool to inspect it. The earlier API lesson explains the surrounding development project.
I use the desktop app's Codex mode and GPT-6 Astra in the recorded interface. The model and menu labels are context for the video; your available controls may differ. The essential task is to provide the exact page, the actions to try and the evidence you want back.
Ask for both a description and interaction
My recorded request asks for an accessibility audit, a description of the page because I am blind, and an attempt to play the game. A more scoped follow-up prompt you can adapt is:
Review the game at http://localhost:5173. Describe its layout.
Try the keyboard controls, complete a game, and restart it.
Report what you tested, what you observed, and what remains untested.
Separate confirmed problems from suggestions and uncertain findings.
The address refers to the computer hosting your game. In the recording, I choose Allow once when asked to access the local site. Read the requested destination and action before responding to an access prompt.
Follow the game state with NVDA
Listen for each square's row and column, the selected mark, whose turn is next, the win announcement and the restart announcement. The recording includes an X win and a new game. I also hear the tool report a draw test. Record those as observations from this session, not as proof that every browser and screen reader will behave the same way.
Turn the report into checks you can repeat
The report describes a narrow layout at 320 pixels, contrast checks and suggestions about stable focus, reviewing the whole board and naming the winning line. For each finding, note the starting state, action, expected result and actual result. Then repeat the relevant interaction yourself with the keyboard and NVDA.
For example, after a win, verify where focus remains and whether you can understand the result without moving away from the board. After Play again, check that the new turn and available squares make sense. A clear spoken status and a predictable focus position solve different problems, so test both.
Keep the limits visible
Correction to the narration: I say WCAG 2.1 near the end, but the report uses WCAG 2.2. The report also calls out further checks: NVDA and JAWS, 200 percent text resizing, 400 percent browser zoom, text-spacing overrides, Windows high contrast and mobile screen readers. A narrow viewport test does not substitute for all of those.
The W3C accessibility evaluation overview explains the role of evaluation and human expertise. Use the AI report to guide investigation, then retain your own test evidence and unresolved issues. Do not turn a successful game or a zero-issue automated result into a claim that the whole site is accessible.
Save a useful follow-up record
Keep the date, page version, browser, assistive technology, steps tested and observed results. Give each confirmed problem a small reproducible example. After a fix, repeat that example and the related game flow. The video shows how assistance can help a blind developer inspect a page; the written record makes that work repeatable.