How to Audit and Improve Website Accessibility: A Practical WCAG 2.2 Workflow

Quick answer: A useful website accessibility audit does not begin with an automated score. It begins by identifying the pages and user journeys that matter most, testing whether they can be understood and operated without relying on sight, a mouse, color alone, perfect hearing, or unusually precise movement, and then mapping real barriers to the relevant accessibility requirements. For most general-purpose websites, WCAG 2.2 Level AA is a practical technical target, but accessibility is broader than any checklist and legal requirements vary by country and sector.

Accessibility is a product-quality concern, not a one-time compliance badge. Image: Wikimedia Commons, CC BY-SA.

A website can look polished, load quickly, and still block people from completing basic tasks. A visitor may be unable to see low-contrast text, may not be able to operate a menu with a keyboard, may hear a video but miss information conveyed only visually, may see a form error but receive no programmatic explanation, or may find that a sticky header covers the keyboard focus indicator. These are not theoretical edge cases. They are usability failures that can affect people with permanent, temporary, situational, or age-related disabilities, and they often frustrate everyone else as well.

This guide explains how to perform a practical accessibility review of a small or medium website without pretending that one tool or one afternoon can certify full conformance. The goal is to create a repeatable process: choose scope, establish a baseline, inspect the highest-impact barriers, fix them in a sensible order, retest with assistive technologies and real users when possible, and build accessibility into normal publishing and development work.

1. Understand what you are actually testing

Before opening a testing tool, define accessibility in operational terms. The World Wide Web Consortium’s Web Accessibility Initiative organizes WCAG 2.2 around four principles: content should be perceivable, operable, understandable, and robust. Those words are more useful than they first appear because they turn a vague goal into questions you can test.

Perceivable means users need a way to receive the information. If an important chart is only an image with no useful text alternative, a person who cannot see the chart may miss the conclusion. If a video contains essential speech but no captions, a deaf or hard-of-hearing user may miss the message. If instructions say “click the green button,” color becomes part of the meaning.

Operable means users need a way to control the interface. A menu that opens only when a pointer hovers over it may be unusable with a keyboard. A tiny close button may be difficult for someone with limited dexterity. A modal that traps focus incorrectly can make the rest of the page unreachable.

Understandable means the content and interface should behave predictably and explain what users need to do. Forms need labels and useful error feedback. Navigation should not change unexpectedly. Authentication should not create unnecessary cognitive barriers.

Robust means the underlying structure should communicate roles, names, values, relationships, and states in ways browsers and assistive technologies can interpret. A visually convincing custom control is not necessarily an accessible control. Native HTML often gives you semantics, keyboard behavior, and platform compatibility that would otherwise have to be recreated.

WCAG 2.2 contains testable success criteria at Levels A, AA, and AAA. W3C encourages use of the latest WCAG version. For many organizations, Level AA is the most practical working target because it includes the foundational Level A criteria plus additional requirements that address common barriers such as contrast, focus, target size, and accessible authentication. Do not, however, write “WCAG compliant” because an automated checker showed a high score. Conformance is a claim about all applicable success criteria in a defined scope, and W3C explicitly notes that automated tools alone cannot determine whether a site is accessible.

Turn standards into user tasks

A good audit combines standards with realistic tasks. Instead of testing only “the homepage,” test journeys such as:

Find a product or article from the main navigation.
Search the site and refine results.
Complete a contact, registration, checkout, or newsletter form.
Open and close a menu, dialog, accordion, or cookie preference panel.
Watch a video and understand the important information.
Recover from a validation error.
Zoom the page and continue using it.
Navigate to the same destination using only a keyboard.

This approach prevents a common failure: spending hours fixing decorative issues on low-traffic pages while a keyboard user still cannot submit the main form.

2. Define the scope before you count defects

Large websites can contain thousands of URLs, repeated templates, third-party widgets, archived pages, and multiple applications. Testing every page manually is unrealistic for a first pass. Instead, choose a representative sample that covers templates and critical workflows.

Start with the homepage, one article or content page, one category or listing page, one search page, the primary contact or signup form, any login flow, and the most important conversion flow. Add pages with unusual components such as tables, maps, embedded media, sliders, calendars, or complex filters. If the site uses multiple themes, page builders, or legacy templates, include examples of each.

Next, list components that appear everywhere: header, navigation, mobile menu, footer, cookie controls, search, forms, buttons, cards, breadcrumbs, pagination, alerts, and modal dialogs. A single accessible fix to a shared component can remove hundreds of repeated defects, which is why template-level issues should usually outrank isolated cosmetic problems.

Create a simple audit worksheet

