Accessibility statement
A voluntary statement, made by Cosimo Luigi Manes, a natural person running
the ReactiveNET project in a personal capacity and not as a business, in respect
of the reactivenet.ai website and the ReactiveNET application.
Where it comes from should be said at once: the provider is not among the entities required to publish such a statement under Italian Law 4/2004 and the related AgID guidelines. It is made anyway, in the form prescribed for the entities that are required to, because the platform is aimed largely at public administrations: a body publishing a service built with these tools needs to know what it can rely on and what it cannot, and a voluntary statement that tells the truth is more useful than an obligation that does not exist.
1. Conformance status
The reactivenet.ai website and the ReactiveNET application are partially
conformant with WCAG 2.2 level AA (and with EN 301 549), because of the
non-conformities listed in § 2.
The project’s stated target is WCAG 2.2 level AA — a more recent version than current legislation requires, which stops at WCAG 2.1 AA.
2. Non-accessible content
2.1 Non-conformant
The two text editors — the Markdown editor and the block editor — are third-party components (CodeMirror and BlockNote) embedded in the platform. Their conformance is not within the provider’s control and has not been verified as conformant. They are authoring surfaces, used by whoever writes an app, and they do not appear in what readers of an app see: published pages and running apps do not contain them. Below phone screen width the editors are not offered at all.
Available alternative: an app is a Markdown text file. It can be written in any accessible editor of one’s choosing and imported; it can be exported, changed elsewhere and imported back. Creating and editing need not go through the embedded editors.
Apps created by users may contain barriers the provider does not control: an
image without alternative text, a badly chosen colour, a missing label are
decisions of whoever writes the document. The platform supplies accessible
components and composes them correctly — labels tied to fields, help text linked
with aria-describedby, tables with headers, named regions, verified contrast
for the palettes offered — but it cannot force an author to use them well.
The conformance of a published app is its author’s responsibility, and for a
public body it is a legal obligation: the accessibility section of the
documentation says what to check.
2.2 Disproportionate burden
No requirement is excluded on grounds of disproportionate burden.
2.3 Content not within the scope of applicable legislation
Diagrams generated by Mermaid, mathematics rendered by KaTeX and output produced by Python blocks reflect the content written by the document’s author: whether they are understandable depends on a text alternative that the author must provide.
3. What has been done, and how it is verified
Some choices are verified automatically on every build, not by eye:
- Contrast: the WCAG relative luminance and contrast ratio formulas are implemented in the code, and a test checks every palette offered against the surfaces on which text actually appears, in light and dark themes. A colour below 4.5:1 fails the build. The original six palettes had been chosen by eye and none of them passed.
- Reflow (§ 1.4.10): verified by constraining the document to 320 px and measuring the absence of horizontal scrolling. Tables, exempt from reflow, are wrapped in a scrollable region that is keyboard reachable and has an accessible name.
- Visible focus (§ 2.4.7), accessible names on every icon-only control (§ 4.1.2), 24×24 px minimum target size (§ 2.5.8) and no obscuring of focused content (§ 2.4.11): verified in the running application.
- Labels that name the control (§ 2.4.6): buttons state the function, not the format; the two panes of the workspace are named regions.
4. Assessment method
Self-assessment carried out by the provider, with automated tests built into the build (contrast, presence of translated strings), manual keyboard testing, reflow verification and inspection of the accessibility tree.
No independent third-party evaluation has been carried out. When one is, this statement will report its findings and date.
5. Feedback mechanism
Anyone encountering a barrier can write to info@reactivenet.ai, stating the page or feature, the device and the assistive technology in use. A reply is given within 30 days, describing how and when the barrier will be removed or, where it cannot be, what alternative is available.
Reports are welcome even where they concern a requirement the project believes it already meets: a requirement met on paper and not in practice is exactly what internal testing fails to see.
6. Enforcement procedure
In respect of entities legally required to comply, a person who does not receive a satisfactory reply within thirty days may apply to the Digital Ombudsman (Difensore civico per il digitale) at the Agency for Digital Italy. Since the provider is not a required entity, that procedure is not available against it: what remains is the feedback channel in § 5, and the provider’s willingness to discuss the matter with the public client concerned.
7. Information for bodies publishing an app
An administration building a service with ReactiveNET remains the entity responsible for that service’s accessibility and for its own statement. What the platform gives it: components with correct role, name and state; verified contrast; document structure with real headings; tables with relationships preserved; keyboard operation. What remains for it to do: alternative text, order and clarity of content, declared language, testing its own service with real users, and — where it uses the card drag feature, which requires a pointer — checking that the keyboard alternative (editing the row) is adequate for its use case.
Statement drawn up on 13 August 2026 and last reviewed on 13 August 2026. It is reviewed at least annually and on every substantial change to the platform.