Accessibility statement

1. Scope

• The visitor pages: joining a queue, the ticket, the queue status, booking an appointment, the kiosk and the display screen.
• The attendant panel and the admin page.
• This website (qrwait.app).
• The QR Wait iPhone and Android apps show the same pages; their own parts (notifications, the lock screen) are not covered yet.

2. Standard and status

Our target is WCAG 2.2 level AA. It includes the WCAG 2.1 level AA requirements that the European standard EN 301 549 (V3.2.1, chapter 9) sets for the web, and WCAG 2.2 level A.

QR Wait is partially conformant: the pages we test meet the automated checks below, and the known limits further down are where it falls short or hasn't been checked yet.

3. How we test

• An automated check (axe-core 4.10, WCAG 2.1 A and AA rules) of the home, pricing and demo pages, joining a queue, the ticket, the queue status, booking, the attendant panel, the display screen, the kiosk and the admin page, in all 23 languages, in light and dark mode. The last run, on 27 October 2026, found no violations.
• Every colour pair of every theme is tested against the WCAG AA contrast ratio with each change.
• Automated checks find only part of the problems. A full manual test with screen readers (VoiceOver, TalkBack) is not finished yet.

4. What already helps

• The visitor pages open in the phone's language (23 languages, Arabic right to left) and follow its light or dark setting; a high-contrast theme can be picked in the top bar. They work with the browser's zoom.
• Nobody needs a smartphone: the attendant adds a visitor by hand and tells them their number, and a kiosk lets visitors take a number on a shared screen.
• Being called doesn't rely on one sense: the phone vibrates, the page turns green with the number in large type, and a notification arrives if it was allowed. The display screen can also read the numbers aloud.
• The time to come after a call is set by the business (3 to 30 minutes), and visitors can ask for more time.
• Movement is reduced when the device asks for less motion.
• A business's own brand colour is darkened automatically when it would be too light to read on white.

5. Known limits

• Joining with the QR code needs a camera and, in queues that check location, the phone's location. Visitors who can't use either are added by the attendant.
• The map in the admin page's queue form is hard to use with a keyboard or a screen reader; the address search beside it places the queue without the map.
• The QR code that changes on the attendant's screen can only be scanned, not read out; the attendant can add anyone by hand.
• The bot check when signing up (Cloudflare Turnstile) and the payment page (Lemon Squeezy) belong to other companies. We can't fix them ourselves, but tell us and we'll pass the problem on.
• Manual testing with screen readers is not complete (see above).

6. Feedback

If something stops you from using QR Wait, write to hello@qrwait.app with the page's address and what happened. We'll answer, fix it where we can, and meanwhile tell you another way to get what you need.

Businesses: please pass on what your visitors tell you.

7. A paragraph for your own statement

Businesses that use QR Wait can copy this into their own accessibility statement:

Our queue runs on QR Wait (qrwait.app). Its visitor pages aim for WCAG 2.2 level AA, which includes the WCAG 2.1 AA requirements of EN 301 549, and are checked with automated accessibility tests in 23 languages. You don't need a smartphone to join: ask our staff and they will add you to the queue and tell you your number. QR Wait's own accessibility statement, with its known limits: qrwait.app/accessibility

8. About this statement

Prepared on 27 October 2026 by QR Wait from its own testing. We update it when the pages change.