Your worksheet does not need to be complicated. Give each issue these fields:

Page or component: where the problem occurs.
User impact: what task becomes harder or impossible.
Evidence: what you observed and how to reproduce it.
WCAG reference: the relevant success criterion when known.
Severity: blocker, serious, moderate, or minor.
Reach: one page, one template, or site-wide.
Owner: content, design, development, vendor, or product.
Status: open, in progress, fixed, retest needed, or accepted risk.

A useful issue description is behavioral. “Contrast fails” is weaker than “The gray placeholder-style label for the email field is difficult to read against the white background and measures below the required contrast for normal text.” “Menu inaccessible” is weaker than “Pressing Tab skips all submenu links; the submenu opens only on pointer hover, so keyboard-only users cannot reach Services → Consulting.”

The expected result should also be explicit. That turns an audit into a development task rather than a vague criticism.

3. Start with a keyboard-only walkthrough

Keyboard testing is one of the highest-value manual checks because it exposes navigation, focus, widget, modal, and interaction problems quickly. Put the mouse aside. Reload the page and use common keyboard controls such as Tab, Shift+Tab, Enter, Space, Escape, and arrow keys where appropriate.

Keyboard access is essential for people who cannot reliably use a pointing device. Image by Francisclarke, Wikimedia Commons, CC BY-SA 4.0.

Begin at the browser address bar or the top of the document and press Tab repeatedly. You should be able to tell which interactive element has focus at every step. Focus should move in an order that makes sense. Links, buttons, form controls, menus, and other interactive components should be reachable. If a control can be clicked but never receives keyboard focus, record it.

Watch for invisible or obscured focus

A focus indicator is not decorative. It tells a keyboard user where the next action will occur. Common mistakes include removing outlines globally with CSS, using a barely visible focus color, showing focus only on some controls, or allowing sticky banners to cover the focused element.

WCAG 2.2 added specific criteria around focus not being obscured. In practical terms, when focus moves to a control, the user should not have to guess where it went because a fixed header, cookie bar, chat widget, or modal layer is covering it. Test pages with sticky navigation and floating controls carefully.

Test interactive components as complete behaviors

Do not stop after confirming that a menu receives focus. Try to open it, move through it, select an option, close it, and continue. For a modal dialog, trigger it with the keyboard, verify that focus moves into it sensibly, interact with its controls, close it, and confirm focus returns to a logical place. For an accordion, test expansion and collapse. For a carousel, test controls without relying on drag gestures.

A common mistake is to add tabindex="0" to a non-semantic element and call the job done. That may make the object focusable, but it does not automatically provide the behavior, role, name, state, or keyboard interaction users expect. When a native <button>, <a>, <input>, <select>, or <details> element fits the job, prefer it over rebuilding the control from generic containers.

Run the reverse test

Use Shift+Tab to move backward. Some interfaces behave correctly in one direction but fail in reverse, especially around dialogs and custom widgets. Also test Escape where dismissal is expected. A close icon that can be clicked but not focused, or a dialog that cannot be dismissed without a pointer, is a real barrier.

4. Inspect headings, landmarks, and page structure

Visual design creates structure through size, spacing, columns, color, and placement. Assistive technology needs programmatic structure. That makes semantic HTML a major accessibility tool.

Read the page as an outline. The page title should be clear. Headings should describe sections and follow a logical hierarchy based on the document structure, not be chosen simply because an H3 happens to look smaller than an H2. Skipping a level is not automatically catastrophic, but using headings as visual styling rather than semantic structure creates a confusing outline.

Inspect landmarks such as header, navigation, main content, complementary content, and footer. Native elements including <nav>, <main>, <header>, and <footer> can help users of assistive technology navigate by region. If multiple navigation landmarks exist, labels can help distinguish them.

Check the page without its styling

One revealing test is to consider the reading order without the visual layout. If CSS were removed, would the DOM order still make sense? A two-column layout can look correct visually while placing a sidebar or secondary action in an awkward position in the source order. CSS grid and flexbox can visually rearrange elements, but screen readers and keyboard focus generally follow DOM order.

Verify that instructions and supporting text appear near the element they explain. Do not rely on visual proximity alone if the underlying relationship matters. Lists should be marked up as lists. Data tables should use table structure and headers rather than a series of styled divs pretending to be rows and columns.

5. Review every meaningful image and icon

W3C’s updated Images Tutorial emphasizes a simple rule: images need text alternatives appropriate to their purpose. The correct alt text depends on context, not on what a computer vision system can describe.

For an informative image, write a concise alternative that conveys the information the image contributes. If the image shows a damaged cable in an article about troubleshooting, “Frayed power cable with exposed insulation near the connector” is more useful than “image123.jpg” or “picture.”

