Manual accessibility review guide: Part 1
When it comes to accessibility, there are some checks an automated tool can't make. That's where manual testing comes in.
Automated accessibility tools catch a lot, but they can't catch everything. An automated accessibility scanner can measure whether an alt attribute exists or whether your colour contrast hits a ratio. But what it can't do is tell you whether your site actually works for someone navigating with a keyboard or a screen reader.
Roughly half of the Web Content Accessibility Guidelines (WCAG) success criteria can't be checked by a machine. So half of your site's accessibility comes down to a person testing it by hand. Insytful handles the automated half, so you can spend your time on the checks a machine can't do.
The good news: most of these checks need no special software. Just your keyboard, a browser, and a few minutes. This guide walks through four of them. If you'd like to see them in action first, you can catch up on our recent manual accessibility testing webinar.
Manual tests covered in this guide
In this guide we cover manual tests for WCAG A and AA.
We strongly recommend aiming for AA, it's the standard public sector organisations are expected to meet. A is a useful checkpoint along the way, but on its own it's the bare minimum and won't meet public sector requirements. Skip to:
Before you get started
- Put your mouse away. Every check below is done from the keyboard. Using a mouse defeats the point.
- Know which keys do what. Tab moves forward, Shift+Tab moves back, Enter and Space activate a control, and arrow keys move within a component such as a menu or a radio group.
- Test in the browser your audience actually uses. Focus behaviour can differ between Chrome, Firefox and Safari, so a pass in one isn't a pass in all.
- Write down the page URL and what failed. A finding you can't locate again isn't something you can fix.
What success looks like: if you can reach every control with Tab and always see where you are on the page, you've already cleared the checks that trip up most public-facing sites.
1. Tab order and focus rings
Keyboard users move through a page with the Tab key, and the focus ring is their cursor, it's the only thing that shows where they are. For that to work, focus has to do two things at once: move in an order that matches how the page reads, and stay visible at every step.
How to test tab order and focus rings
- Put the mouse away. Press Tab from the top of the page to the bottom.
- Follow the focus ring with your eyes. It should move in a predictable path: skip link, header and navigation, main content in reading order, then footer. There should be no jumps into the footer and back, or into a sidebar mid-sentence.
- Check you can always see which element is focused. The indicator should have clear contrast and never vanish, including on buttons, images and dark backgrounds.
- Watch for focus stopping on something that isn't interactive, like a plain heading. That's usually a sign of a stray
tabindex.
Passes manual check criteria for
Level A: Focus moves in reading order and you can always see, at a glance, where it is - preserving meaning and operability.
Level AA: Your page has a visible focus indicator on every focusable element, at every step.
Fails manual checks when: The order contradicts the visual layout, or focus lands somewhere with no visible indicator. A common cause of the latter is outline: none in the CSS with nothing put back in its place.
2. Link text makes sense on its own
Screen-reader users often navigate a page using a list of every link on a page. In that list, the links are pulled out of the surrounding text, so "click here" or "read more" repeated ten times tells them nothing.
At Level A, WCAG does allow the surrounding sentence or list item to supply the meaning. So a "Click here" link can pass Level A, as long as the text around it makes the destination clear. If it doesn't, that's a Level A failure, and since AA includes every Level A criterion, you can't claim AA either. Making each link's text stand on its own regardless of context is Level AAA (2.4.9). It isn't required for AA, but it's the safer target and we would recommend it, because it creates clarity when a screen reader user pulls up a list of every link on the page with the surrounding text stripped away.
How to test link text is descriptive
- Read down the page looking only at the linked words, ignoring the surrounding text.
- For each one, ask: if this were the only thing I could read, would I know where it leads?
- Flag any generic labels such as "click here", "read more", "learn more", "download". None of these name their destination, so that's a AAA failure, and a Level A failure too if the test around the link doesn't make the destination clear.
- Watch the reverse too: two links with the same text should go to the same place. If they lead somewhere different, the text needs to tell them apart.
Passes manual check criteria for
Level A: Each link's purpose is clear from its text, or from the sentence, list item or table cell it sits in.
Level AAA: Each link's text describes its destination on its own — "Download the 2026 prospectus" rather than "Download".
Fails manual checks when: A link's purpose can't be worked out even with the text around it, or several links with the same label lead to different places.
3. Alt text is actually useful
A scanner can tell you whether an alt attribute exists. But it can't tell you whether the text is any good, that's a judgement only a person can make. Good alt text gives a screen-reader the same information or function the image gives a sighted user. And decorative images should have empty alt text so screen readers skip them.
How to test alt text is useful
- For each meaningful image, ask: if this image disappeared, does the alt text give the reader the same information or purpose?
- Check that alt text is specific. For example, "Bar chart showing applications up 30% since 2024", not "chart" or "image".
- Confirm decorative images (dividers, background flourishes) have empty alt text (
alt="") so they're skipped, rather than being read aloud as a filename. - For an image that is also a link, check the alt text describes the destination, not the picture.
Passes manual check criteria for
Level A: Meaningful images convey their information or function; decorative ones are hidden from screen readers.
Fails manual checks when: Alt text is missing, a bare filename, unhelpfully generic, or a description sits on a purely decorative image.
4. The page holds up when text gets bigger
Many people with reduced vision will browse your website zoomed in - often at 200%, and sometimes as far as 400%. Two separate WCAG requirements cover this, and it's worth knowing which is which because they fail in different ways and get fixed in different ways.
Resize Text is about size. Can someone make the text twice as big without your page breaking? A page that fails here cuts text off, overlaps it, or hides a button.
Reflow is about width. Does the page still work when it's squeezed into a narrow space, roughly the width of a phone? A page that fails here forces you to scroll sideways as well as down to read a sentence.
Zooming in does both at once - it makes text bigger and leaves less room for it - which is why the two get confused. You can test them in one sitting, but check them separately.
How to test that your text can be resized
- Zoom the browser to 200% (Ctrl/Cmd and +, until you hit the right zoom amount).
- Read through the whole page and confirm all text is still visible and readable.
- Check nothing overlaps, gets cut off, or disappears - watch menus, buttons and form fields especially.
- Check all of the controls on your page still work - menus open, forms can be filled in and submitted.
Passes Level AA (1.4.4) when: at 200%, nothing has disappeared, been clipped or become unreadable, and everything still works.
How to test the page reflows
- Set your browser window to about 1280 pixels wide, then zoom to 400%. That combination produces the narrow width this criterion is measured at - about the width of a small phone. If you leave the window maximised on a wide monitor, the test is too easy and a real failure will slip past you.
- Read down the page. Scrolling down is expected and fine.
- The thing you're looking for is scrolling sideways as well as down. If you have to scroll right to reach the end of a sentence or to find a button, that's a Reflow failure.
- Check nothing has disappeared. Some layouts hide content at narrow widths rather than reflowing it.
Passes Level AA (1.4.10) when: at that width everything is still present and usable, and you only ever scroll in one direction.
Fails manual checks when: Text overlaps or is clipped, controls become unreachable, or you're forced to scroll sideways to read.
Note: Some content is allowed to break this rule. Content that genuinely needs two dimensional scrolling is an exception: maps, diagrams, video, presentations and data tables. A wide data table you scroll sideways is not a failure.
When you've worked through the list
These four checks catch the accessibility problems that show up most often and that users notice most. Once your page clears them, the next part of the series moves from what users can see to what they can operate.
And if your page passes all four, it's already ahead of most sites in the public and higher-education sectors. For the fuller picture, read parts two and three of this guide to cover the rest of the manual checks.
If you'd rather have a specialist run a full manual audit against the complete WCAG 2.2 AA conformance checks, that's something the Zengenti accessibility team can do for you. Get in touch and we'll talk it through.

