Partly, and the honest answer comes in three parts. It is NOT WCAG-certified and has not been audited by a third party: no page on this site will tell you otherwise. Several foundations are nonetheless there by construction, because the interface is written by a deterministic program rather than redrawn each time — visible keyboard focus, reduced motion if your system asks for it, real forms, no native dialog boxes. At every generation, the accessibility tree of each screen is recorded and published in a report. What is missing is named below rather than left unsaid. And because the code belongs to you, an accessibility fix is ordinary work, not a request filed with a vendor.
What is guaranteed by construction, because a program writes the interface
The difference comes down to who holds the pen. The interface is not drawn by a model at each generation: a deterministic builder emits it from a shared component library. A guarantee established once therefore holds for every screen of every application, instead of depending on the inspiration of the day. That is the most useful property of this architecture where accessibility is concerned, and it is not a slogan: it can be checked screen by screen.
Concretely: every interactive element takes keyboard focus and shows a visible ring drawn from the application's own palette — not the browser default, which vanishes against a coloured background — and that same ring does not appear on a mouse click, where it teaches nothing. A user whose system asks for reduced motion gets transitions cut to a negligible duration. Dialog boxes are real forms: Enter submits, the first field takes focus on opening, and the primary button is a submit button.
No native dialog boxes, and why that is good news
An application produced here never uses the browser's native confirmation window. Deleting a row happens in two steps, inside the page: a first click arms the action, a second confirms it, and you can back out in between. The same principle applies to disabling an account.
This decision was not taken for accessibility — it came from an automation problem and a question of visual language — but its consequence is real and worth stating. A native window steps outside the document, interrupts the reading flow, and is not announced the same way depending on the browser and the assistive tool. A confirmation placed inside the page stays in the tab order, reads like the rest of the screen, and leaves room to step back without answering a modal question.
What is MEASURED at every generation — and what the measurement does not promise
Before delivery, each application is opened in a real browser and walked through screen by screen. On that pass it is not the picture that is examined but the accessibility tree: the structure a screen reader traverses. Recorded there are buttons, links and fields without an accessible name, skipped heading levels, images without a description, and identical labels repeated outside a list. A “×” close control counts as unnamed, because a screen reader pronounces it “multiplication sign”.
Here is the point of honesty, and it is decisive: this is a REPORT, not a gate. There is no threshold, no verdict, no blocking — a screen carrying unnamed controls is not held back at delivery. The measurement therefore states what is known about the application; it promises no level of conformance. A coverage figure claiming otherwise would be exactly the kind of promise this page refuses to make.
What is NOT done, and what you can do about it
Three gaps, named. Dialog boxes do not trap focus: tabbing can leave an open dialog, whereas the rule is that it should cycle within it. No live region is in place: a successful save, an error, a refreshed list are visible on screen but announced to no one. And there is neither WCAG certification nor independent audit — so if you are under a legal obligation, this application does not discharge it and does not claim to.
What you can do about it is precisely what separates this situation from closed software. The code belongs to you, it can be retrieved as an archive or on a repository, and it is an ordinary Next.js project: trapping focus in a dialog or adding a live region are well-charted front-end tasks, costable, that any provider can carry out. With a classic vendor, the same defect is a ticket whose priority and date you do not control. If you fall under an accessibility regulation, plan your audit: it is mandatory anyway, and here its findings are actionable.