For a purely decorative image, use an empty alternative such as alt="" so a screen reader can ignore it. Do not fill decorative images with keyword-heavy descriptions for SEO. Accessibility and search usefulness both improve when alternatives reflect genuine purpose.

For a functional image used as a button or link, describe the action rather than the appearance. A magnifying-glass image that submits search should have an accessible name equivalent to “Search,” not “magnifying glass.”

Do not duplicate adjacent text unnecessarily

If a card contains an image, a heading link reading “Summer Garden Checklist,” and the image links to the same destination, repeating “Summer Garden Checklist” as the image alt may cause screen reader users to hear the same information twice. Depending on the markup and purpose, an empty alt on the linked image may be more appropriate if the adjacent text already provides the accessible name.

Treat charts as information, not decoration

A chart often needs more than a short alt attribute. Give the image a concise alternative, then provide the important conclusion and underlying values in nearby text or an accessible table when practical. The goal is not to narrate every pixel. The goal is to make the information and takeaway available.

6. Test color contrast and information that depends on color

Color problems are common because designs are often created on bright calibrated monitors under ideal conditions. Real users may have low vision, color-vision differences, screen glare, dim displays, old devices, or simply be reading outdoors.

Contrast ratios can be measured, but usable color decisions also require context. Diagram by Cmglee, Wikimedia Commons, CC BY-SA 4.0.

For WCAG Level AA, normal text generally needs a contrast ratio of at least 4.5:1 against its background, while qualifying large text has a lower threshold of 3:1. Non-text user-interface components and graphical objects also have relevant contrast requirements. Use a reliable contrast checker on actual foreground and background colors rather than estimating by eye.

Pay particular attention to light gray text, placeholder-like labels, secondary buttons, disabled-looking controls that are actually active, text placed over photographs, badges, chart labels, breadcrumb links, footer text, and focus indicators. Hover and focus states can fail even when the default state passes.

Do not use color as the only signal

If required fields are marked only in red, error states are shown only with a red border, or a chart distinguishes categories only by hue, some users may not receive the intended information. Add text, icons with accessible names, patterns, labels, or other cues.

An example: instead of turning an invalid field border red and doing nothing else, display a message such as “Enter an email address in the format name,” associate that message with the field, and ensure the error summary or focus behavior helps the user find the problem.

7. Audit links and buttons for understandable purpose

Links should tell users where they lead, especially when read out of surrounding context. A page full of “Click here” and “Read more” links can be difficult for screen reader users who navigate by a list of links. Descriptive anchor text also improves scanning for sighted users.

Prefer “Download the 2026 accessibility checklist” over “Click here.” Prefer “Compare hosting plans” over “Learn more” when the destination is specifically a plan comparison. This does not mean every link must be long. It means the purpose should be reasonably clear.

Buttons perform actions; links navigate. Styling a link to look like a button is fine when it still navigates. Using an anchor with no meaningful href to perform an application action can create keyboard and semantic problems. Choose elements based on behavior first, appearance second.

Check icon-only controls

Icons such as a hamburger menu, search symbol, trash can, heart, share arrow, or close “X” need accessible names when they act as controls. The visual icon may be obvious to some users, but assistive technology needs a programmatic label such as “Open menu,” “Search,” “Remove item,” or “Close dialog.”

Also check whether the accessible name matches visible text when visible text exists. Speech-input users may try to activate a control by saying what they see. If the visible button says “Save changes” while its accessibility name is “Submit form,” the mismatch can cause unnecessary friction.

8. Fix forms from the label outward

Forms deserve special attention because they often sit directly on important user journeys: account creation, checkout, contact, subscription, booking, support, and login. W3C’s Forms Tutorial, updated in March 2026, recommends identifying controls with labels, grouping related controls, providing instructions, validating input, and giving useful feedback.

Every field should have a meaningful label. In standard HTML, the most reliable pattern is usually a visible <label> whose for attribute matches the control’s id. Visible labels help many users, including people with cognitive disabilities, speech-input users, mobile users, and users with limited dexterity.

Do not use placeholder text as the only label

Placeholder text disappears when users begin typing and may have weak contrast. It also does not provide the persistent orientation that a real label provides. Use placeholders for optional examples when they genuinely help, not as a replacement for labels.

Group related choices

Radio buttons and checkboxes that belong to one question should be grouped meaningfully. Native <fieldset> and <legend> elements are often appropriate. A user navigating choices such as shipping method, notification preference, or account type should hear the group question as well as each option.

Make instructions available before errors happen

