Accessibility features and limits
The implementation uses native browser controls and static records to support different reading methods. This is a description of the supplied features, not certification of an accessibility level or a claim of an independent audit.
1. Keyboard operation
A skip link leads directly to the main content. Navigation uses links, while state changes use buttons and native select controls. Visible focus outlines are defined for keyboard focus. FAQ answers use native details and summary elements, which can be opened without a mouse.
No fixed overlay or sticky control covers record headings. The privacy banner sits in the page flow and does not trap focus or block access to the archive. Its Accept, Decline and settings controls are keyboard accessible. Reopening settings moves focus to the banner heading; saving returns focus to the originating control or main content.
The optional archive-card reveal uses native buttons. Tab to a card and use Enter or Space to reveal it. Its result is announced in a text status message. “Try again” resets the cards and returns focus to the first card. No hover action is required to read a record, follow a source or use a tool.
2. Structure and tables
Pages have one main heading and labelled navigation areas. Draws use dated article headings and explicit main and Euro pool labels. Colours and number shapes add visual distinctions but do not replace those labels. Frequency tables include captions, column headers and row headers; zero counts remain visible.
Table containers permit local horizontal scrolling when needed and can receive keyboard focus. The rest of the page is intended to reflow rather than hide essential columns or record fields.
3. Labels and status messages
Every input has a visible label. Filter counts, draft outcomes and card-reveal results use text status messages, not colour alone. Draft fields include length guidance, required-field checks and a source URL protocol check. Copy failures offer manual copying or a text download rather than claiming success.
If browser settings prevent saving the privacy preference, the banner explains the failure rather than claiming the choice has been saved.
4. Display and reduced motion
System fonts avoid external font loading. The layout uses responsive breakpoints and wrapping links. Cards use small hover lifts, short transitions and an optional flip with a brief decorative particle effect after selection. There is no autoplay sound, flashing, moving ticker or continuous animation.
The reduced-motion setting disables transitions and particle effects, removes interactive card lifts and replaces the flip with an immediate face change. All record numbers and source links remain available regardless of motion preferences.
Records, explanations, navigation and all frequency rows exist in HTML before JavaScript runs. Search, filtering, CSV downloads, local draft preparation, the optional card reveal and shared privacy preference controls require JavaScript. The essential catalogue remains readable without it.
5. Limits and preparing an issue note
Browser and assistive-technology combinations can differ. No completed independent audit, screen-reader test series or universal compatibility claim is made. External websites have their own accessibility characteristics.
The local feedback-draft tool includes an accessibility topic. Record the page, the control involved and the difficulty without personal information. It prepares a draft only; it is not a sent support ticket or a promise that an issue has been received.