Accessibility statement
Alcometer.org is committed to making its BAC calculator, hangover, recovery, and hydration tools accessible to the widest possible audience, including people with visual, motor, auditory, cognitive, and neurological differences.
Conformance target
We aim to meet the Web Content Accessibility Guidelines (WCAG) version 2.2 at Level AA, published by the W3C. This target is consistent with EN 301 549 and the European Accessibility Act (EAA), with WCAG 2.1 AA treated as the minimum compatibility floor.
Commit 14a introduced an executable axe-core + Puppeteer baseline over the main Alcometer tool routes. Commit 14b began remediating known failures while keeping that baseline non-regressing until the Phase 12 launch gate.
Known gaps are listed below and are being actively remediated before the launch gate flips from non-blocking to blocking.
Current automated test coverage
The repository now runs npm run test:alcometer:a11y, which builds the site, starts Astro preview, opens the curated English tool set, injects axe-core through @axe-core/puppeteer, and checks the wcag2aa and wcag22aa tags.
The current baseline is stored at test/a11y-baseline.json and the latest run report is written to reports/a11y-run.json. The baseline currently tracks serious and critical findings so later commits can prove they do not introduce regressions.
The GitHub Actions accessibility job is intentionally non-blocking until Phase 12. It uploads the baseline and report artifacts for review.
What this means in practice
• Interactive controls should use native HTML controls wherever possible, with visible focus indicators and keyboard operation.
• SVG and canvas-like data visualisations should provide an equivalent text or table fallback when the graphic carries information.
• Dialogs must preserve focus order and provide an explicit path for users who do not want to continue.
• Document language is declared on every generated page through the <html lang> attribute.
Known limitations
The first axe-core baseline still contains serious/critical findings that are being handled in follow-up commits. Until Phase 12, the automated runner blocks regressions against the baseline rather than claiming zero findings.
Some data visualisations now include screen-reader-only tables, but the remaining chart copy and locale parity still need manual assistive-technology review.
Right-to-left languages are not yet implemented as dedicated RTL layouts; content falls back to the available LTR locale shell where applicable.
How we test
• Automated: axe-core via @axe-core/puppeteer on Astro preview, scoped to wcag2aa and wcag22aa tags.
• Regression report: reports/a11y-run.json.
• Frozen baseline: test/a11y-baseline.json.
• Manual review still remains necessary for keyboard flow, screen-reader wording, cognitive clarity, zoom behavior, and visual regression checks.
Automated tools catch only part of WCAG conformance. Human review is required before launch, especially for the calculator, compliance gate, and chart-heavy pages.
Feedback and contact
If you encounter an accessibility barrier — missing alt text, a keyboard trap, a contrast issue, unclear focus order, or anything else — please get in touch.
Email: alcometer@wp.pl
Postal: Piotr Zieminski, Kalonka 71a, Poland
Please include: (1) the URL where the problem occurs, (2) a short description of the barrier, (3) your assistive-technology setup if relevant.
Enforcement
If you are not satisfied with our response, you may refer the matter to the competent national enforcement body under the European Accessibility Act. In Poland, this is Urząd Komunikacji Elektronicznej (UKE, https://www.uke.gov.pl/).
Preparation of this statement
This statement was updated on 25 April 2026 after the axe-core baseline and non-blocking CI accessibility job were added to the repository.
Next review scheduled: 25 April 2027, or sooner if material changes to page templates, calculator UI, or accessibility tooling occur.