Accessibility

Last updated October 17, 2026.

Psychology.com Learn is meant to work for everyone, whatever you use to read, move and answer. We aim at WCAG 2.2 AA, the Web Content Accessibility Guidelines at level AA, and we do not claim more than that. This page says plainly what works today, what we test, where we know Learn still falls short, and where to write when something is out of reach.

What works

• Everything by keyboard. Every control in Learn works without a mouse. The number keys pick an answer, a tile or a picture, the arrow keys move a highlight, Enter picks and then checks, Backspace removes the last tile, Esc goes back or closes a sheet, and the letter keys open the tabs. Press ? on any screen for the full list of shortcuts. Inside a lesson one small chip names the next key, and the full key bar appears as soon as you press one.
• Screen readers. The result of every check is announced: the title, the correct answer after a miss and the Why are a live region, so you hear them without moving focus. The combo count and the tries count are status text in words. A form field we cannot accept is marked invalid, the reason is written under it and read out, and focus moves there. Pip and the other illustrations are decoration and are hidden from assistive technology.
• Reduced motion. The Reduce motion switch in Settings turns every screen change, card and celebration into a short fade, stops the confetti and leaves the counters at their numbers. If your phone or computer already asks for reduced motion, Learn follows that setting on its own.
• Forced colors. In a forced color mode such as Windows high contrast, buttons, answer cards, progress bars and focus rings keep visible borders and use the colors you chose instead of ours.
• Text size. Every font size in Learn is set in rem, so text follows the size you set in your browser or phone and the layout reflows around it. Nothing locks the text to a pixel size.
• A text path for voice items. A listening exercise can show its clue as text (Can't listen right now, or the L key) and still scores, and a speaking exercise takes a typed answer where the browser has no speech recognition or you would rather type. No sound or speech ever starts on its own: it waits for your tap or key press, and it stops when you leave the screen.
• Visible focus. Keyboard focus is shown with a honey ring on every control, and sheets move focus to their first button so Enter confirms them and Esc closes them.

What we test

An automated browser suite drives Learn through onboarding, a lesson of every track, the results, Settings and every route, in Chromium, Firefox and WebKit, at a phone width of 390 pixels and a desktop width of 1280 pixels. It runs the axe accessibility rules on the screens it opens and fails on a violation, on any page error, and on a key that stops working. A second suite reads the generated markup without a browser: that every course picture carries alternative text and every decorative drawing is marked as such, and that the live regions, the key hints and the names of the controls are where the code says they are. Both suites run before a change can go live.

Known limits

Our automated checks cover behavior, not appearance: neither can verify 1024px rendering, overlap, touch targets, keyboard viewport behavior, focus delivery with assistive technology, animation timing or PDF appearance. In plain words, these are the places where a barrier may stand that our tools cannot see:

• The three column layout on screens 1024 pixels wide and wider is built, but no test looks at it in a browser, so overlap or a control hidden behind another there would reach you before it reached us.
• Where focus lands after a screen change is checked with a browser, not with a screen reader or a switch device, so a screen reader may announce a new screen later than a sighted reader sees it.
• Touch target sizes and the space between them are not measured, and neither is how the answer box and the Check button sit above a phone keyboard on every device.
• The field guides you can download are PDF files drawn in your browser. Their text is real text, but their reading order and tagging have not been checked with a screen reader.
• The timing of animations is not measured, so an animation may run longer on a slow device than it should.

We work through this list, and we would rather hear about a barrier than guess at one.

How to report a barrier

If something in Learn is out of reach or unclear with your keyboard, screen reader, magnifier, voice control or any other assistive technology, tell us. Email hello@psychology.com and say which screen you were on, what you were using and what you expected to happen. A screenshot or a recording helps, but a sentence is enough. You can also press H on any screen in Learn, or open Help in Settings, and write in the Report a problem box; that note reaches us with the screen name and the app build and nothing else, so write to the address above if you want an answer. We read every report, and we answer from the address you wrote from.