Answers are grounded in this paper and cite their sources.
Background: Nearly all popular websites still contain detectable accessibility failures: in 2026, 95.9% of the top one million home pages had detectable failures in automated WCAG checks, and a published synthesis identified repair support for 13 of 55 accessibility issue types (23.6%) among the tools it reviewed (Nie et al., 2024). Automated checkers that find these failures rarely help developers repair them correctly. Fixes that ignore how a component behaves at runtime, such as an ARIA state that does not reflect the state of a menu, can mislead screen-reader users. Aims: This study presents the design of A11ySmart, a context-aware and explainable accessibility repair assistant that helps front-end developers understand, preview, apply and re-check fixes for accessibility violations in HTML and React (JSX) code. Methodology: Following a design science research approach, the study synthesised recent literature on accessibility detection and repair, developer practice, tool transparency, explainable AI and human-in-the-loop design; modelled the target user through a proto-persona; derived six functional requirements; specified a reference architecture for context inference, fix generation and re-verification; and built a high-fidelity interactive prototype. The design was positioned against seven existing tools through a six-criterion feature comparison with a transparent coverage score (0 to 6) based on public documentation and assessed formatively through an analytical walkthrough. Results: The prototype implements an end-to-end workflow of project ingestion, prioritised issue dashboard, contextual code viewer with plain-language explanation, side-by-side fix preview that requires developer approval, re-scan, team roles and compliance reporting. In the seven-tool documentary comparison, coverage scores ranged from 1.0 to 5.0 (median 2.5); A11ySmart’s specified design scored 5.0, matching the highest-scoring comparator. Within this selected set, its design combined re-validation, developer approval and fix-specific explanation. This result measures design coverage only, because detection, repair and re-validation are simulated in the current prototype. Conclusion: A11ySmart contributes a design for keeping developers informed and in control during AI-assisted accessibility repair. Its re-verification step is simulated in the current prototype and no user evaluation has yet been conducted; a staged evaluation protocol is therefore proposed, comprising a technical benchmark, a proposed controlled study targeting 34 completing developers and a field deployment, with pre-specified measures (repair correctness, time to fix, regressions, usability, trust and knowledge retention) and ethical and privacy safeguards. The work supports Sustainable Development Goals 10, 9 and 4.
No takes yet. Share an insight, caveat, or question.
Ciervo et al. (2026) studied this question.
Synapse has enriched 10 related papers. Consider them for comparative context: