1. What this covers
The pollslive.com website and web application: the marketing and documentation pages, the presenter's Studio, and the participant experience - joining a session, answering a question and viewing results. It covers the site in all seven languages we publish. It does not cover content a host writes into their own poll, which is theirs to make accessible, nor third-party services we embed, which are named below.
2. Conformance status
PollsLive is partially conformant with WCAG 2.1 level AA - the standard referenced by EN 301 549 and by the European Accessibility Act. "Partially conformant" means most of the standard is met and some parts are not; the parts that are not are listed under Known limitations rather than left for you to discover.
We do not claim full conformance, and we will not claim it on the strength of an automated test passing. Automated tooling detects a minority of WCAG failures - it can tell you a control has no name, and it cannot tell you whether the name makes sense.
3. Our position under the European Accessibility Act
PollsLive is operated by a micro-enterprise as defined in Commission Recommendation 2003/361/EC - fewer than 10 staff and turnover at or below €2 million - and is therefore exempt from the service obligations of the European Accessibility Act (Directive (EU) 2019/882). We publish this statement anyway. The exemption describes what we are obliged to do, not what we intend to do, and someone using a screen reader to answer a poll does not care which recital applies to us.
4. How we test
Every public route - 79 of them - is scanned automatically against WCAG 2.1 A and AA using axe-core, driven through a real browser at three viewport sizes including a 320px phone, plus a live session with a host and a participant connected, because most of what a participant experiences happens after the page has loaded and a static scan never reaches it. The scan runs with reduced motion so the readings are of settled pages rather than mid-animation.
A build fails if any route has a critical or serious violation, so a regression is caught before release rather than at audit time. Lower-severity findings are recorded and reviewed rather than blocking. We have not commissioned an external audit or user testing with assistive-technology users; when we do, this statement will say so.
5. What we fixed
The August 2026 audit found and corrected: no skip-to-content link anywhere on the site, so keyboard users tabbed through the full header on every page; option colours that put white labels on backgrounds as low as 2.15:1 against the 4.5:1 required; inline links distinguished from surrounding text by hue alone; code samples and reference tables that scrolled sideways with no way to reach them from a keyboard; a live results panel carrying three overlapping announcement regions that read the entire chart aloud on every incoming vote; and a participant view that changed question without announcing anything at all.
6. Known limitations
Current, and honest. Each of these is real today:
- The interactive API reference (/docs/api-reference) is rendered by Swagger UI, a third-party component we load rather than build. It nests interactive controls inside one another, which assistive technology can announce confusingly, and we cannot restructure it without forking it. The same specification is available as plain JSON at /api/v1/openapi.json, and our own documentation pages carry the same information in accessible HTML.
- Presenter-side live panels - the host console, the leaderboard, the moderated Q&A queue and the insights panel - update in real time without announcing their changes. The participant-facing side has been fixed; the presenter side has not yet, and a presenter using a screen reader will not be told when a new question is received.
- Form error messages are shown visually and are not consistently associated with their field programmatically, so a screen reader may not read the error when focus lands on the input it belongs to.
- Automated coverage is not full coverage. We have not tested every flow manually with a screen reader, and we have not tested at all with voice control or a switch device. Absence from this list is not evidence that something works.
7. Telling us about a barrier
If something stops you using PollsLive, email [email protected] or use our contact form. Tell us the page, what you were trying to do, and the assistive technology and browser you were using if you can - it makes the difference between us reproducing the problem and guessing at it. We aim to reply within five working days.
If you need something from PollsLive in another form - a result export, a poll's contents - ask and we will send it in a format that works for you. If we cannot resolve a barrier you have reported, you can escalate to the Dutch enforcement authority; our registration and contact details are in the legal notice.