Accessibility Statement — Cookie Approval Plus
- Effective date: 12 August 2026
- Applies to: Cookie Approval Plus for Android, package
com.cookie.approval.plus, version 1.1.1 and later - Published by: Casinos Custom, LLC
- Contact: app.dev@casinoscustom.com
1. Purpose statement
Cookie Approval Plus is a digital medical prosthetic. Accessibility is not a feature of this app; it is the reason the app exists and the whole of what it does.
A prosthetic does not restore a limb — it restores a function, standing in for a motion the body cannot make, so the person can get on with the task. This one is software, and it substitutes for a single motion: the small, precise, endlessly repeated tap that clears a consent prompt. The decision itself stays entirely with the user, who sets it in advance. The app performs only the movement.
That is the same reason a hand prosthesis exists, and the same reason for everything else revenue from this app is intended to fund.
The app was built for people with motor and dexterity impairments — limited or no use of the hands, arms, or fingers — arising from conditions including but not limited to spinal cord injury, cerebral palsy, muscular dystrophy, multiple sclerosis, ALS/motor neurone disease, Parkinson's disease, essential tremor, arthritis, repetitive strain injury, stroke, amputation, and limb difference.
Where this sits
Cookie Approval Plus is the first project of a longer effort. Casinos Custom, LLC intends to establish a non-profit building technology that restores lost function.
Some of that is software: eye-tracking that navigates by intent, control surfaces driven by whatever movement a person has, and custom interfaces built around one person's range of motion rather than an average one. Some is physical. Some is both — AI-assisted prosthetics that read muscle signals to close a hand or move a leg.
The common thread is the principle this app is built on: identify the motion a person cannot make, and make it for them.
Cookie Approval Plus is a paid app, and what you pay for it goes toward that. The non-profit is not yet established, so this is a statement of intention rather than of present fact — we are not asking anyone to donate, and no existing charity receives your money. You are buying a tool; this is what the company does with the revenue.
The app carries no advertising and no in-app purchases.
2. The barrier it removes
Consent banners are, for most people, a small irritation. For a person who cannot perform a precise touch gesture, they are a physical barrier repeated dozens of times a day.
A typical cookie banner requires the user to:
- locate a small control, frequently under 48dp — below the Android accessibility target-size guidance and below WCAG 2.2 Success Criterion 2.5.8 (Target Size, Minimum);
- reach it precisely, often at the bottom edge or in a corner of the screen;
- commit a single accurate tap without tremor, drift, slip, or accidental multi-touch;
- repeat all of the above on essentially every new website, on every device, every day, indefinitely.
For a user with a significant motor impairment, each of those steps can take several attempts, cause pain, or be impossible without assistance from another person. The barrier is not the decision — the user knows what they want. The barrier is the motor act of executing it.
3. How the app removes it
The user makes the decision once, in advance, in a settings screen designed for large targets and no time pressure. Thereafter, the app performs the motor act on the user's behalf, each time the barrier appears.
This is the same substitution that every assistive technology makes:
| Assistive technology | Substitutes for |
|---|---|
| Screen reader | Reading the screen visually |
| Switch access | Touching a specific point on the screen |
| Voice control | Manual navigation and selection |
| A hand prosthesis | A grasping motion the hand cannot make |
| Cookie Approval Plus | The precise, repeated tap needed to clear a consent prompt |
The app is built on Android's Accessibility Service API — the same platform
capability those tools use — because it is the only API Android provides for
reading on-screen content and performing a gesture on the user's behalf. It is
declared to the platform with android:isAccessibilityTool="true".
4. Design decisions driven by the accessibility purpose
These are not incidental. Each follows directly from who the app is for.
- Configure once, act silently thereafter. The app never interrupts the user to ask “shall I press this?”. Asking would recreate the exact barrier the app exists to remove — an unplanned, time-pressured, precise tap.
- “Ignore” is the safe default, not a question. When the app cannot confidently identify a prompt, it does nothing and leaves it for the user. It does not ask the user to resolve the ambiguity by hand.
- Wrong presses are weighted far more heavily than missed ones. Whenever the app is unsure, it does nothing. Leaving a banner on screen costs the user a moment; an incorrect press may cost them a task they cannot easily undo. The optional “Guess the button” fallback is off by default for exactly this reason.
- Settings use large, static targets. One labelled row per category with a standard spinner — no drag gestures, no long-press, no swipe actions, no timed interactions, no multi-touch anywhere in the app.
- The activity log exists for accountability. A user who cannot easily undo an action must be able to find out what was done on their behalf.
- The service can be paused instantly from a single large master toggle, and turned off entirely from Android's own Accessibility settings.
5. Conformance
Cookie Approval Plus aims to conform to WCAG 2.2 Level AA as applied to mobile applications, and follows the Android accessibility developer guidance including minimum touch target sizes, content labelling, and text scaling.
Self-assessment status: partially conformant. The following are known and tracked:
| Area | Status |
|---|---|
| Touch target size (2.5.8) | All interactive controls meet or exceed 48dp |
| Keyboard / switch operability (2.1.1) | All controls are reachable by directional navigation and switch access |
| Screen-reader labelling (1.1.1, 4.1.2) | All controls carry text labels; decorative emoji are supplementary to labelled text |
| Text resizing (1.4.4) | Layouts are scrolling and use scalable text units |
| Colour contrast (1.4.3) | Meets AA against the app's surface colours |
| No timing (2.2.1) | No time limit exists anywhere in the app |
| No motion or gesture requirement (2.5.1, 2.5.4) | The app requires no path-based gesture, shake, or tilt |
| Dark theme / reduced brightness sensitivity | Supported |
| Localisation of the interface | The interface, the first-run disclosure and the consent acknowledgement are available in English, German, French, Spanish, Italian, Dutch, Polish and Portuguese. The Nordic languages are detected but the interface is not yet translated into them. |
If you encounter an accessibility barrier in the app itself, please tell us — see §7. Accessibility defect reports are treated as priority bugs.
6. What the app is not
Stated plainly, because it matters both to users and to reviewers:
- It is not a privacy tool. Accepting consent banners means consenting to those sites' tracking. The app reduces the physical friction of consenting; it does not reduce tracking. This is disclosed on first run and in the store listing.
- It is not a general-purpose automation or macro framework. It acts only on recognised consent and permission prompts, and refuses consequential controls outright.
- It is not a way to bypass a site's consent requirements, a paywall, or any security control. It presses the same button the user would have pressed.
7. Feedback and contact
We want to hear about barriers, including barriers in this app.
Casinos Custom, LLC
- app.dev@casinoscustom.com
- support@casinoscustom.com
We aim to respond within 5 business days, and to fix confirmed accessibility defects in the next release.
If you use a communication method we have not listed and it would help you to reach us another way, tell us and we will accommodate it.