Accessibility
Every button in the app is a real button, with a name a screen reader can speak, in Romanian and in English — and that is not a promise, it is a rule that stops the build when a screen breaks it. This page says what we check automatically, what we designed but do not check yet, and how to tell us when something does not work for you.
It is a short page. We would rather it were short and true.
What we check automatically
Every screen is made of the same parts. No screen draws its own buttons or its own fields; they all come from one component library. A rule in the build refuses a screen that makes its own button.
That matters for accessibility more than it looks: an improvised button is where the spoken name gets lost, or the touch target, or the response to a press. When the button comes from one place, all three are fixed in one place.
Every icon that is a button has a name. The component that draws them requires the name — not optional. An icon says nothing to a screen reader, so the label is all that somebody who cannot see the screen gets, and a button without one simply cannot be written.
Every text somebody reads exists in both languages. Including the labels for the screen reader, which are text a person reads even if nobody sees them. Two separate checks: one refuses text written directly into a screen, the other compares the two languages and fails if one has a key the other does not. A "half-translated" version cannot exist.
The header is the same on every screen — the mark, the title, the same actions in the same place. It is composed once, and a rule forbids a screen from making its own. A header that comes and goes as you move through an app is hard for anybody and very hard for somebody navigating with a screen reader.
What we designed, but do not check yet
The things below are rules written in our design document and followed as each screen was written. Nothing checks them automatically, so we do not present them to you as guarantees — a "we meet the standard" that nothing can contradict is exactly the kind of claim this page refuses to make.
| What we designed | What would make it checkable |
|---|---|
| Contrast — every text/background pair above the WCAG AA threshold of 4.5:1 | A test that takes the pairs from the design document, computes the contrast from the colours defined in the code, and fails below the threshold. It is arithmetic on values the repository already has. |
| Touch targets of at least 48 dp — including where the element is drawn smaller, through an extended touch area | An automated check across the components. Harder than contrast, and second in priority. |
| Reduced motion — if you have asked the system for less animation, the app should drop the inessential ones | An implementation, first. The rule is written in the design document, but nothing in the code reads the setting yet. That is a gap, not a nuance, and it is recorded as one on our list of technical debt. |
Text scaling works: the app uses the system sizes and has been walked through on a phone at maximum size, including in landscape, where the calendar screens were rebuilt to fit. It is not an automated test, it is a check on a device — we say so, so you know what it weighs.
How to tell us
If something does not work for you, write to contact@thatpigeon.app. It is the most useful category of message we get, because it is the only one we cannot discover on our own.
What helps us to know:
- Which phone you have, and which Android version.
- What text size you have set in the system, if you changed it.
- Whether you use a screen reader — and which.
- Which screen, and what you were trying to do.
We are not asking you for a technical report. "I can't press the save button at large text, on the add-bird screen" is a perfect message.
Further reading
- Your data — what we collect, where the data lives, and how to check it yourself.
- Import and export formats — the CSV files, column by column.