Regularly testing your website for accessibility helps ensure that everyone, including people with disabilities, can navigate, understand, and interact with your content. Automated testing is a good starting point for finding common, detectable issues, but it can only identify part of the problem.
Many accessibility issues can only be uncovered through manual testing. Manual accessibility testing involves using a keyboard and screen reader, along with human judgment, to review how the website actually behaves and feels to use.
This guide shows you how to manually test your website in a structured, beginner-friendly way. It explains how to approach testing, what to pay attention to, and how to identify issues that may affect real users as they navigate and interact with your content.
What to Do Before Manual Accessibility Testing
Before jumping into manual accessibility testing, it is important to run automated checks first.
Automated testing is good at finding programmatically detectable accessibility issues across many web pages at once. Fixing these issues early reduces the number of problems you encounter during manual testing, making the manual review more focused and effective.
However, automated accessibility testing tools have limitations. It cannot assess whether content is easy to understand, whether navigation feels logical, or whether interactions make sense to real users. That is where manual accessibility testing becomes essential.
How to Manually Test Your Website for Accessibility
To manually test your website, focus on four key areas: keyboard access, screen reader experience, content clarity, and visual presentation. These areas help you understand how different users interact with your site and whether they can complete basic tasks without barriers.
- Keyboard testing: This checks whether users can navigate and interact with the website using only a keyboard, without relying on a mouse.
- Screen reader testing: This checks whether page structure and content make sense when read aloud, and whether changes like pop-ups opening or sections expanding are announced clearly.
- Content review: This checks whether information is clear, easy to understand, and well structured, no matter how users read or navigate through the page.
- Visual check: This checks whether content is easy to see and use when text is resized, the page is zoomed, or colors are removed.
Together, these four areas form the foundation of manual accessibility testing and help uncover the most common issues that affect real users.
How to Do Keyboard Testing
Keyboard testing checks whether users can navigate and interact with your website without using a mouse. Many users rely on a keyboard to browse the web, so this test is essential.
To start, set your mouse aside and use only your keyboard.
Use the Tab key to move forward through links, buttons, and form fields, and Shift + Tab to move backward. Use Enter to activate links, and use Enter or Space to activate buttons, accordions, and other interactive elements. And use Escape to close menus or dialogs when available.
Here are the checks you need to perform.
Check #1: Is a visible focus indicator present on every interactive element?
When you tab to a link, button, or form field, you should clearly see where focus is on the page.
- Pass: A clear visual indicator, such as an outline, border, underline, or background change, appears around the focused element.
- Fail: No visual change appears when an element receives focus, or the focus indicator is too faint or hidden to notice.
Bad example:
Good example:
Check #2: Does the navigation order follow a logical flow?
As you tab through the page, does focus move in a way that matches the visual layout, usually left to right and top to bottom?
- Pass: Focus moves through links, buttons, and form fields in a predictable order that matches how the content appears on the screen.
- Fail: Focus jumps around the page in an unexpected order, skips sections, or moves back and forth between unrelated elements.
Bad example:
Good example:
Check #3: Can all menus and interactive elements be used with a keyboard?
Are dropdowns, navigation menus, dialogs, and custom widgets usable without mouse actions like hover or click?
- Pass: Menus and interactive elements respond correctly to keyboard input, allowing users to open, move through, and close them using Tab, Enter, Space, and Esc.
- Fail: Menus or interactive elements do not respond to keyboard input, or only work when using a mouse, even when Tab, Enter, Space, or Esc are used.
Bad example:
Good example:
Check #4: Is a “skip navigation” or “skip to content” link available and functioning correctly?
When the skip link is activated, does focus land on the main content so the user can continue navigating from there?
- Pass: A “skip navigation” or “skip to content” link appears during keyboard navigation, and activating it moves focus to the main content area.
- Fail: No skip link is available, or activating it does not move focus to the main content area.
Bad example:
Good example:
Check #5: Can all forms be completed using only a keyboard?
Are all input fields, buttons, and controls reachable and usable without a mouse?
- Pass: All form fields and controls can be reached, filled, and submitted using Tab, Enter, and Space.
- Fail: One or more form fields or controls cannot be reached, filled, or submitted using the keyboard alone.
Bad example:
Good example:
Check #6: Do dialogs and popups behave correctly with the keyboard?
Can you open and close them using the keyboard? Does pressing Esc close them?
- Pass: Keyboard actions such as Enter, Space, and Esc allow dialogs or popups to open, close, and return focus to the page.
- Fail: Dialogs or popups do not respond to keyboard actions, remain open when Esc is pressed, or trap focus, meaning the keyboard cannot move out of the dialog.
Good example:
Check #6: Does focus return to a logical place after closing a dialog?
When a popup closes, does focus return to the element that triggered it or another sensible location?
- Pass: After closing the dialog, focus moves back to the element that opened it or another appropriate place on the page.
- Fail: After closing the dialog, focus is lost, moves to an unrelated part of the page, or returns to the start of the page.
Good example:
How to Do Screen Reader Testing
Screen reader testing checks whether your website makes sense when content is read aloud instead of displayed visually.
To begin, turn on a screen reader such as NVDA on Windows or VoiceOver on macOS. Start at the top of the page and let the screen reader read through the content. You do not need to use advanced commands. Simply listening is enough to identify many issues.
Here are the checks you need to perform.
Check #1: Is the page title clear and descriptive?
When the page loads, does the screen reader announce a title that explains what the page is about?
- Pass: The page title clearly describes the content or purpose of the page.
- Fail: The page title is missing, generic, or does not explain what the page is about.
Bad example:
“Contact Us”
The page purpose is clear, but the title does not identify the website. This can be an issue for screen reader users or when navigating browser tabs, bookmarks, or history, where only the page title is available and “Contact Us” lacks enough context.
Good example:
“Contact Us – WebYes”
Including the site name in the page title provides helpful context. “Contact Us – WebYes” clearly communicates both the purpose of the page and which website it belongs to, making it easier to identify when navigating between tabs, bookmarks, or using a screen reader.
Check #2: Do headings follow a logical order?
As you move through headings, do they form a clear structure that helps users understand and navigate the page?
- Pass: Headings are used in a clear hierarchy that reflects the structure of the page.
- Fail: Headings are skipped, out of order, or used only for visual styling.
Bad example: The page jumps from an H1 directly to an H4, or uses H3 and H2 headings inconsistently just to make text look bigger.
Good example: The page uses a single H1 for the main title, H2 headings for major sections, and H3 headings for subsections within those sections.
Check #3: Are all focusable elements announced correctly?
As you tab through the page, does the screen reader clearly announce each focusable element, including links, buttons, and form fields?
- Pass: Each focusable element is announced with a clear name and role, so it is obvious what the element is and what it does.
- Fail: Focusable elements are announced without a name, with a generic label, or not announced at all.
Bad example:
The screen reader announces:
“Button” or “Unlabeled”
This does not explain what the element does or why it is there.
Good example:
The screen reader announces:
“Search, edit text” or “Submit, button”
This clearly tells the user what the element is and its purpose.
Check #4: Are links understandable on their own?
When links are announced, do they explain where they lead or what they do, without relying on surrounding text?
- Pass: Links are announced with text that clearly describes their destination or action.
- Fail: Links are announced with generic or unclear text that does not make sense on its own.
Bad example:
The screen reader announces:
“Read more” or “Click here”
Good example:
The screen reader announces:
“Download accessibility checklist”
Check #5: Are images announced appropriately?
Do meaningful images have descriptions that explain their purpose? Are decorative images skipped?
- Pass: Meaningful images are announced with helpful descriptions, and decorative images are skipped by the screen reader.
- Fail: Images are announced without useful descriptions, announced unnecessarily, or not handled correctly.
Bad example:
The screen reader announces:
“Image” or reads out a decorative icon that adds no information.
Good example:
The screen reader announces:
“Screenshot showing a form error under the email field.”
Check #6: Is dynamic content announced when it changes?
If content updates based on user actions, such as form validation, alerts, or live updates, are those changes announced clearly by the screen reader?
- Pass: When content changes, the screen reader announces the update automatically.
- Fail: Content changes visually, but the screen reader does not announce anything.
Bad example:
A form shows an error message after submission, but the screen reader remains silent.
Good example:
After submitting the form, the screen reader announces:
“Error: Email address is required.”
Check #7: Are form instructions and error messages announced at the right time?
When focus moves to a form field, are instructions and error feedback read out clearly so users know what to do?
- Pass: Instructions and error messages are announced when focus moves to the field or when an error occurs.
- Fail: Instructions or errors are shown visually but not announced when needed.
Bad example:
An error message appears below a field, but the screen reader does not announce it when focus is on the field.
Good example:
When focus moves to the field, the screen reader announces:
“Password must be at least eight characters.”
Check #8: Are custom widgets announced and navigable?
Can you move through custom components like dropdowns, tabs, or sliders, and does the screen reader announce their role, state, and value correctly?
- Pass: Custom widgets are announced with their role and state, and can be navigated using the keyboard.
- Fail: Custom widgets are announced without context, missing roles, or cannot be navigated properly.
Bad example:
The screen reader announces:
“Clickable” with no information about what the element does.
Good example:
The screen reader announces:
“Dropdown menu, collapsed” or “Tab, selected.”
How to Do Content Review
Content review checks whether the information on your website is clear, understandable, and easy to follow for all users.
To begin, read through the page visually and carefully. Focus on how information is written, structured, and explained. You are checking whether users can understand what the page is about and what they need to do next.
Here are the checks you need to perform.
Check #1: Is the purpose of the page clear?
Can a user quickly understand what this page is for and what they can do here?
- Pass: The page clearly explains what it is for within the first few seconds of viewing it.
- Fail: The page purpose is unclear, and users must scroll or guess to understand it.
Bad example: The page starts with a heading like “We’re Here for You” and shows a form immediately, but does not explain whether this is for sales, feedback, technical support, or general inquiries. Users have to infer the purpose from the form fields.
Good example: The page starts with “Contact Support” and a short line like “Use this page to report issues, ask questions, or get help with your account.” There is no doubt about why the page exists or what the user should do.
Check #2: Is the language simple and direct?
Are sentences easy to read, avoiding jargon, complex phrases, or unnecessary detail?
- Pass: The content uses clear, plain language that everyone can easily read and understand.
- Fail: The content uses complex words, jargon, or long sentences that make it hard for many people to understand.
Bad example:
“To continue, please ensure that all mandatory registration requirements have been fulfilled.”
This uses formal language and extra words that make it harder to understand.
Good example:
“Please complete all required fields to continue.”
This says exactly what to do in clear, simple words.
Check #3: Are instructions clear and specific?
Do instructions explain exactly what action to take, without relying on visual cues like color, icons, or placement?
- Pass: Instructions use clear words to guide the user, making it obvious what needs to be done next without needing to see the page layout.
- Fail: The instruction does not clearly tell the user what to do, so they have to guess the required action or look for visual hints to proceed.
Good example:
“All required fields are marked with an asterisk (*). Please complete all required fields before submitting the form.”
This explains what to look for and what action to take using words.
Bad example:
“Please fill in all fields marked in red.”
This relies on color alone and does not clearly explain what the user should do.
Check #4: Do links and buttons use meaningful text?
Do labels clearly describe the action or destination, rather than using vague terms?
- Pass: Links and buttons use text that clearly describes their purpose or destination without needing extra context.
- Fail: Links or buttons use vague or generic text that does not clearly explain what they do or where they lead.
Bad example:
A button or link uses text like “Click here,” “Read more,” or “Learn more,” which does not explain the action or destination on its own.
Good example:
A button or link uses text like “Download accessibility checklist” or “View pricing details,” making it clear what will happen when it is selected.
Check #5: Are error messages written clearly?
When errors occur, do messages explain what went wrong and what the user should do next?
- Pass: Error messages clearly explain the problem and give a clear next step to fix it.
- Fail: Error messages are vague, technical, or do not explain how to fix the issue.
Bad example:
“Invalid input” or “Something went wrong.”
Good example:
“Email address is required. Please enter a valid email to continue.”
Check #6: Is alt text accurate and meaningful where images are used?
Does the alt text describe the purpose of the image and add useful context, rather than repeating nearby text or being overly vague?
- Pass: Alt text clearly explains what the image is for and adds information that helps users understand the content.
- Fail: Alt text is missing, too vague, too long, or simply repeats nearby text without adding meaning.
Bad example:
Alt text says “image,” “chart,” or repeats the heading above the image without explaining its purpose.
Good example:
For a chart showing test results, the alt text says:
“Bar chart comparing passed and failed accessibility checks.”
How to Do Visual Checks
Visual checks focus on how your website looks and behaves under different viewing conditions. This helps you understand whether users can read content, recognize key elements, and interact with the site when visual cues are limited.
To begin, view the page normally and then adjust the zoom level in your browser. You can also switch your display to grayscale to review how the page works without color.
Here are the checks you need to perform.
Check #1: Is text easy to read at different zoom levels?
When you zoom the page to around 200 percent, does the text remain readable without overlapping or becoming cut off?
- Pass: When the page is zoomed to around 200 percent, text remains readable without overlapping, truncation, or loss of content.
- Fail: When the page is zoomed, text overlaps, gets cut off, or becomes difficult to read.
Check #2: Does the layout adapt without breaking?
When zoomed or resized, does the page reflow properly, or does it introduce horizontal scrolling and broken layouts?
- Pass: The page reflows properly when zoomed or resized, without introducing horizontal scrolling or broken layouts.
- Fail: Zooming or resizing causes horizontal scrolling, overlapping elements, or broken layout sections.
Check #3: Is spacing comfortable and consistent?
Are lines of text, paragraphs, and sections spaced well enough to read without feeling crowded?
- Pass: Text, paragraphs, and sections have enough spacing to remain easy to read and visually clear.
- Fail: Content appears cramped, crowded, or inconsistent, making it harder to read.
Check #4: Does the page still make sense in grayscale?
When color is removed, can users still understand what is important, such as errors, active states, or selected items?
- Pass: Important information remains clear without color, and meaning is not lost when color is removed.
- Fail: Important information relies on color alone and becomes unclear when viewed in grayscale.
Bad example:
Good example:
Which Pages Should You Manually Test?
You could manually test every page on your website, but time and resources are limited, which is why page sampling is recommended. Page sampling involves testing a small, representative set of pages to assess the overall accessibility of your website, without reviewing every page individually.
There are two ways to approach page sampling.
#1. Test pages based on your main website goals
The first approach is to select pages based on the primary goals of your website. These are the actions users come to your site to complete. Instead of testing single pages in isolation, you test the full journey from start to finish.
Examples of goal-based flows include:
- Applying to a university or course
- Completing a checkout process
- Booking an appointment
- Submitting a contact or support form
When testing these flows, focus on whether users can complete the entire journey without running into barriers. You are evaluating the overall experience, not individual issues. If a key journey is difficult or impossible to complete, it creates a serious accessibility barrier for users.
#2. Use a simple page sample
The second approach is to build a small sample of page types that represent how your website is structured overall. This method works especially well when your site has many similar pages or when clear user flows are less defined or harder to identify.
At a minimum, your page sample should include:
- The homepage, which usually contains navigation, featured content, and key links
- A prominent content page, such as a blog post, article, or product information page
- A prominent page with a form, such as a contact page, sign-up page, or checkout page
- One random internal page to help uncover unexpected issues
This mix of pages gives you a clearer picture of how accessible your website is across different layouts, templates, and shared components. It helps you understand how accessibility holds up in both content-heavy pages and interactive areas of the site.
What to Do After Manual Accessibility Testing
Manual accessibility testing helps you spot real usability issues. The next step is to use what you found to make steady, meaningful improvements.
After completing your manual checks, focus on the following actions:
- Review and group issues
Look through the issues you identified and group similar ones together. Many problems repeat across pages because they come from shared layouts, components, or content patterns. - Prioritize what to fix first
Start with issues that block users from completing key tasks. Problems that affect keyboard access or screen reader use should be addressed before smaller visual or content issues. - Fix issues at the source
Whenever possible, fix problems in templates, components, or shared content styles. This helps improve accessibility across multiple pages at once. - Re-test after making changes
After fixing issues, manually re-test the affected pages using the same checks. This confirms that the fixes work and that no new barriers were introduced. - Make manual testing part of your routine
Manual accessibility testing works best when done regularly on a small set of pages. This keeps accessibility improvements manageable and ongoing.
Manual testing helps you see where real accessibility barriers exist on your website. By reviewing what you found, fixing issues at the source, and re-testing your changes, you can steadily remove those barriers and reduce the chance of them returning in the future.
AUTHOR
Melwyn holds a Bachelor's degree in Computer Science and has been writing professionally for over 4 years. He has a strong background in SEO and is certified in web accessibility from the World Wide Web Consortium (W3C). When he's not writing about website optimisation, you can find him enjoying a game of FIFA or exploring the open world of GTA.
Melwyn Joseph 
