Accessibility statement for kadabra.net
This site was built targeting WCAG 2.1 level AA. Here is the real status, what we know still falls short, and how to report a barrier to us.
Accessibility statement
Report a barrier
Conformance status
Status: partially conformant with WCAG 2.1 level AA. Partially conformant means most of the site meets the standard, some parts do not yet, and those parts are listed below by name.Date of this statement: August 30, 2026. Last reviewed: August 30, 2026. Evaluation method: internal self-assessment by the Kadabra team.We will not write «fully conformant» until an audit has been done and dated. Claiming full conformance and having someone hit a barrier five minutes later is worse than claiming nothing, and worse still for a consultancy that sells accessibility.
What we measured, and what it forced us to change
We calculate the contrast of every colour pair in our brand before using it. These are the failing rows, published as they came out:
Contrast measurements of the palette
Verdict and use
Mint green on white
1.9 to 1
Fails. Banned as text across the site.
White on mint green
White on the turquoise end of the brand gradient
1.8 to 1
That is why the pure gradient is decorative and never carries text.
Brand blue on white
4.07 to 1
Good for large headlines only. For links and small text we use a blue one step darker, which gives 4.78 to 1.
Mint green on navy
7.8 to 1
Passes comfortably, which is why the green only appears on dark backgrounds.
White on navy
14.7 to 1
Passes comfortably.
In addition: the overlay on hero photographs uses a blend mode that never lightens the background, so white text keeps at least 4.9 to 1 over any photograph. Every interactive element has visible focus. Transitions respect the operating system's reduced motion preference.
The detail, unvarnished
Detail of the accessibility evaluation of kadabra.net
What we evaluated, and with what
The review combines two things, because neither is enough on its own.Manual keyboard review. We walk every page with the tab key, no mouse: focus order, visible focus, keyboard traps, heading hierarchy, alternative text and form labels.Automated tools. They catch insufficient contrast, missing attributes and markup errors. They cover roughly one third of the WCAG criteria; the rest can only be seen by hand. When somebody says their site «passed the tool», they are talking about that third.The automated tool is axe-core (version 4.13.0), run against a real Chromium browser driven by Playwright (version 1.50.0). We have not yet run a dedicated screen reader test.
Known limitations of this site
These are the ones we already know about and have documented. It is not a closed list.Page content is assembled in the browser. Pages are built with components that render on the client. With JavaScript disabled, or blocked by an organisation's policy, there is no content to read.The brand typefaces are not self-hosted yet. Until they are, they depend on an external service and there can be a visual shift while the font arrives. Text falls back to a system typeface, so the content still reads.Some brand palette pairs do not reach AA. They are measured, published above and banned in the design system, so they never appear on the site. What is still pending is fixing them in print materials and slide decks.First full automated review: August 30, 2026, axe-core across all 66 pages of the site, against the WCAG 2.0 A/AA, 2.1 AA and 2.2 AA rule sets. Result: zero firm violations. Methodology note: on some runs, axe reported a false contrast violation on the «Preferences» button of the cookie notice; checked by hand, the cause is that the notice enters with a 420-millisecond appearance animation, and the tool sometimes measures the color mid-animation, before it reaches its final opacity. The text's final color does meet AA. This first review did not cover PDFs, third-party video, or third-party components, because the site does not publish any of the three yet.
Technology this site relies on
This site relies on HTML, CSS and JavaScript. Its components are written in React and TypeScript. Accessibility rests on semantic HTML and the browser's standard accessibility attributes; we use no proprietary widgets or third-party frameworks for navigation.
Standard we target
We target WCAG 2.1 level AA: the level Uruguayan public tenders usually ask for. The components we build for clients hold the same standard, not as an extra but as a delivery requirement.Uruguay also has Decree No. 406/022 (December 22, 2022), which implements Article 88 of Law No. 19,924 and requires WCAG-based digital accessibility from State bodies, Departmental Governments, Autonomous Entities, Decentralized Services, and non-state public-law entities. Today it covers the public sector, not Kadabra as a private company — the decree itself allows the Executive Branch to extend it to specific private sectors, but that has not happened for ours yet. We hold ourselves to it anyway, without being required to, because it is the standard we already hold the public bodies we work with to.
How to report a barrier
If you find something you cannot use, write to hello@kadabrait.net and tell us three things: which page it was, what you were trying to do, and which assistive technology you were using (screen reader, magnifier, keyboard or voice navigation).We reply within 10 working days. If the barrier is ours, that same reply gives you a date for the fix. If we cannot fix it, we tell you why and how to reach that information another way.
Book 30 minutes