Statement
Accessibility
Issue 3Dated Supersedes issue 2 of
responda should work for everyone who uses it, including people using a screen reader, a keyboard, magnification or voice control. This statement says how well the website and the app meet that today, and how to report a problem.
What this covers
As of
This statement covers the responda website and the responda app, and answers for each separately. Both are measured against WCAG 2.2 AA: the Web Content Accessibility Guidelines, version 2.2, at level AA.
This website
As of
This website conforms to WCAG 2.2 AA.
Every page is checked before it is published. An accessibility scanner runs over it at a phone width and at a desktop width, in both the light and the dark theme, against the whole set of WCAG 2.2 level A and AA rules. A page with any reported problem is not published.
The site carries no JavaScript, no cookies and nothing loaded from another company, so a screen reader gets the page as it was written.
The responda app
As of
The responda app is partially conformant with WCAG 2.2 AA.
Partially conformant means the app meets most of the standard, but not all of it. Some parts of the app have been checked thoroughly. Others have not been checked as whole screens. There are also two known problems that are not fixed as of this issue. The sections below give the details.
What is checked
As of
The app is built from a shared component library of controls: buttons, fields, dialogs, menus, tables, date pickers and so on. Every one of them is tested for accessibility problems automatically each time the app is built. If a control has a problem, the build fails. No control is exempt.
Two areas are also checked as whole screens, in a browser, against a real server. This catches problems that checking each control on its own cannot, such as a skipped heading level, or a duplicate identifier that only appears when two sections are on the page together. The two areas are:
- the public burn permit application, from its self-screener through every section of the form to the screen shown once it is lodged
- every brigade administration screen: the member list and each member's record, membership and disassociation requests, sign-ins and sign-in history, the activity report, settings, visit reasons and the station user
An automatic test measures the contrast of the app's grey text colours against every background they are used on. If a colour is below the minimum contrast for readable text, the build fails.
What is not checked
As of
Station sign-in, system administration, organisation administration, signing in and the dashboard are checked control by control, not as whole screens. Their parts are held to the same bar as everything else, but nothing measures how those parts compose once they are on a screen together.
The whole-screen checks that run on every change use one browser engine, Chromium, which is what Chrome and Edge are built on. Firefox is not scanned at all, and Safari only when the whole suite is run by hand rather than on a change.
The app's automatic checks run against WCAG 2.1 AA, one version behind this website. The four requirements that version 2.2 added at level AA are covered by no automatic check in the app: keeping a focused control from being hidden behind something else, offering a way round a dragging gesture, a minimum size for anything you tap, and signing in without having to remember or copy out a character sequence.
No sustained screen reader listening pass has been done. One screen has been worked through with VoiceOver on Safari, which is where the second problem below was measured. NVDA has not been used at all.
An automatic scan only catches some accessibility problems, so passing one does not prove a screen is accessible.
Known non-conformances
As of
Two problems are measured, recorded, and not fixed at the date of this issue. Each is named with the surface it affects.
The site icon is hard to see in a dark browser tab. The small responda icon a browser draws in its tab strip and its bookmarks does not stand out from a dark background by enough: it measures 2.31:1 against a floor of 3:1. It affects every page of the app and of this website. It affects the browser's tab strip and bookmarks, and nothing inside the page.
VoiceOver on Safari highlights the wrong place around text written for a screen reader. Where the app puts text on a page for a screen reader to read and for nobody to see, VoiceOver on Safari draws its cursor around where that text would sit if it were visible, rather than around the small box it takes up. It was measured on the screen shown once a burn permit application is lodged, where the cursor lands beside the application's reference number instead of around it. The text is read out correctly and only the highlight is misplaced. It comes from the technique that hides the text, so it is not particular to that one screen.
This list only includes problems we have measured. Anything we have not tested is covered in the section above. If you find a problem that is not listed here, report it to us using the details below.
Reporting a barrier
As of
If you have trouble using this website or the app, email contact@responda.app. A person reads every email, and Entent replies within 30 days.
It helps to say which screen you were on, what you were trying to do and what happened instead. If you use a screen reader, magnification, voice control or a switch device, tell us which one and its version. That helps us find the problem.
There is no charge, and you do not need an account or a brigade role to report a barrier. Anyone can.
Changes to this statement
As of
This statement is a controlled document. When it changes, it is published as a new issue with a new date, and the line under the headline names the issue it replaces. Each section carries the date its statement became true, so a claim can be cited with the date it was made.