Our commitment
We want this site to be usable by everyone, including people who use screen readers, keyboard navigation, magnification or reduced-motion settings. Our target is WCAG 2.2 Level AA, and we treat it as a floor rather than an award.
This matters more than usual for a site about contracts. A reader who cannot parse a bonus table or a state list is a reader who cannot make an informed decision, and the harm from that is financial. Accessibility here is not a compliance box; it is the product working.
What we have implemented
- Semantic HTML landmarks, one H1 per page and a logical heading order.
- A skip-to-content link and visible keyboard focus styles.
- Colour contrast checked against AA for body text and interactive elements.
- Tables with captions and scoped headers; no layout tables.
- Text alternatives for meaningful graphics and decorative images marked as such.
- No information conveyed by colour alone; state tiers pair colour with labels.
- Content reflows at 320px width without horizontal scrolling of body text.
- Reduced-motion preferences respected by animations and transitions.
- Form controls and links with discernible names; no icon-only buttons without labels.
How we test
We test with a keyboard-only pass, a screen reader pass and automated checks. The automated tools catch contrast, labels and structural errors; the manual passes catch the things tools miss, such as a table that is technically valid but impossible to follow when read aloud.
Testing happens on the pages that carry the most information, the state reference, operator pages and the guides, because those are where a barrier costs a reader the most. We do not claim a perfect audit of every page on every release.
Known limitations
- Some long data tables are wide. On small screens they scroll horizontally within a container rather than compressing into an unreadable grid. The text remains reflowable; the table does not.
- Charts and diagrams are described in surrounding text rather than duplicated in a data table. If you need a specific figure in another format, ask us.
- Third-party operator sites are outside our control. Their accessibility is their responsibility, and it varies widely.
Feedback and barriers
If you hit a barrier, email editorial@casinotrustcenter.com with the page, the task you were trying to complete and, if possible, the assistive technology you use. We aim to respond within five business days and to fix blocking issues faster than that.
We will not ask you to prove a disability to act on a report. A description of what broke is enough.
Testing cadence
We run the automated checks on every build, a keyboard pass before any layout change ships, and a screen-reader pass on the high-information pages once a quarter. The quarterly pass covers the state reference, the operator pages and the two guides, because those are the pages where a barrier changes a decision rather than just an experience.
Findings are logged with the page, the assistive technology and the task that failed. Blocking issues, a control that cannot be reached, a table that cannot be parsed, a form that cannot be submitted, are fixed before the next deploy. Non-blocking issues are batched into the next design pass, and this statement records that they exist rather than implying a clean audit.
Third-party content
Operator sites are outside our control. We link to them because the reader needs to check the terms, not because we endorse their accessibility. If a partner link leads to a page that is unusable with assistive technology, tell us and we will add a note to our operator page describing the barrier, so the next reader is not surprised.
We also avoid embedding third-party widgets (chat, video, social feeds) that bring their own accessibility failures. Where an embed is necessary, it carries a text alternative and a link to the same information in our own markup. If an embed cannot meet that bar, it does not go on the page; the information is more important than the widget.
Standards and references
Our target is the Web Content Accessibility Guidelines 2.2, Level AA, published by the W3C. We also follow the practical guidance in the WAI-ARIA Authoring Practices for the interactive elements we use, and we avoid custom widgets where a native element would do.
Review cycle
This statement is reviewed when the design system changes and at least once a year. The date at the top of the page reflects the last review, not the last deployment. A statement that is never tested is a claim, and we would rather publish a short list of known limits than a long list of good intentions.
What we have tested
The site is built with semantic headings, a visible focus style, and text contrast that meets WCAG AA for body copy. Tables use header cells with scope attributes, and navigation landmarks are labelled. Images that carry meaning have alt text; decorative images are marked as such.
We have not completed a full audit with assistive technology across every browser and screen reader combination. Saying that plainly is more useful than claiming full conformance.
Known limits
The mobile menu is a native disclosure element, which works without JavaScript but behaves differently across screen readers. Data tables are horizontally scrollable on narrow screens, which can be awkward with keyboard-only navigation on very small viewports.
Reporting a barrier
Email editorial@casinotrustcenter.com with the page, the device and what happened. Accessibility reports are treated as corrections, not as feature requests, and they are answered first.