If a password requires a minimum length, a date needs a specific format, or a file upload has size and type limits, explain those constraints before submission. W3C advises providing relevant form instructions and ensuring they can be conveyed to screen readers.

For required fields, do not rely only on an asterisk without explanation. Indicate “required” in text or provide an accessible equivalent. If a session has a time limit, explain it and provide accessible mechanisms to extend the time when required.

Write errors that help users recover

“Invalid input” is not enough. State what is wrong and, when possible, how to fix it. Associate field-specific messages with their controls. If submission fails, provide an error summary near the top and move focus or otherwise notify assistive technology appropriately, while preserving the user’s entered data whenever possible.

Test errors deliberately: submit an empty required form, enter malformed data, exceed limits, choose incompatible options, and trigger server-side errors. An accessible happy path is not enough if the recovery path is broken.

9. Test zoom, reflow, responsive layout, and text spacing

Accessibility is not limited to screen readers. Many people with low vision enlarge content significantly. Test browser zoom, not just operating-system magnification. At common high zoom levels, content should remain usable without forcing users into impractical two-dimensional scrolling for ordinary text content, subject to the applicable WCAG criteria and exceptions.

Watch for navigation that disappears, buttons clipped offscreen, cookie banners that cover the viewport, horizontal scrolling caused by fixed-width containers, text that overlaps, labels that detach from fields, and dialogs that cannot be scrolled.

Also test increased text spacing. Some users apply custom styles to improve readability. Layouts built with rigid heights may clip text when line-height, letter spacing, word spacing, or paragraph spacing increases. Flexible containers generally survive this better than fixed-height boxes.

Check orientation assumptions

Mobile layouts should not unnecessarily require one device orientation unless the content truly depends on it. Test portrait and landscape. A form that is usable only in landscape because the submit button disappears in portrait is a design defect, not a user problem.

10. Review target size and pointer interactions

WCAG 2.2 added a Level AA minimum target-size criterion. The exact success criterion includes exceptions, so avoid converting it into a simplistic “every button must be X pixels” slogan. The practical design lesson is straightforward: controls should be large enough and spaced well enough that users do not need extraordinary pointer precision.

Small icon controls are especially risky on mobile: carousel dots, tiny “X” buttons, pagination numbers, map markers, disclosure arrows, and inline edit icons. If a control is visually small, increasing its interactive hit area can improve usability without changing the visual design dramatically.

Provide alternatives to dragging

WCAG 2.2 also addresses dragging movements. If the interface requires dragging an item, provide a way to achieve the same result without a dragging gesture unless an exception applies. A sortable list, for example, might offer “Move up” and “Move down” buttons. A slider may need keyboard controls. A map with drag-and-drop placement may need another mechanism for entering or choosing the same value.

Test with a trackpad, touch screen, keyboard, and—where practical—alternative input methods. The easiest way to discover precision problems is to stop assuming everyone uses a desktop mouse.

11. Evaluate animation, motion, and time-based behavior

Automatic movement can distract, disorient, or make content difficult to operate. Carousels that advance while someone is reading, video backgrounds, flashing content, auto-updating tickers, and animated transitions should be reviewed carefully.

Give users control over movement when required and respect reduced-motion preferences where appropriate. Avoid content that flashes in ways that could trigger seizures. For time limits, identify whether users can turn off, adjust, or extend the limit when the relevant WCAG requirements apply.

Do not make essential content disappear so quickly that users who read more slowly cannot act. Toast notifications and temporary status messages need enough persistence or an alternative way to recover their information.

12. Make audio and video understandable without a single sensory channel

Media accessibility depends on what the content contains and whether it is prerecorded or live. For prerecorded video with speech, accurate captions are usually essential. Captions should represent meaningful spoken content and important non-speech audio, not merely approximate the words with unreviewed automated transcription.

Audio-only content may require a transcript. Video that communicates important visual information not conveyed by its audio track may require an audio description or another alternative depending on the applicable criterion and context.

Test the media player’s controls with a keyboard. Can users play, pause, change volume, enable captions, and enter or exit full screen without a mouse? Does focus remain visible? Are buttons named meaningfully? Does autoplay create sound unexpectedly?

Treat transcripts as content, not leftovers

A transcript can be useful for people who are deaf or hard of hearing, people in noisy environments, people who prefer reading, users searching for a specific passage, and search engines. Structure it with speaker names where needed and include important information, rather than dumping an unedited speech-to-text block beneath the video.

13. Perform a basic screen-reader check

