Accessibility

AddressHate wants everyone who monitors, studies, or reports on hate online — trust and safety teams, researchers, policymakers, journalists, and the public — to be able to use this dashboard, including people who rely on a screen reader, a keyboard, voice control, magnification, or reduced motion.

We treat accessibility as part of correctness rather than polish. The checks described below run automatically on every change to the site, and a change that introduces a failure cannot be released.

The Web Content Accessibility Guidelines (WCAG) 2.1 define requirements for making web content accessible. This dashboard is built to WCAG 2.1 Level AA, the conformance level referenced by the Americans with Disabilities Act and by international regulators.

The dashboard is partially conformant with WCAG 2.1 Level AA: every page passes our automated and keyboard checks, but some content does not yet fully conform, for the reasons listed under Known limitations.

Two automated gates cover every page of the site in both the light and dark colour themes. They run in continuous integration before any change is released.

• Automated audit. Every page is rendered in a real browser and checked against the WCAG 2.1 A and AA rule set of axe-core, plus structural rules for landmarks and heading order.
• Keyboard operability. Scripts drive the primary navigation and page controls with a keyboard alone and assert that every control can be reached and used, that focus is always visible, that focus never lands inside a collapsed panel, and that Escape closes a menu and returns focus to the control that opened it.
• Colour and contrast. The design tokens behind every surface are checked at 4.5:1 for text and 3:1 for graphical elements, in both themes, before the browser audit re-measures the rendered result.
• Motion. When a visitor’s system asks for reduced motion, animations are shortened rather than removed, and the audit checks that nothing is left invisible as a result.
• Page titles. Each page carries its own descriptive title, so screen-reader users and bookmarks can tell pages apart.

What this buys you on every page:

• A skip link to the main content, and consistent landmarks and headings.
• Full keyboard operation with a visible focus indicator.
• A light and a dark theme that both meet the contrast targets above.
• Charts that carry an accessible name and, for most, a written summary or a hidden data table for screen readers.
• Icons that are labelled or hidden from assistive technology as appropriate.

Despite the above, some content does not yet fully conform. We list what we know so you are not left guessing.

• Charts and visualisations. Every chart has an accessible name, and most also carry a text summary or a screen-reader data table. A few visualisations remain hard to interpret without sight where the underlying numbers are not yet reproduced in text nearby. We are adding those tables as we go.
• Third-party content. Posts, images and video collected from social media platforms are shown as we found them. We cannot author text alternatives or captions for content we do not control, so some of it will lack them.
• Assistive-technology testing. Our checks are automated and scripted. We have not yet completed a manual audit with screen readers such as NVDA, JAWS or VoiceOver, and some issues are only found that way.
• Pages behind sign-in. Restricted and data-dependent pages are audited against representative data rather than live content, so a defect that appears only with particular live data could escape us.
• Scope. This statement covers the dashboard at this address. The AddressHate Annotator browser extension has its own interface and is assessed separately.

If something on this site is inaccessible to you, or you need information from it in another format, please email us at ecarmeli@addresshate.org. It helps to include the page address, what you were trying to do, and the browser and assistive technology you were using.

We read every message and aim to reply promptly, and we fix confirmed barriers as a priority.

The dashboard relies on HTML, WAI-ARIA, CSS, JavaScript and SVG. Interactive views require JavaScript. It is built to work in current versions of Chrome, Firefox, Safari and Edge on desktop and mobile, together with the assistive technologies those browsers support.

This statement was published on 26 August 2026 and last reviewed on 26 August 2026. The automated review it describes runs on every change to the site; we revise the statement itself whenever our conformance status or known limitations change.