How to Test Keyboard Navigation on Your Charity Website
Key takeaways
- A keyboard test needs no software: Tab, Shift+Tab, Enter, Space, the arrow keys and Esc are enough to find most keyboard failures on a page.
- On a Mac, Safari's Tab key skips links until "Press Tab to highlight each item on a webpage" is turned on in Safari's Advanced settings, so test there with that setting on.
- WCAG 2.2 requires every function to work from a keyboard (2.1.1) and requires that focus never gets trapped in a component (2.1.2).
- You must always be able to see where the keyboard is (2.4.7), and since WCAG 2.2 the focused item must not be completely hidden behind a sticky header or banner (2.4.11).
- Test the journeys the site exists for: the homepage, the donation form up to the payment step, the contact form, the newsletter sign-up and the cookie banner on a first visit.
Summary
Put the mouse away and try to use your own website with the keyboard alone. Tab and Shift+Tab move between links, buttons and fields; Enter follows a link; Space presses a button or ticks a box; the arrow keys move inside menus, radio groups and dropdowns; Esc closes what opened. This page lists what each key should do, the six things to check on the journeys that matter, and the WCAG 2.2 criterion behind each one, so a failure can be written down rather than argued about.
The Short Answer
Put the mouse to one side and try to use your website with the keyboard alone. Find out what you do, make a donation up to the payment step, and send a message through the contact form. If you cannot reach something, cannot see where you are, or cannot get out of something you got into, a keyboard user cannot either.
That group is larger than it sounds. WebAIM notes that "many users with motor disabilities rely on a keyboard", and that "blind users also typically use a keyboard for navigation". A page that fails with a keyboard usually fails for them as well.
Information checked against the sources linked below on 14 October 2026.
Before You Start: One Setting on a Mac
On Windows there is nothing to set. On a Mac, Safari skips links by default: Tab moves only between form fields and pop-up menus, and Option-Tab reaches links. Apple's own guidance is to turn on "Press Tab to highlight each item on a webpage" in the Advanced pane of Safari settings, and Keyboard Navigation in the Mac's Keyboard settings so that buttons and other controls are reached too.
Skip this step and Safari will make a working site look broken.
The Keys and What Each One Should Do
| Key | What it should do | What a failure looks like |
|---|---|---|
| Tab | Move to the next link, button or form field | Something you can click is never reached |
| Shift+Tab | Move back to the previous one | Focus jumps somewhere unexpected |
| Enter | Follow a link or press a button | Nothing happens, or only a mouse click works |
| Space | Press a button, tick a checkbox, open a dropdown | The page scrolls instead of the control responding |
| Arrow keys | Move between options in a radio group, dropdown, set of tabs or menu | Arrowing through a dropdown selects the first option and leaves the page |
| Esc | Close a dialog, pop-up, menu or cookie banner | The pop-up stays open and the page behind it cannot be reached |
The full list of expected keystrokes for each type of control is in WebAIM's keyboard guide, and the W3C's Easy Checks walk through the same test.
Six Things to Check
1. Can you always see where you are? Every link, button and field needs a visible outline or highlight when it has keyboard focus. If you lose track of the focus between presses, so will everyone else. This is WCAG 2.2 success criterion 2.4.7, Focus Visible.
2. Is the focus ever hidden? A sticky header, a chat widget or a cookie banner can sit on top of the item that has focus. Since WCAG 2.2 that is a failure when the focused item is completely hidden: 2.4.11, Focus Not Obscured.
3. Does the order make sense? Focus should move in the order you would read the page, top to bottom and left to right for English. Focus that leaps from the header to the footer and back is 2.4.3, Focus Order.
4. Can you skip the navigation? On many sites the first press of Tab shows a "Skip to content" link. Without one, a keyboard user tabs through every menu item on every page before reaching the content. A skip link is the usual way to meet 2.4.1, Bypass Blocks.
5. Can you do everything? Open the main menu and its dropdowns, expand an accordion, move a carousel, play a video, choose a donation amount and submit the form. Anything that only works on hover or click fails 2.1.1, Keyboard.
6. Can you get out? Tab into the video player, the embedded map, the donation widget and any pop-up, then try to Tab or Esc out again. A component you cannot leave is a keyboard trap and fails 2.1.2, No Keyboard Trap. When a dialog closes, focus should go back to the button that opened it, which is the behaviour the W3C's dialog pattern describes.
Where to Run It
Not every page. The journeys the site exists for:
- the homepage and main navigation, including every dropdown;
- the donation page, through every step up to payment (stop before you pay);
- the contact form, including what happens when you submit it with a field missing;
- the newsletter sign-up;
- the cookie banner on a first visit, in a private window.
Write down each failure as the page, the key you pressed and what happened. "Donate page, Tab, focus disappears after the amount buttons" can be fixed and checked again. "The donate page is not accessible" cannot.
What This Test Does Not Cover
It tests one part of WCAG 2.2. It does not tell you what a screen reader announces, whether text has enough contrast, whether images have useful alternatives or whether the page still works at 400% zoom. The wider picture is in website accessibility for nonprofits, and if your site publishes an accessibility statement, the template shows what it should say about known problems like the ones this test finds.
Your accessibility statement makes a claim about your website. A keyboard is the cheapest way to find out whether the claim is true.
If you want the whole site tested rather than its main journeys, the Blueprint Audit runs a manual WCAG 2.2 AA review of every unique template and key journey, by keyboard, NVDA and VoiceOver, and says which failures matter most.
Two clicks. Three things.
Send the address of your website. Within two working days you get a short email naming the three things a funder would hold against it, including what AI assistants like ChatGPT and Google’s AI Overviews currently say about you. No report, no call, no follow-up unless you ask.
Received. Your three things arrive within two working days.
That did not send. Email hello@socialectric.com with your website address and I will reply from there.
Frequently asked questions
- Which keys do I need to test keyboard accessibility?
Six: Tab to move forward, Shift+Tab to move back, Enter to follow a link or press a button, Space to press a button or tick a checkbox, the arrow keys to move inside radio groups, dropdowns, tabs and menus, and Esc to close a dialog or pop-up. WebAIM's keyboard guide lists the expected keystroke for each type of control.
- Why does Tab skip links in Safari on my Mac?
By default Safari's Tab key moves only between form fields and pop-up menus, and Option-Tab reaches links. Apple's Safari shortcuts page says to turn on "Press Tab to highlight each item on a webpage" in the Advanced pane of Safari settings to swap them, and to turn on Keyboard Navigation in the Mac's Keyboard settings so Tab also reaches buttons and other controls.
- What is a keyboard trap?
A component that the keyboard can enter but not leave: a video player, an embedded map or a pop-up where Tab goes round and round inside it and nothing gets you out. WCAG 2.2 success criterion 2.1.2 requires that focus can always be moved away, and a trap is a Level A failure.
- Does passing a keyboard test mean our website is accessible?
No. It tests one part of WCAG 2.2: whether the site can be reached, seen and operated from a keyboard. It does not test what a screen reader announces, colour contrast, text alternatives or how the page reflows when zoomed. It is a fast way to find serious failures, not a conformance check.
- Who on our team should run this test?
Anyone who can follow the steps, which is why it is worth doing in-house before and after every change to a template or form. Give the results to whoever is responsible for the website, with the page, the key pressed and what happened, so each failure can be fixed and checked again.