A complete screen-reader audit requires skill and familiarity with the chosen screen reader and browser combination, but a basic check can still reveal major structural failures. Use a mainstream screen reader on a supported platform and learn its core navigation commands before interpreting results. Do not assume that one unexpected announcement automatically means the website is wrong; screen readers have modes, commands, browser interactions, and user settings.

Begin with page title and landmarks. Navigate by headings. Review the list of links. Move through form controls. Test the main interactive components. Listen for names, roles, states, required status, errors, and updates.

Ask simple questions:

Can I tell what page I am on?
Can I understand the heading structure?
Can I find the main navigation and main content quickly?
Do image alternatives make sense in context?
Do controls announce what they do?
Do expanded, selected, checked, invalid, or disabled states make sense?
When content changes dynamically, am I informed when necessary?
Can I complete the critical task without looking at the screen?

The purpose is not to “test blindfolded” as a stunt. It is to identify whether the semantic and interaction layer gives assistive technology enough information.

14. Use ARIA carefully and only when it solves a real semantic gap

ARIA can add semantics and states to web applications, but it is not a substitute for correct HTML. Overusing ARIA often creates controls that announce one thing and behave like another.

Before adding a role, ask whether a native HTML element already provides the behavior. A native button has keyboard activation, focus behavior, and an established accessibility role. A generic <div role="button"> needs additional keyboard handling, focus management, and state logic to behave equivalently.

When ARIA is appropriate, keep its states synchronized with the real interface. An accordion whose aria-expanded remains “false” after opening creates conflicting information. A custom checkbox whose visible check mark changes without its accessibility state changing is broken even if it looks correct.

Inspect accessible names

Use browser developer tools to examine the accessibility tree when available. Check the computed accessible name and role of custom controls. A visually labeled icon button may accidentally have no accessible name, or several naming mechanisms may combine into an awkward repeated announcement.

Do not hide focusable content from assistive technology with aria-hidden="true". Do not add roles that contradict native semantics unless you understand the consequences. Complexity should earn its place.

15. Run automated tools, but treat them as scanners rather than judges

Automated accessibility tools are valuable because they find certain classes of defects quickly and consistently. They can flag some contrast failures, missing alternatives, duplicate IDs, form-label issues, semantic misuse, and other machine-testable patterns.

But W3C is explicit: no tool alone can determine whether a site meets accessibility standards. Automation cannot reliably decide whether an alt description is meaningful in context, whether heading wording helps users, whether keyboard focus order is logical, whether a transcript communicates the important meaning, or whether a complex interaction is cognitively understandable.

A practical workflow is:

Run one or more automated checks on representative pages.
Remove duplicate noise and group recurring template defects.
Confirm findings manually before assigning them.
Perform keyboard, zoom, and content checks that automation cannot replace.
Use a screen reader for critical flows.
Retest after fixes.
Add automated checks to development or publishing workflows where they provide reliable signal.

Do not optimize for a score at the expense of users. A page can score 100 in a limited automated audit and still have a confusing focus order or misleading alt text.

16. Prioritize fixes by barrier severity and reach

A list of 200 defects is not a plan. Prioritize by how badly the issue blocks a user, how many users and pages it affects, and how central the affected task is.

A simple priority model:

Priority 1 — blockers: users cannot complete a critical task. Examples include an inaccessible checkout control, keyboard trap, unlabeled authentication input, or form that provides no usable error recovery.
Priority 2 — serious barriers: the task is possible but significantly difficult, confusing, or inefficient. Examples include weak focus visibility, major contrast failures, missing captions on essential instructional video, or inconsistent navigation semantics.
Priority 3 — moderate issues: the defect creates friction but does not usually prevent task completion.
Priority 4 — polish: lower-impact improvements that still contribute to a more inclusive experience.

Then multiply the impact mentally by reach. Fixing one broken navigation component used on 2,000 pages often deserves more attention than repairing five isolated image alternatives on archived posts.

Fix systems, not symptoms

If authors routinely publish images without alt decisions, do not merely repair 300 posts. Update the content workflow or CMS prompts, train authors, and add review checks. If designers repeatedly use low-contrast tertiary text, fix the design token. If developers repeatedly build custom buttons incorrectly, improve the component library.

This is where accessibility becomes sustainable. W3C’s planning guidance recommends integrating accessibility into normal processes, assigning responsibility, reviewing websites, monitoring progress, training staff, and evaluating early rather than treating accessibility as a separate project at the end.

17. Build an accessibility definition of done

Every team needs a short, realistic quality gate. The exact checklist depends on the product, but a content or feature should not be considered complete merely because it looks correct in one browser.

For a typical content page, your definition of done might require:

