Inspiration

Accessibility is often treated as an end-of-project compliance checklist. In product teams, the most valuable question is earlier and more human: which barriers will stop a real person from completing an important task? AccessPilot AI makes that answer visible in seconds, helping designers, developers, and student builders address critical user journeys before launch.

What it does

Paste HTML from a page, choose or infer a product context, and run an accessible, privacy-conscious review in your browser. AccessPilot identifies 12 classes of potentially harmful interface patterns, groups findings by severity, explains why they matter, and offers actionable remediation. Try the provided sample screens for checkout, healthcare, and a more accessible baseline. Explore severity filters and export the review as a Markdown report.

Live demo: https://accesspilot-ai-openbuild-2026.usefulotter1.chatgpt.site/

Visual walkthrough: https://accesspilot-ai-openbuild-2026.usefulotter1.chatgpt.site/walkthrough

Source code: https://github.com/samertall/accesspilot-ai

AccessPilot interface

Accessibility findings

How AI is used

A lightweight, locally trained multinomial Naive Bayes classifier learns from 48 small labeled examples of interface text and HTML cues. It predicts a product context, such as checkout or healthcare, and uses that context to help prioritize the review. For example, checkout-oriented inputs with form and payment cues give extra attention to transaction-related accessibility barriers. The actual checks remain deterministic and inspect DOM structure; the AI does not invent defects or claim a WCAG certification.

Representative input: HTML for a checkout form containing a missing label, image without alternative text, and poor button naming. Output: context-aware findings ordered by critical, high, or medium severity, with an explanation and suggested fix. A well-structured example produces no findings from the implemented checks.

No third-party inference API, account, or API key is required. The analysis runs in the browser and keeps pasted snippets local.

How we built it

The project uses semantic HTML, modern CSS, vanilla JavaScript, DOMParser, a handcrafted 48-example training corpus, and a small Naive Bayes implementation. DOM analysis is separated from contextual prioritization, making results explainable. A secure sandbox powers the visual preview; sample scenarios, keyboard-friendly controls, filters, and Markdown export make the prototype directly testable.

Challenges and what we learned

A probabilistic model can identify context, but it cannot validate accessibility by itself. We explicitly separated ML context detection from deterministic markup checks so that prioritization does not masquerade as a definitive compliance verdict. Another challenge was providing useful feedback without sending user HTML to a server. The local processing design helps address that constraint.

Testing and limitations

Seven automated checks passed, covering implemented analysis behavior. Browser testing included the checkout example (12 findings: 3 critical, 5 high, 4 medium), an accessible baseline (zero flagged findings), severity filtering, and export feedback. Results are intentionally limited: static HTML inspection cannot establish keyboard interaction quality, actual screen reader behavior, visually perceived contrast in all states, or all WCAG requirements. Dynamic apps, CSS-dependent issues, and ambiguous content need manual user testing and expert validation. False positives and false negatives remain possible.

What is next

Improve the training corpus and evaluation; add guided keyboard-test tasks; expand rule coverage with transparent evidence; enable accessible team collaboration and CI integration.

Credits, team and disclosures

Samer Tallauze — solo builder; product strategy, UX, accessibility review, interface engineering, testing, and documentation. This prototype was developed for demonstration during November 2026. Browser APIs, JavaScript, and public accessibility principles are pre-existing components. AI assistance was used for ideation, coding, documentation, and QA; the locally trained classifier is the runtime AI feature. No external dataset or paid model API was used. This is a prototype, not a certified accessibility audit service.

Share this project:

Updates

Submission history