A website can appear effortless when someone moves through it quickly with a mouse. Press Tab on the same page and a different experience may emerge. Focus disappears, a menu cannot be closed, or a form error is communicated only through red. An accessibility audit does not ask only whether the interface looks polished. It asks whether people can complete real tasks under different conditions.
You do not need to memorise hundreds of criteria to begin. A small number of well-chosen tasks can reveal where the experience breaks. W3C also makes an important distinction: quick checks are only a first review, and no automated tool can determine accessibility conformance on its own. This guide does not promise a compliance statement. It helps design, content, and development teams create a shared issue list before a more complete evaluation.
1. Choose representative pages and real tasks first
Testing only the home page is comfortable but misleading. Select the home page, a service detail, a long article, the contact form, and a page that uses a menu, modal, or expandable panel. If the site sells online, add finding a product, choosing a variant, and beginning checkout. For each page, write one sentence that describes what the visitor is trying to finish.
A recurring problem in web projects is a quality checklist organised only around components. The team approves the button, form, and menu separately but never tests the route that connects them. A representative task set closes that gap. Our digital experience design approach treats interface, content, and technical behaviour as one journey.
2. Put the mouse aside and complete the route by keyboard
Reload the page and move with Tab and Shift+Tab without touching the mouse. Activate links with Enter, controls with Enter or Space, and check whether Escape closes menus, modals, and similar layers when expected. Does focus follow a meaningful order? Can you become trapped inside a component? Is a required action skipped, or does the route stop on dozens of unnecessary elements?
Keyboard access and visible focus are separate checks. An element may technically receive focus while leaving no visual clue about your current position. Inspect the focus indicator on light backgrounds, dark sections, image cards, and error states. Removing the browser outline for aesthetic reasons can also remove the only orientation signal available to a keyboard user.
3. Zoom, narrow the view, and follow the content order
Set browser zoom to 200 percent, then reduce the width of the window. Is the text still readable, or does it disappear into horizontal scrolling? Does a fixed header cover the content? Are button labels clipped, form labels detached from their fields, or primary actions pushed outside the view? This test examines more than type size. It shows whether the layout can reflow around the person using it.
Read the content order independently from the visual layout. Price, conditions, and action may sit side by side on a desktop. What order do they take on a narrow screen? A layout can look correct in CSS while presenting a confusing source order to assistive technology. Our comparison of PDF and web page formats for restaurant menus shows how format choices connect with mobile use and accessibility.
4. Measure contrast across states, not only body copy
An automated contrast tool is a useful beginning, but do not stop after measuring normal text. Placeholder copy, input borders, error messages, chart labels, selected tabs, focus rings, and hover states also communicate information. If colour is carrying meaning on its own, capture the page in greyscale. Can you still distinguish success, error, and selected states?
A brand colour does not need to perform the same job on every surface. A coral control may work strongly as a large block while failing to separate small type from its background. The answer is not necessarily to abandon the colour. Combine text colour, background, border, icon shape, and an explicit label. Naming accessible combinations in the design system prevents the team from reopening the same debate on every page.
5. Read image alternatives, headings, and page language together
Alternative text is not a keyword field. It is a concise alternative for the purpose an image serves in its current context. A product photograph may need the detail required for a choice. A chart should communicate its conclusion. A decorative image may be better skipped with an empty alternative. When the same image performs a different role on another page, its description may need to change too.
List the page title, H1, and lower headings. Does the structure still make sense when visual size is removed? Does a skip link lead to the main content? Is the page language identified correctly? These can look like small technical details, yet they directly affect how a screen reader user understands location and moves from one section to another.
6. Complete the form with empty, invalid, and valid input
Submit the contact form while it is empty, then enter one invalid value, and finally complete it with valid information. Does every field have a visible label? Is a required field communicated through more than a star or colour? Does each error explain the problem and a way to correct it? After submission, does focus move meaningfully to an error summary or success message?
One failure we often find appears when a visually minimal form turns labels into placeholders. The question disappears as soon as the person starts typing. Another appears when an error summary is added above the form but keyboard focus remains on the submit button. In our corporate web design work these micro-behaviours belong to the architecture alongside content structure and conversion routes.
7. Check motion, media, and time pressure
Can automatically starting motion be paused? Does the interface respect a reduced-motion preference? Does a carousel, counter, or temporary notice change before someone can finish reading it? Does video include captions for speech and meaningful audio? Is a usable transcript available when an audio-only item carries important information?
The aim is not to remove all movement. Motion should support information, leave control with the person, and avoid locking meaning into one sensory channel. Leaving these decisions until the end of a redesign is expensive. Our website redesign launch plan explains why design, content, and technical checks should meet in one inventory before release.
8. Verify the automated report through a human task
Browser extensions can quickly find missing alternatives, some contrast failures, and certain code errors. What they cannot judge matters just as much. They cannot reliably decide whether an alternative is useful, whether the focus order fits the task, or whether an error message makes sense. Use automation for discovery, not as a final verdict.
After the first team review, include people with expertise in keyboard and screen-reader use and, when possible, disabled users. W3C's WCAG-EM approach also separates defining scope, exploring the product, selecting a representative sample, evaluating that sample, and reporting findings. A score from one home page should not be presented as the result for an entire website.
Prioritise with a 0-1-2 task card
Give each of the eight tasks 0, 1, or 2 points: representative route, keyboard operation, visible focus, zoom and reflow, contrast and colour, images and content structure, forms and errors, motion and media. Zero means the task cannot be completed, one means it can be completed with clear friction, and two means it works consistently in the selected sample. The highest score is 16. This is not a WCAG conformance score. It is a triage tool that gives the team a shared language for first priorities.
Stop the release regardless of the total if there is a keyboard trap, an essential form cannot be submitted, primary information is unreadable, or critical motion cannot be controlled. Sort the remaining issues into prevents completion, makes completion harder, and reduces consistency. This keeps the team focused on the barrier with the greatest effect on the user route rather than the easiest visible fix.
Move accessibility from final inspection into design decisions
A strong first review does not prove that every standard has been met. It shows where deeper expertise, user research, or code inspection is needed. The largest gain is not a one-time score. It is designing every new component with keyboard, focus, zoom, error, and motion states from the start.
Fark Studio can map the representative tasks on your current site and separate accessibility findings into design, content, and development responsibilities. Send us your three most-used user routes and the form you suspect is causing problems, and we can build the first audit sample together.