Meaningful page title and heading structure.
Appropriate alt decisions for every image.
Descriptive links and properly marked lists and tables.
Readable contrast.
Keyboard reachability and visible focus for interactive elements.
No information conveyed by color alone.
Responsive behavior at zoom and on mobile.
Captions or alternatives for relevant media.
Automated scan with findings reviewed rather than blindly accepted.

For a form or application feature, add labels, instructions, errors, status messages, accessible names and states, target size, drag alternatives, focus management, and screen-reader checks.

18. Add accessibility to design before code exists

The cheapest accessibility defect is the one that never enters the design system. Designers can prevent many problems by specifying focus states, hover states, error states, disabled states, minimum target sizes, contrast-safe color pairs, responsive behavior, content hierarchy, and keyboard interaction before development.

Design annotations should not say merely “dropdown.” They should describe when it opens, how it closes, what receives focus, how options are selected, what happens on Escape, and what state is communicated. For dialogs, clarify the initial focus target and return focus. For tooltips, decide whether the content is essential and how it appears for keyboard and touch users.

Component libraries are powerful because accessible patterns can be reused. They are also dangerous because one broken pattern can spread everywhere. Test the shared components with the same seriousness as production pages.

19. Improve the content itself, not only the code

Accessible code cannot rescue unclear writing. Long paragraphs, unexplained jargon, vague headings, inconsistent terminology, and instructions that rely on spatial language can create cognitive barriers.

Use descriptive headings that help readers predict the section. Put the important instruction near the relevant action. Break complex processes into manageable steps. Explain abbreviations on first use when appropriate. Keep button labels consistent. Avoid unnecessary double negatives and ambiguous error messages.

For instructions, “Select Billing, then choose Download invoice” is usually clearer than “Use the option on the right.” Responsive layouts can move “the option on the right” somewhere else, and screen-reader users may not experience the page spatially in the same way.

20. Test authentication and account recovery carefully

WCAG 2.2 added criteria related to accessible authentication. Authentication flows can create cognitive barriers when they require users to remember, transcribe, or solve information in ways that lack an accessible alternative.

Review login, multi-factor authentication, password reset, verification, and account recovery as complete journeys. Test password-manager compatibility and paste behavior where relevant. Do not block paste into password fields merely because someone believes it is more secure. Avoid CAPTCHAs or puzzles that create unnecessary sensory or cognitive barriers without accessible alternatives.

When security constraints are genuine, accessibility and security should be designed together rather than treated as opposing goals. A user who cannot pass authentication has effectively been denied the entire service.

21. Include third-party widgets in the audit

A site’s accessibility is experienced as one product even when parts of it come from external vendors. Cookie consent tools, chat widgets, payment forms, scheduling systems, maps, video players, advertising units, review widgets, and embedded forms can all introduce barriers.

Document which third parties control which components. Test them in the same user journeys as your own code. If a vendor component creates a blocker, contact the vendor with reproducible evidence and ask about its accessibility roadmap. Where practical, choose suppliers with credible accessibility documentation and contract language.

Do not assume that “we did not build it” means users will experience it as someone else’s problem.

22. Retest fixes in context

Accessibility fixes can create regressions. Increasing contrast may solve one criterion but make a disabled state indistinguishable from an enabled one. Changing DOM order may affect focus. Adding ARIA may alter announcements. A new focus trap may prevent users from leaving a modal.

Retest the original steps exactly. Then test neighboring behavior. If you changed the menu, test it at desktop and mobile widths, by keyboard and pointer, forward and backward, open and closed. If you changed form errors, test valid submission, invalid submission, multiple errors, server errors, and re-submission.

Record evidence of the fix. Screenshots help for visual issues, but keyboard and screen-reader bugs may need short recordings or written reproduction steps. Keep the audit record because it becomes useful regression knowledge.

23. Involve people with disabilities instead of treating standards as a substitute for users

Standards are essential because they provide testable requirements and a shared vocabulary. They do not replace human experience. W3C recommends involving people with disabilities in evaluation when possible.

User testing can reveal problems a checklist misses: confusing wording, exhausting task sequences, misleading announcements, difficult gesture combinations, poor magnification behavior, or workflows that are technically possible but unnecessarily burdensome.

Recruit participants ethically. Pay people for their expertise. Do not ask one participant to represent every disability. Different people use different assistive technologies, strategies, settings, and devices. Treat findings as product research, not as a performance where the participant must “prove” a defect.

24. Create a 90-minute first-pass audit for small websites

If you have never reviewed a site before, use this compact sequence to find the highest-value problems without pretending it is a full conformance evaluation.

Minutes 0–10: choose the journey

Select the homepage plus one critical task such as submitting the contact form, signing up, searching, or completing checkout. Note the templates and third-party components involved.

