Does passing an automated audit mean a website is accessible?
Choose a complete task such as booking a service. Test success, a form error and returning from a dialog; one correct attribute does not establish that the task can be completed.
Start with three visitor tasks. Find a service through headings, understand a photograph through alternative text and open the contact page using a keyboard. For a JavaScript-controlled menu, check where focus moves after opening and closing it.
What to do step by step
- Complete an important journey using only the keyboard.
- Check clear names for fields, buttons and links.
- Trigger a validation error and review its connection to the field.
- Test text enlargement, reflow and readability.
- Add assistive-technology and manual evaluation.
A practical example
<label for="email">Email for the reply</label>
<input id="email" name="email" type="email" autocomplete="email" />A common mistake
A placeholder does not reliably replace a visible label. Incorrect ARIA can make semantics worse instead of fixing them.
Try the report before checking your site.
Explore the sample report, then enter your own URL to see findings, HTML evidence and a repair plan for your page.
Run your audit
How to test a website using only the keyboard
Start on an entry page and submit a form without a mouse. A list of correct attributes can miss an unreachable button or focus hidden behind a banner.
- Use Tab and Shift+Tab while checking that focus remains visible.
- Activate links and buttons using their standard keyboard controls.
- Include navigation and consent banners that might block the page.
How to check form labels and validation errors
A field’s label should remain available after typing. An error must explain the problem and help with the correction; a red border alone is insufficient.
- Give each field a clear name, preferably through a visible label.
- Associate the error message with the relevant field.
- Keep correctly entered values when the form is rejected.
Source W3C WAI — form validation ↗
How to test focus in a modal dialog
A modal changes the interaction context. The user needs to recognise its purpose, reach its controls and continue from a sensible location when it closes.
- On opening, move focus to an appropriate element inside the dialog.
- Keep keyboard navigation within a modal dialog and provide Escape to close it.
- Normally return focus to the opening control after the dialog closes.
How to check enlarged text and the complete user journey
Supplement automated checks with text enlargement and assistive-technology testing. An accessible entry page does not establish that checkout or an error screen is accessible too.
- Check readability without overlapping text or controls.
- Review headings, image alternatives and meaningful link names.
- Define the page scope and tested WCAG requirements before claiming conformance.
How to verify the result
Use Fukamo findings as technical inputs. Assess relevant WCAG requirements across interactions, context and page types before making a conformance claim.
Primary documentation www.w3.org ↗
Frequently asked questions
Does passing an automated audit mean a website is accessible?
No. Automated rules catch some issues but cannot fully evaluate alternative-text meaning or an entire user journey. Complete a form by keyboard, try invalid input, and check visible focus. Modal interaction and returning focus to the trigger require testing actual behavior.
When the task is complete
An important task can be completed without a mouse, fields have meaningful names, and errors are announced. Do not present a limited automated check as whole-site conformance certification.
Related SEO guides
Check a specific page.
Fukamo shows findings, evidence and the next step.
679 rules + SEO, AI readability, performance and accessibility measurements for free.