Accessibility
What is built, how it was checked, and what we have not checked. This is a statement of fact about our own work, not a certification.
Hedroom has not launched, so nobody outside the project has used it yet. We make no claim of conformance with WCAG or any other standard. The checks below are ones we wrote ourselves, and they have limits that we list.
What is built into the app
- VoiceOver. Every control has a label. Tiles are labeled groups. Toggles, pickers and segments announce their value or which option is selected. Charts have a spoken summary, for example "Memory pressure strained for 17 minutes, now improving". The memory gauge reads the word (Healthy, Strained, Critical) and not only a color.
- Spoken progress. Pressure changes, each step of a relaunch, cleanup progress and finish, and error cards are announced without moving your focus.
- Target size. Anything clickable is at least 44 pt, except dense lists such as the app rows, which are 28 pt with the whole row clickable.
- Keyboard. Every control is a real button, toggle or field, so Tab and Full Keyboard Access reach it. Command-1 to Command-7 switch tabs, Command-comma opens Settings, Return activates a sheet's main button and Esc cancels. The license sheet puts focus in the key field when it opens.
- Light and dark. Both themes are designed and checked, with text contrast of at least 4.5:1 and 3:1 for large numbers and interface parts, checked for every tile color in both themes.
- Increase Contrast and Reduce Transparency. Secondary text turns to full ink, tiles, chips and rows get a 1 pt outline, and translucent areas become opaque.
- Reduce Motion. No breathing or pulsing, charts update without sliding, numbers swap without rolling.
- Text size. Type scales with the system text size and Hedroom's own text scale from 1.0 to 2.0. Tiles grow and sheets widen so nothing is cut off.
- Color is never the only signal. Pressure and status always carry a word next to the color.
How it was audited
An automated audit builds each screen, sheet, window and popover from fixture data and reads its live accessibility tree, the same tree VoiceOver reads. It runs as a test, and the test fails if it finds anything. It checks that:
- every control has a label, and images are not exposed without a description;
- sibling controls do not share the same label;
- every tile has a label, every screen has a heading, and charts have a summary;
- toggles, pickers and segments expose a value or selected state;
- hit areas are at least 44 by 44 pt (dense rows 28 pt, marked as dense);
- reading order matches visual order, and clickable things have a control role.
The most recent generated report covers 81 surfaces and 2,309 accessibility elements, with 0 findings. The first run, before any fix, found 221 (124 distinct): unlabeled tiles, hit areas under 44 pt, missing values and missing headings. They were fixed, and the test now fails on any finding.
Known gaps
These are the limits of the audit, as it records them.
- Scrolling content. Tab bodies are audited without the scroll view that wraps them in the real window, because SwiftUI scroll content is not visible to an in-process check. The top bar is audited on its own. How the screens read when scrolled is not covered by the automated audit.
- Text fields. The AppKit-backed text fields get their label through a labeled group. The audit accepts a field that is the only input in such a group.
- Dense lists. Controls 28 pt high are accepted only where marked dense: app row buttons, Quit and Relaunch pills, and mode segments. They are under the 44 pt target on purpose.
- How it sounds. Spoken quality, focus return after a sheet closes, and Increase Contrast on a live system need a person. A written VoiceOver walkthrough of about 10 minutes exists for that, and we have no recorded result of it yet. Until it has been done on a real Mac with VoiceOver, treat the spoken wording as designed, not confirmed.
- The pages on this site use headings, landmarks, a skip link, visible focus and a stylesheet that respects dark mode and reduced motion. We have not run a formal audit of the website.
Report a problem
If something does not work with VoiceOver, the keyboard, your text size or your display settings, write to support@hedroom.app. It helps to tell us the screen, what you expected to hear or do, what happened instead, your macOS version and which assistive technology you use. An accessibility problem in the app is treated as a bug.