Accessibility Statement
Last updated: August 23, 2026
Rena is committed to making this product usable by everyone, including people who browse with a screen reader, navigate by keyboard, enlarge text, or use a display setting other than the default. This statement says what we measure against, what we have done, what we know is still short, and how to tell us when we have missed something.
It applies to projectrena.com, the Rena forum, and the Rena app for iPhone and Android.
The standard we measure against
WCAG 2.1, Level AA. This is the standard United States courts and regulators point to when they apply the Americans with Disabilities Act to a website or an app, and it is the standard we hold ourselves to on both surfaces.
Where this statement says a colour "measures" a certain ratio, that number was computed from the actual value in our source using the WCAG relative-luminance formula, including transparency composited over the background it sits on. We do not estimate contrast by eye, and we do not accept a passing grade from a tool without checking the arithmetic.
What we have done
Colour and contrast. Every text colour in the product was recomputed against the background it actually sits on, in both light and dark mode, and every value that fell short was raised. Where a colour failed in light mode and passed in dark, or the reverse, it became a token with a value for each rather than one compromise for both. The outline of a control, whether a text field, an answer button or a secondary button, is held to the 3:1 minimum that applies to anything you need to see in order to know a control is there.
Names on every control. A placeholder inside a text field is not a label: it disappears the moment you type, and some screen readers never announce it. Every input, checkbox, select and text area in the product carries a real accessible name.
Errors that are spoken. When a form fails, the message is announced rather than only drawn. Submitting a form and hearing nothing is the single most common way a screen reader user gets stuck, and it is the failure we hunted hardest.
Keyboard operation. Dialogs can be closed with Escape, hold focus while they are open, and return focus to where it came from when they close. Focus is always visible. Every route carries a skip-to-content link.
Motion. The moving wall of posts on the home page honours your system's reduced-motion setting, and there is a pause control on the page itself for anyone whose setting is not turned on.
Structure. Headings are marked as headings, so a screen reader's heading list is a real table of contents rather than an empty list. Progress indicators report their value. Navigation announces which destination you are currently in.
Text size. The app never suppresses Dynamic Type, so the text size you set on your phone is the text size the app uses. The website does not lock pinch-zoom.
What is still short
We would rather publish this list than leave it out. Each of these is known, measured, and either scheduled or waiting on a design decision.
- The app's navigation bar. The tint that lights the destination you are currently in measures 1.26:1 against the bar behind it, below the 3:1 that Success Criterion 1.4.11 asks for. The current destination is announced correctly to a screen reader, so the information is not lost. But for a sighted user with low vision the visual cue is fainter than the standard requires. Fixing it means a different colour rather than a stronger one, which is a design decision in progress.
- The desktop cursor. The website replaces the system pointer with a custom cursor. This defeats operating-system settings for cursor size and for locating the pointer. It is under review.
- Content other people write. Forum posts, replies and profile text are written by members, and answers from the AI tools in Rena PRO are generated. We control the frame around that content: its structure, its contrast, how a reader moves through it. We do not control whether a member describes an image they post.
- Assistive-technology testing. Our audit was performed by reading and measuring the source rather than by driving VoiceOver, TalkBack, NVDA and JAWS through every screen. Source analysis catches a different set of problems than a real screen-reader session does, and it does not replace one.
Tell us when we get it wrong
If any part of Rena is difficult or impossible for you to use, we want to hear about it, and we would rather hear about it early than have you work around it.
Email: support@projectrena.com
Please tell us the page or screen, what you were trying to do, and what happened. If you can, tell us the browser or phone and the assistive technology you use. It usually turns a report we have to reproduce into one we can fix the same day.
We aim to acknowledge every accessibility report within two business days and to tell you either the fix or the timeline. If something we have not fixed yet is standing between you and something you need to do, say so, and we will find another way to get it done for you in the meantime.
The formal note
This statement describes our conformance with WCAG 2.1 Level AA as of the date above, including the exceptions listed under "What is still short." Accessibility is not a state a product arrives at once. Every release can introduce a regression, and ours are reviewed against this standard before they ship. This statement is updated when what it describes changes.