Accessibility
Why this page exists
We want everyone to be able to read this site, use its forms, and get around it, whatever tools they browse with. A site you cannot navigate is a broken site; the legal checkbox is beside the point.
We test against a published standard. We say exactly what we tested and how, and just as plainly what we have not tested yet. If we got something wrong, we want to hear about it, and there is a working email address at the bottom of this page that a human reads.
The standard we test against
We test against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. That is the current version of the standard most of the web is measured against.
This is a small, static content site. The full page inventory: the home page, About, the games index, the three Iron Latitudes pages (overview, roadmap, media), the news index and the individual news posts, the press kit, Contact, and a 404 page. The interactive parts are the navigation menus, a category filter on the news page, a contact form, and a newsletter signup. The site embeds video, held behind a still image so that nothing loads from the video host until you press play. Captions and audio description are therefore in scope; we test against them, and the known exceptions below say what we provide with every clip and what we do not.
How we tested
An accessibility statement that does not say how the testing was done is not worth much. Here is ours.
Automated scanning. We ran axe-core (version 4.12.1), the most widely used accessibility rules engine, over every page of the site: all Level A and AA rules for WCAG 2.0, 2.1, and 2.2, plus the maintainer's best-practice rules. The first scan of the live site found 53 failing elements on WCAG rules. We fixed all of them. After the fixes were deployed, we re-scanned the live production site the same day, every page, at two screen sizes (a 1440 pixel desktop viewport and a 375 pixel phone viewport): zero violations.
Manual assessment. Automated tools catch only a minority of accessibility problems, so we ran a manual assessment modeled on Microsoft's Accessibility Insights process, covering the things a scanner cannot decide:
- Keyboard walks across the site, checking that every link, button, menu, and form field can be reached and operated with the keyboard alone. This is where we found our worst bug: a navigation submenu that keyboard users could not reach at all. It is fixed, and the fix is verified by a scripted walk of the full tab order.
- Focus order and focus visibility, checked step by step: every stop in the tab order has to show a visible focus indicator, and we read the computed styles rather than eyeballing it.
- Heading structure and page landmarks on every page: one h1, no skipped heading levels, and proper regions for navigation, main content, and footer.
- Reflow at a 320 pixel wide viewport, the width of a small phone, with the check rigged so that hidden overflow cannot mask a failure. Before the fixes, part of our navigation was laid out off screen at narrow widths with no way to scroll to it. That is also fixed and verified.
- Text spacing overrides, 200 percent text resize, landscape orientation, and reduced motion preferences.
- Eight of the nine success criteria added in WCAG 2.2, each checked by name: Focus Not Obscured (both levels), Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication (both levels). The ninth, Focus Appearance, is a Level AAA criterion outside this assessment's AA scope.
Pixel-measured contrast. Text sitting on gradients and images cannot be judged by automated tools, and our site has a fair amount of it. For all 52 cases the scanner flagged as undecidable, we measured the actual rendered pixels behind each piece of text, took the worst pixel, and compared it against the required contrast ratio. All 52 passed, with measured ratios from 4.77:1 up to 17.59:1.
Re-verification against production. Everything above was first verified on a local build, then the fixes were deployed and the automated scan was re-run against the live site the same day. The numbers on this page describe the live site, not a lab copy.
What we tested fully, partially, and not yet
The table below sorts everything into those three buckets. The bottom two rows are the part most accessibility statements leave out.
The table scrolls sideways on narrow screens.
| Coverage | What |
|---|---|
| Tested fully | Automated rules on every page at desktop and phone widths. Keyboard reachability and operability of every control. Focus order and focus visibility on everything we build. Heading and landmark structure. Reflow at 320 pixels. Text spacing and text resize. Contrast of text and controls, including pixel measurement against real backdrops where automation could not decide. The WCAG 2.2 additions listed above. |
| Tested partially | The pixel-level contrast measurement covered every case the scanner flagged as undecidable, not every element on every page individually; flat-background text was measured by the scanner itself. The Cloudflare Turnstile widget on the contact form is a closed vendor component: we verified what we could from the outside (keyboard focus goes in, three stops, comes out cleanly, no trap, and it no longer overflows small screens), but what renders inside it belongs to Cloudflare, not us. Details in the exceptions section below. |
| Not tested yet | Sessions with real screen readers (NVDA, JAWS, VoiceOver). We verified the programmatic properties screen readers rely on, such as names, roles, states, and live regions, but we have not yet sat down with the actual software and listened. That is a known limit of this assessment and we intend to close it. |
Known exceptions
Two, and we will name them rather than bury them.
Cloudflare Turnstile, the bot check on our contact form. It is a third-party component whose internals we cannot style or inspect. We verified that keyboard focus passes through it cleanly and that it fits on small screens. We cannot verify the focus styling inside it; that is Cloudflare's surface and Cloudflare's responsibility. If the check will not complete for you, you do not need it. Email us directly at info@ravenwatchstudios.com and the message gets to the same place.
Video: every clip carries captions we write ourselves, a written description of what happens on screen, and a downloadable transcript. We do not yet provide a narrated audio description track.
Conformance statement
This site conforms to WCAG 2.2 Level AA based on self-assessment, with the exceptions documented on this page. This is our own assessment, not a third-party certification, and we have tried to give you enough detail above to judge it.
The full Accessibility Conformance Report (in the industry-standard VPAT 2.5 WCAG format) is published at /accessibility/conformance, and a PDF copy is available for download there.
Tell us if we got it wrong
If anything on this site does not work for you, with any tool, for any reason, email info@ravenwatchstudios.com. A human reads it. Tell us what you were trying to do, what happened instead, and what you were using (browser, device, assistive technology if any). We will write back, and if you found a real problem we will fix it and say so.
Assessment date and upkeep
This assessment was completed on July 30, 2026, against the site as deployed that day. The full test harness (automated scans, keyboard walks, contrast measurement) is kept, and we re-run it against the live site after significant changes rather than letting this page quietly go stale. If a material change lands, this page and the conformance report get re-dated to match.
This page was last revised on , to cover the video the site now embeds. The July 30, 2026 assessment is otherwise unchanged, and the conformance report carries the same note.