Accessibility

What Solid Memo aims for so that everyone can use it, with a keyboard, a screen reader, zoomed in or on a phone: the target, what is checked automatically and what by hand, the gaps we know of, and how to report a barrier.

The target

The web app and Solid Memo Studio aim to meet WCAG 2.2 at level AA. This is a goal, not a claim of conformance: no full audit has been made, and the known gaps below are not met yet.

What the app does for it today:

• Keyboard: the screens are made to be used with the keyboard alone. The first Tab reaches "Skip to content", and as a screen opens the focus moves to its heading, so a screen reader says where you are (user-guide.md).
• Languages: each text says which language it is in, the app's own and a deck's alike, so a screen reader reads it in that language and right-to-left text, such as Arabic, reads right to left (i18n.md).
• Themes: a light and a dark theme, each with text at a contrast of 4.5:1 or more and the edges of fields at 3:1 (theme.md, below).
• Motion: the browser's "reduce motion" turns the animations off.
• Targets: buttons and links are 24px high at least, or far enough from their neighbors, as WCAG 2.2 asks; the Studio's rows and controls are about 28px high, or 44px with its Comfortable layout (studio.md).
• Shortcuts: the Studio's single-key shortcuts can be turned off (studio.md).

Checked automatically

CI checks all of this on every pull request, and npm run check all but the journeys:

• Every screen a journey visits: the user journeys run axe on the screen each step ends on, in the light and the dark theme, in each browser a journey runs in (on a phone too), with its rules for WCAG 2.0, 2.1 and 2.2 at levels A and AA. A violation fails the journey, and the report says which rule, on which element, with what axe found (harness/accessibility.ts). A violation that is let pass is listed there, in KNOWN_EXCEPTIONS, with its reason; today the list is empty.
• The lint: Biome's accessibility rules (missing labels, roles that don't exist, links without content and more) run on every component. A rule is turned off only for the files its reason holds for, with the reason in biome.jsonc (style.md).
• Contrast: unit tests check the contrast of muted text and of fields' edges on every surface, in both themes (style.test.ts).
• Names and roles: the journeys and the component tests find elements by their role and accessible name, as assistive technology does, so a button that loses its name fails a test (testing.md).
• Languages: component tests check that a card's text, in its fields too, is marked with its language.

Checked by hand

What a tool can't judge is checked by hand as a change is reviewed:

• that what a screen says, its alternative texts and its labels make sense, and that the order things are read in follows the screen;
• that a change can be made with the keyboard alone, the focus seen where it is and never trapped;
• that the screen still works zoomed to 200%, and at 320px wide;
• that a screen reader announces what changed, such as a saved edit or an error.

Known gaps

• Language in accessible names: a name built as one aria-label string, such as the Studio's cell buttons ("Back of كتاب: Book"), can't say the language of the deck's or card's text in it, so a screen reader reads that text in the app's language.
• Contrast tests: they cover some token pairs only, not every text and surface pair in both themes, and not the Studio's own stylesheet. axe checks the contrast of the screens the journeys visit.
• Focus under sticky parts: in the Studio, the sticky header, sticky columns and bulk bar can hide the row that has the focus.
• Screen readers: no pass with a screen reader is written down.
• Browsers: every journey runs in Chromium, but only those that differ between engines run in Firefox, WebKit and on a phone (testing.md), so axe sees the other screens in Chromium alone.
• What axe sees: it checks the screen each journey step ends on, not every state in between, and only what the journeys visit. It finds a part of all possible problems.

Report a barrier

If something in Solid Memo or the Studio is hard or impossible to use with your setup, open an issue with the bug report form. Say what you tried to do, what happened, and what you use: browser, screen reader or other assistive technology, and the device. It is labeled accessibility and handled as a bug. Discussions are open too, for a question or an idea (CONTRIBUTING.md).