Minutes 10–25: keyboard test

Put away the mouse. Tab through the page and the task. Record unreachable controls, missing focus, strange order, traps, inaccessible menus, and dialogs that do not manage focus correctly.

Minutes 25–35: structure and content

Review title, headings, landmarks, link text, image alternatives, lists, tables, and reading order. Check whether instructions rely on visual position or color.

Minutes 35–50: form test

Inspect labels and instructions. Submit the form with missing and invalid values. Verify that errors are clear, associated with fields, and recoverable.

Minutes 50–65: contrast, zoom, and mobile

Check high-risk colors with a contrast tool. Zoom the page. Test narrow viewport behavior. Look for clipping, overlays, tiny controls, and horizontal scrolling.

Minutes 65–75: automation

Run an automated scan and confirm the results manually. Add only validated issues to your worksheet.

Minutes 75–90: prioritize

Group findings by shared component, assign severity and owners, and choose the first three fixes. A first pass succeeds when it produces an actionable backlog, not when it generates the largest number of warnings.

25. A worked example: auditing a newsletter signup flow

Imagine a small business homepage with a newsletter signup card. Visually it contains a heading, email field, green Subscribe button, and a note saying subscribers can unsubscribe anytime.

Start with keyboard access. The heading is not interactive, so focus should move naturally to the email field and then the Subscribe button. If focus skips the field because a styled div was used instead of an input, the flow is broken. If the button receives focus but the outline is removed, the user has no visible indicator.

Inspect the field. If the only label is placeholder text saying “Your email,” add a persistent label such as “Email address.” Make sure the label is programmatically associated. If the field is required, communicate that accessibly.

Test invalid submission. Enter “abc” and submit. If only the border turns red, add a useful message such as “Enter an email address in the format [email protected].” Ensure users can discover the error without having to visually scan the entire page.

Measure text and button contrast. Check the button in default, hover, active, and focus states. If green is the only visual cue showing successful subscription, add a text confirmation such as “Subscription confirmed. Check your inbox.” If that confirmation appears dynamically, verify that assistive technology is notified appropriately.

Zoom the page and test it on a narrow viewport. The label, field, and button should remain readable and operable. If the cookie banner covers the button, you now have an interaction between two otherwise separate components that automated checks might not explain.

Finally, use a screen reader. Confirm the heading, field label, required state, button name, error message, and success confirmation. That single small flow demonstrates why accessibility is a system: content, CSS, semantics, keyboard behavior, validation, dynamic updates, and third-party overlays can all affect the final experience.

26. Common accessibility mistakes and what to do instead

Mistake: chasing a perfect automated score

Better approach: use tools to identify machine-detectable problems, then perform manual checks and user-centered testing. A score is a signal, not a conformance certificate.

Mistake: adding ARIA everywhere

Better approach: start with native semantic HTML. Add ARIA only when you understand the semantic gap you need to fill and can maintain correct states and keyboard behavior.

Mistake: writing alt text for every visible detail

Better approach: describe the image’s purpose in context. Use empty alternatives for purely decorative images. Give complex graphics nearby explanations when a short alt cannot carry the information.

Mistake: removing focus outlines because they look ugly

Better approach: design a visible focus style that belongs to the visual system. Accessibility and aesthetics are not mutually exclusive.

Mistake: fixing only the desktop layout

Better approach: test zoom, narrow screens, portrait and landscape, touch targets, reflow, and overlays.

Mistake: assuming captions generated automatically are finished

Better approach: review captions for accuracy, punctuation, speaker changes, timing, and important non-speech audio.

Mistake: treating accessibility as the developer’s job

Better approach: assign responsibilities across design, content, development, QA, procurement, and product management. Many accessibility defects originate before code is written.

Mistake: declaring legal compliance from a generic checklist

Better approach: separate technical accessibility work from legal advice. WCAG is an international technical standard used in many policies and laws, but legal obligations vary by jurisdiction, organization type, contract, and sector. Consult qualified local counsel when you need a legal conclusion.

27. Build a monthly accessibility maintenance routine

Accessibility drifts when websites change. New campaigns introduce image text. New plugins add dialogs. A redesign changes color tokens. A vendor updates a widget. Editors paste headings incorrectly. A form gains a new field without a label.

A lightweight monthly routine can prevent gradual decay:

Scan a representative set of key pages.
Keyboard-test one critical journey.
Review recently published content for headings, links, images, and media.
Check new or changed components at zoom and mobile widths.
Review open accessibility issues by severity and age.
Retest a sample of recently closed issues.
Review feedback from users and support channels for possible accessibility patterns.

