Digital AuditsModule 2: Website and search reviewLesson 3 of 12
Course progress17%
20 min lesson · Updated August 2026
How do you audit website clarity, UX and accessibility?
Audit website clarity, user experience and accessibility by testing important tasks with real content across devices, input methods and user needs, supported by automated checks but never replaced by them.
What you will learn
By the end, you will understand:
Define priority user tasks and success criteria
Run manual mobile, keyboard, zoom, content and form checks
Use automated accessibility findings within their limits
Visual explainer
See the idea clearly.
123
One priority website task is tested on desktop and mobile using pointer, keyboard, zoom and screen-reader paths; obstacles are recorded at each step.
Audit journeys, not isolated screens
01
Entry point
02
Understand offer
03
Find relevant detail
04
Assess trust/terms
05
Choose action
06
Complete form/purchase
07
Receive confirmation
08
Recover from error
09
Get support
Write task tests before browsing
A task should state the user, starting point, goal, device/context and success evidence. “Review the homepage” invites taste-based commentary; “Can a first-time mobile visitor find emergency repair coverage and call without losing entered information?” is testable.
Include high-risk and high-volume tasks, not only the ideal path. Test empty, error, loading and success states.
Clarity and information architecture
Purpose understandable quickly
Language matches customer questions
Navigation labels predictable
Current location visible
Important conditions near decision
Readable headings and hierarchy
Search/filter supports real inventory
No dead ends
Contact details consistent
Confirmation explains what happens next
Manual accessibility checks
Check
Look For
Keyboard
All controls reachable/operable, logical order, visible focus, no trap.
Zoom/reflow
Content remains readable and usable at high zoom without two-dimensional scrolling except where essential.
Images/media
Meaningful alternatives, captions/transcripts where needed, decorative assets ignored.
Forms
Persistent labels, instructions, programmatic errors, recovery and status announcements.
Structure
One coherent heading outline, landmarks, lists and table relationships.
Motion
Pause/control where required and a meaningful reduced-motion state.
Contrast/state
Text/control visibility and meaning not conveyed by color alone.
Automation finds only part of accessibility
Automated tools can detect certain missing names, contrast conditions and structural issues. W3C notes that tools cannot determine accessibility on their own; human judgment and assistive-technology/user testing remain necessary.
Do not report “100% accessible” from a clean scanner. Record tool version, page state and manual coverage.
Observe, then interpret
A user hesitation is an observation; “the navigation is confusing” is an interpretation. Ask what label, expectation or prior context caused it, and whether the pattern repeats.
Avoid treating one participant as a demographic stereotype. Combine task evidence, analytics, support questions and content review.
Real-world example
Example: a keyboard-invisible booking option
Example
The booking page looks complete with a mouse, but its date cards cannot receive keyboard focus. An automated scan does not flag the custom interaction. Manual testing reproduces the block, records affected browsers and recommends a native or correctly implemented selectable control with focus and error handling.
Try this
Run a no-mouse task
Choose the most important task. Put the pointer aside and use Tab, Shift+Tab, arrow keys, Enter, Space and Escape. Record where focus goes, what is announced visually, any trap and whether completion is possible.
Common questions
Questions beginners ask.
What is a UX audit?
A structured review of how well priority users can understand and complete important tasks, using evidence rather than preference alone.
What is an accessibility audit?
An evaluation of barriers against defined accessibility criteria using automated, manual and—where possible—disabled-user testing.
Can Lighthouse prove WCAG compliance?
No. It tests only automatable conditions and cannot establish full conformance.
How many pages should be checked?
Use representative templates, priority journeys, unique components and risky states; scope depends on the site.
A component receives keyboard focus but the user cannot move away using expected keyboard actions.
Are usability and accessibility the same?
They overlap, but accessibility addresses equitable access for disabled people against specific requirements and cannot be reduced to general ease of use.
Do overlays make a site accessible?
No tool can automatically repair every content, code and design barrier; verify changes at the source and test them.
