A website can look polished and still make ordinary tasks difficult. A visitor may be unable to open your navigation without a mouse, lose track of which button is selected, or reach a form error without knowing how to correct it.
You do not need to become an accessibility specialist to start finding these problems. You can perform several useful checks yourself, document what happens, and give your developer a much clearer starting point.
On a recent WordPress remediation project, my work included a skip link, a main content landmark, more visible keyboard focus, and corrections to heading structure. Form-related checks remained part of the follow-up work. Each improvement addressed a specific obstacle; none established that the entire website was accessible.
This walkthrough focuses on navigation, page structure, and forms. It is a starting point for identifying barriers, not a complete accessibility audit.
1. Choose a task your visitors actually need to complete
Start with a useful task rather than clicking through random pages. For example:
- Find a service and request more information.
- Locate a staff member and their contact details.
- Open a resource and download a document.
- Complete a registration or inquiry form.
Choose one route through your website and write down the pages involved. Include any menus, accordions, popups, or forms along the way.
Test the public website while logged out of WordPress so the admin toolbar does not change the experience. Use a staging site for submissions that could create orders, bookings, or other real transactions.
Your first objective is simple: can someone complete this task, and where do they encounter difficulty?
2. Put the mouse aside and test keyboard navigation
Open the first page in your chosen journey. Then use the keyboard to move through it.
| Key | Typical behavior |
|---|---|
| Tab | Moves to the next focusable control, such as a link, button, or form field. |
| Shift + Tab | Moves to the previous focusable control. |
| Enter | Activates a link or button. |
| Space | Activates a focused button or toggles a checkbox. Outside a control, it may scroll the page. |
| Arrow keys | Operate certain controls, such as radio groups, select menus, and tab interfaces. |
| Escape | Commonly closes a modal dialog or dismisses an open menu, depending on the component. |
Browser and operating-system settings can affect keyboard navigation. If links are skipped throughout multiple unrelated websites, check those settings before concluding that your site is responsible. This is particularly relevant to keyboard navigation settings on macOS and Safari.
Watch for the point where the task becomes difficult
Can you reach the navigation? Open a submenu? Activate the main call to action? Move through an accordion?
Ordinary paragraphs and headings do not need to receive focus when you press Tab. You are checking interactive controls, not expecting the keyboard to stop on every piece of content.
If a button works with a mouse but cannot be reached or operated with the keyboard, record its label and location. That is a concrete issue your developer can investigate.
Check whether you can leave what you opened
Open any popup or modal dialog involved in the task. Try moving through its controls, closing it with the keyboard, and continuing where you left off.
A modal dialog normally keeps keyboard focus inside it while it is open. That is intentional. The problem is being unable to close it or return to the page using the keyboard.
After closing it, focus should usually return to the control that opened it, or another logical place in the workflow. If focus disappears or jumps somewhere unexpected, note that separately.
For more detail, see W3C guidance on modal dialog behavior (opens in a new window).
3. Check whether keyboard focus is visible
As you press Tab, look for a visible indication of the active control. This might be an outline, border, underline, or other clear change.
If you cannot tell which link or button will activate when you press Enter, a visitor may face the same uncertainty.
- Move through the header, main content, and footer.
- Check controls on both light and dark backgrounds.
- Watch for focus disappearing behind sticky headers, cookie banners, or overlays.
- Check that the indicator remains visible until you move to another control.
A style that looks clear on a white section may disappear on a dark banner. Review the actual backgrounds where the control appears.
If you find a problem, capture the focused control in a screenshot or short recording. Describe it specifically: “The Request a Quote button has no visible focus indicator on the dark homepage banner.”
A developer can then inspect whether focus styles were removed, overridden, clipped, or given insufficient contrast. Adding a border everywhere without checking the cause may leave part of the problem unresolved.
See W3C guidance on visible keyboard focus (opens in a new window).
4. Test whether visitors can skip repeated navigation
A skip link gives keyboard users a shortcut past repeated header content to the main content. It is often hidden until it receives focus.
To check it:
- Reload the page and begin navigating from the start of the document.
- Press Tab and look for a link such as “Skip to content.” It should appear early in the navigation order.
- Activate the link with Enter.
- Check that you reach the main content.
- Press Tab again and confirm that navigation continues from that area rather than restarting in the header.
A visible scroll jump alone does not establish that the shortcut works. The keyboard navigation position needs to follow the intended destination.
If you cannot find a skip link, record that finding rather than immediately declaring a failure. Other bypass mechanisms may exist and need evaluation. A working skip link is a straightforward approach for many websites.
Implementation guidance is available in W3C’s skip-link technique (opens in a new window).
5. Check the page structure behind the visual design
Large, bold text is not necessarily a heading in the page markup. Conversely, a small line of text may have been assigned a heading level simply to achieve a particular style.
Headings should communicate how the content is organized. Think of them as an outline:
H1: Website Maintenance
H2: What the service includes
H3: Software updates
H3: Backups and recovery
H3: Ongoing testing
H2: How the process works
H2: Request maintenance supportHow to inspect a heading
- Right-click a visible heading and choose Inspect in your browser.
- Look at the selected HTML and its surrounding elements.
- Check whether the text sits inside an
<h1>,<h2>, or another heading element. - Compare the level with the section’s place in the page outline.
If the selected element is a span inside an H2, it is still part of that heading. If it is only a paragraph styled to look like a heading, it may need different markup.
In WordPress, check the Heading block’s level setting. In a page builder, look for an HTML tag or heading-level option. Verify the published page too, since the theme may supply the page’s main heading separately.
Do not change heading levels just to alter font size. Adjust typography independently. Moving back from an H3 subsection to the next H2 section is normal; introducing an H4 directly under an H2 deserves review because the relationship may be unclear.
Look for the main content landmark
Ask your developer to confirm that the page exposes a main content landmark, commonly through a <main> element. A CSS class named “main-content” does not create that semantic meaning by itself.
For a typical page, expect one exposed main landmark around its primary content. Avoid wrapping individual sections in additional main elements or nesting them.
Headings organize the content within the page. Landmarks identify broader regions such as navigation and main content. Both should reflect the actual structure.
6. Test forms when things go wrong
A form that accepts one successful submission has only passed one test. Visitors also need to understand the fields, identify errors, and recover without losing their work.
Use a test environment where appropriate. If you test a live inquiry form, coordinate with the recipient and clearly label the submission as a test.
Check labels before entering anything
- Does every field have an understandable label?
- Does that label remain visible after you start typing?
- Are required fields identified in text or with an explained symbol?
- Are format requirements explained before the visitor encounters an error?
Placeholder text disappears as someone types and should not be the only label. A visible label also needs to be associated with its field in the markup.
For developers, a basic explicit association looks like this:
<label for="contact-email">Email address (required)</label>
<input
type="email"
id="contact-email"
name="email"
autocomplete="email"
required
>The label’s for value matches the input’s unique id. This demonstrates one field-label relationship, not a complete form or validation system.
Deliberately leave something incomplete
Leave a required field empty and attempt to submit. Then test an incorrectly formatted email address.
Look for three things: the problem is identified in text, the message explains how to correct it, and information already entered remains available. A red border alone does not explain the error.
“Enter an email address in the format name@example.com” gives a visitor more direction than “Invalid input.”
For longer forms, an error summary with links to affected fields can help. Individual error messages should be programmatically associated with their fields. A developer or accessibility tester should also verify that errors and success messages are communicated appropriately to screen-reader users.
See W3C guidance on form errors and notifications (opens in a new window).
Finish the task using the keyboard
Correct the errors, reach the Submit button, and complete the test. Include conditional fields, file uploads, date pickers, and any CAPTCHA in your review.
Check whether a hidden conditional field prevents submission and whether the success message clearly confirms the result. Separately verify delivery to the intended inbox or system: a visible confirmation does not prove the inquiry arrived.
7. Record findings someone else can reproduce
You do not need to diagnose the underlying code. Describe the action and the obstacle precisely enough that someone else can repeat the test.
| General observation | More useful report |
|---|---|
| The menu is inaccessible. | On the homepage in Chrome, Tab reaches Services, but Enter does not open its submenu. Hovering with a mouse does. |
| The focus is broken. | The Get Started button receives keyboard focus, but there is no visible indicator on the dark background. |
| The skip link does not work. | Activating Skip to Content scrolls down, but pressing Tab returns to the header links. |
| The form errors are confusing. | Submitting without an email adds a red border but no text explaining which field needs attention. |
Use this template when requesting help:
Page URL:
Task I was trying to complete:
Browser and operating system:
Steps to reproduce:
1.
2.
3.
What I expected to happen:
What actually happened:
Does this prevent completion, or make the task harder?
Does it happen on other pages?
Screenshot or short recording, if available:
Recent changes to the page, theme, or plugin:
Please help identify the likely cause, the appropriate fix,
and how to verify that the fix works.Remove private information from screenshots and test entries before sharing them. If you use AI to interpret your findings, ask it to distinguish observations from assumptions. A screenshot alone cannot establish keyboard behavior or screen-reader support.
8. Prioritize the barriers and retest after changes
Start with problems that prevent important tasks: an unreachable submit button, a menu that cannot be opened, or a dialog that cannot be closed. Consider both the impact and how widely the component appears.
A shared header problem can affect every page. A confusing label on a key inquiry form can directly interfere with contacting your business.
After a repair, repeat the original steps. Then test other places that use the same component. A change to a shared button style may improve focus in one section while making it harder to see elsewhere.
Automated tools can support this review, but they cannot determine accessibility on their own. Passing these checks does not establish full WCAG conformance. A broader evaluation also needs to address areas such as text contrast, zoom and reflow, image alternatives, media, and assistive-technology behavior.
For additional introductory checks, see W3C’s Easy Checks for web accessibility (opens in a new window).
Found a barrier and need help resolving it?
You do not need a complete audit or a technical explanation before contacting me. A page URL, the task you were attempting, and a description of where you got stuck are enough to start a useful conversation.
I can help investigate the issue, make practical website improvements, and explain what needs further testing. For agencies, I can also help turn client findings into a defined remediation scope.
Send me the page and what you found, and we can work out the next step.