Quarterly or before major releases, expand the review to more templates, assistive technologies, and user testing. When the organization changes design systems, CMS platforms, authentication, checkout, or navigation, treat accessibility as part of the migration plan.

28. Create an accessibility statement that reflects reality

An accessibility statement can explain the organization’s commitment, the standard or target being pursued, known limitations, contact options, and how users can request help or report barriers. It should not make claims the organization cannot support.

Provide an accessible contact route. If the only way to report an inaccessible form is through that same inaccessible form, the feedback mechanism has failed. Offer an alternative such as a clearly published email address or other channel appropriate to the organization.

Use feedback as structured quality data. Record the affected page, task, assistive technology if volunteered, severity, reproduction information, and resolution. Never require users to disclose medical information to report a technical barrier.

29. What success should look like after the audit

The best outcome is not “zero issues forever.” Websites evolve. A more realistic outcome is a system in which severe barriers are found quickly, shared components are designed accessibly, editors understand the basics, tests run during normal delivery, users have a way to report problems, and the backlog becomes smaller and less severe over time.

Measure progress with several signals rather than a single score:

Number of critical blockers open and their age.
Percentage of high-value journeys keyboard-tested before release.
Coverage of shared components in accessibility QA.
Caption and transcript coverage for media that requires them.
Rate of recurring defects such as missing labels or low-contrast tokens.
Time to resolve accessibility feedback.
Results from periodic manual audits and user testing.

If the same defect keeps returning, the process has not really been fixed. Move upstream: template, component, authoring tool, design token, training, or procurement requirement.

Frequently asked questions

Can an automated accessibility checker tell me whether my site is WCAG 2.2 compliant?

No. Automated tools can detect many useful issues, but W3C states that tools alone cannot determine whether a site meets accessibility standards. Human evaluation is required, and some criteria depend on context, meaning, interaction, and judgment.

Should a small website target WCAG 2.2 Level AA?

WCAG 2.2 is the latest WCAG 2 version, and W3C encourages using the latest version. Level AA is a common practical target for many websites because it includes Level A plus additional important criteria. However, your contractual or legal requirement may specify a different standard or version, so verify obligations separately.

Do all images need descriptive alt text?

All images need an appropriate text-alternative decision, but that does not mean every image needs a description. Informative images generally need useful alternatives. Decorative images commonly use an empty alt="". Functional images need alternatives that describe the action or function.

Is a screen reader required for every basic audit?

A basic screen-reader check is highly valuable, especially for critical flows, but it should be performed by someone who understands the tool well enough to distinguish a website defect from unfamiliar screen-reader behavior. Keyboard, structure, zoom, contrast, and form checks are also essential and should not be skipped.

What should I fix first if I have hundreds of accessibility issues?

Fix blockers in critical user journeys first, then serious site-wide or template-level barriers. Prioritize by user impact, reach, and task importance. Repairing a shared navigation or form component can remove more barriers than fixing many isolated low-impact defects.

Does accessibility hurt design?

No. Clear focus styles, readable contrast, descriptive labels, predictable navigation, understandable forms, and generous target sizes can be integrated into strong visual design. Accessibility constraints often encourage more deliberate systems rather than less creativity.

Does meeting WCAG automatically mean I meet every accessibility law?

No. WCAG is a technical standard, while laws and regulations vary by jurisdiction and sector. Some laws and policies reference WCAG, but a technical accessibility guide cannot determine your legal obligations. Seek qualified local legal advice when you need a compliance conclusion.

Conclusion: start with one critical journey, then build a system

If your website has never been audited, do not begin by trying to repair every page at once. Pick one high-value user journey today. Put the mouse aside and complete it with a keyboard. Check focus, labels, headings, contrast, images, errors, zoom, and responsive behavior. Run an automated scan, but validate the findings manually. Then turn the highest-impact defects into assigned tasks with clear retest steps.

The most important mistake to avoid is treating accessibility as a one-time cleanup that ends when a score turns green. New content and components will keep arriving. Sustainable accessibility comes from better templates, semantic HTML, accessible design patterns, editor training, realistic testing, careful procurement, and feedback from people who encounter barriers.

That approach gives a small website something more valuable than a temporary badge: a repeatable way to make the product easier to perceive, operate, understand, and use as it grows.

Sources and further reading

Image credits: Accessibility.svg, Wikimedia Commons; Hand-on-high-contrast-accessible-computer-keyboard.jpg by Francisclarke, CC BY-SA 4.0; WCAG web safe contrast ratio.svg by Cmglee, CC BY-SA 4.0. This article is educational and provides technical accessibility guidance, not legal advice.