How to Make Your Website Accessible: A Practical WCAG 2.2 Audit

Quick answer: Making a website accessible is not a one-click cleanup and it is not only about adding alt text. A useful accessibility process starts by identifying the journeys people must be able to complete, then checking whether those journeys work with a keyboard, screen reader, zoom, high contrast, captions, clear structure, understandable forms, and predictable interaction. Automated scanners can find some problems, but they cannot prove that a page is accessible. The strongest approach combines standards such as WCAG, manual testing, real-user thinking, and a repeatable publishing workflow.

Accessibility is a design quality: information and controls should remain usable through different ways of seeing, hearing, moving, reading, and interacting. Image: Julian Kücklich, CC0, via Wikimedia Commons.

A website can look polished and still be difficult to use. A pale gray navigation menu may disappear for someone with low vision. A dropdown that only reacts to a mouse can trap a keyboard user. A checkout form can appear perfectly normal while a screen reader announces five anonymous edit fields with no useful labels. A video may contain the answer a visitor needs but provide no captions. A cookie banner may visually sit at the bottom of the page yet seize keyboard focus and make the rest of the site unreachable.

This guide shows how to turn accessibility from a vague goal into a practical improvement process. It is written for site owners, editors, designers, marketers, developers, and small teams who may not have a dedicated accessibility specialist. You do not need to memorize every WCAG success criterion before you start. You do need a method that reveals barriers, prioritizes fixes by user impact, and prevents the same errors from returning with every new article, landing page, form, or redesign.

The Web Content Accessibility Guidelines (WCAG) 2.2 are a W3C Recommendation and organize accessibility around four broad principles: content should be perceivable, operable, understandable, and robust. WCAG 2.2 added criteria that address issues such as obscured keyboard focus, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication. WCAG is a technical standard, not a promise that every possible user need has been solved. Treat it as a rigorous baseline and a shared language for evaluating barriers.

Important legal note: accessibility laws and obligations vary by country, organization type, and context. In the United States, the Department of Justice states that the ADA applies to services, programs, and goods offered by covered public entities and businesses open to the public. Separate Title II rules set specific web and mobile accessibility requirements for state and local governments, and their compliance dates were modified by an April 2026 interim final rule. This article explains practical accessibility, not legal advice or a determination of what any specific organization is legally required to do.

1. Start with the user journeys that matter most

The fastest way to waste an accessibility project is to treat every page as equally urgent. A 12-year-old press release and the current checkout page may both contain accessibility defects, but they do not create the same immediate risk or user impact. Begin by mapping the tasks people actually visit your site to complete.

Write down five to ten critical journeys. Depending on your website, these might include reading an article, searching for information, creating an account, signing in, submitting a contact form, buying a product, requesting a quote, booking an appointment, downloading a document, playing a video, changing a subscription, or finding an address and opening hours. For each journey, list every page, popup, form, and confirmation screen involved.

Then ask a more useful question than “Is this page accessible?” Ask: “Can a person complete this task when they cannot rely on a mouse, when they enlarge the page to 200% or more, when they use a screen reader, when they cannot hear the audio, when they have difficulty with precise pointer movements, or when they need more time to read?” That framing exposes barriers that visual inspection alone misses.

A practical audit sheet can have columns for journey, page URL, barrier, affected interaction, severity, owner, fix, test method, status, and retest date. Avoid assigning severity only by how difficult the code change is. A five-minute missing-label fix on a payment form can matter more than a complex visual issue on an unused archive page.

What success looks like: you have a short list of high-value journeys and know which pages deserve manual testing first. If your list contains hundreds of pages, you are still inventorying rather than prioritizing. Narrow it to the tasks that would cause a visitor real harm, exclusion, lost time, or lost money if they failed.

2. Test the entire site with a keyboard before touching a scanner

Put the mouse aside. Reload the page and use only the keyboard. On most desktop browsers, the Tab key moves forward through interactive controls and Shift+Tab moves backward. Enter or Space activates many controls, arrow keys operate certain widgets, and Escape often closes menus or dialogs. Exact behavior can differ by component and operating system, but the principle is simple: every function that requires interaction should have a usable keyboard path unless the task itself inherently requires a path-based pointer input.

Start at the top of the page and press Tab repeatedly. Watch where focus moves. You should be able to see which element currently has focus. If links, buttons, menu items, form controls, and dialog controls receive focus but no visible indicator appears, the page may be technically navigable while still being practically unusable for a sighted keyboard user.

Test the order. Does focus follow the same logical sequence as the page? A visually arranged two-column form can become confusing if focus jumps from the top-left field to the bottom-right field, then back upward. CSS can visually reorder content without changing its underlying focus or reading order, creating a mismatch between what people see and what assistive technology encounters.

Open every menu and accordion. Try modal dialogs, cookie settings, account menus, carousels, search suggestions, date pickers, filters, tabs, chat widgets, and embedded third-party components. The page should not create a keyboard trap, where focus enters a component and cannot escape through normal keyboard operation. A modal, on the other hand, usually needs to keep focus inside itself while it is open, then return focus to the control that opened it when it closes.

Pay special attention to sticky headers, cookie bars, and chat launchers. WCAG 2.2 specifically added a Level AA criterion intended to prevent the keyboard focus indicator from being entirely hidden by author-created content. A sticky header that overlays the focused link is not merely annoying; the user can lose track of where they are.

Common mistake: developers sometimes remove the browser’s default focus outline because it does not match the brand. If you replace it, replace it with a focus style that is at least as clear, not with nothing. The focus indicator is functional information.

If the test fails: identify whether the component uses a real interactive HTML element. A clickable <div> often creates more work than a native <button>, because the developer must manually reproduce keyboard behavior, focus handling, semantics, and states that the button already provides. Prefer native elements unless a custom component is genuinely necessary.

3. Make the page structure meaningful, not merely visual

Headings are not decorative font sizes. They create an outline that helps readers understand sections and gives screen-reader users a fast way to navigate. A person may jump from heading to heading instead of listening to every paragraph from the beginning. If the visual page has six bold section titles but the markup contains no headings, that navigation shortcut disappears.

Review the page’s heading hierarchy. The main page topic is typically represented by the primary heading, followed by second-level headings for major sections and third-level headings for subsections. You do not need to force every page into a rigid numbering system, but the levels should reflect the content hierarchy rather than the desired font size.

Do not pick an H4 because it looks smaller than an H2. Style headings with CSS while preserving semantic levels. Likewise, do not mark a paragraph as H2 just to make it large and bold. This confuses the document outline.

Check landmarks and regions too. Semantic elements such as <header>, <nav>, <main>, <aside>, and <footer> can help assistive technologies identify areas of the page. A “skip to main content” link near the start of the page gives keyboard users a way to bypass a long navigation menu on every page.

Lists should be real ordered or unordered lists when the relationship matters. Tables should be used for tabular data, not for visual layout. Data tables need meaningful headers so a screen reader can associate each value with its row or column context. A visually obvious table such as “Plan / Storage / Price” becomes much harder to understand if every cell is announced as an unrelated piece of text.

Verification: inspect the page using the browser’s accessibility tree or a heading-outline tool. Then compare that structure with what the page visually communicates. The goal is not to make the HTML look neat; it is to make the relationships understandable even when the visual layer is absent.

4. Write alt text that communicates the purpose of an image

“Add alt text to every image” is incomplete advice. The correct alternative depends on why the image is there. A decorative flourish may need an empty alt attribute so a screen reader can ignore it. A product image may need the product’s meaningful visual characteristics. A chart may need a concise alt description plus the actual data or a longer explanation nearby. A screenshot in a tutorial may need to describe the control or state the reader must identify, not every pixel on the screen.

Ask: if the image did not load, what information would be missing from the surrounding content? Put that information into text in the most efficient place. Sometimes that is the alt attribute; sometimes the surrounding paragraph, caption, or data table is better.

Avoid alt text such as “image,” “photo,” or a filename unless that wording is itself meaningful. Screen readers already know an image element is an image. “IMG_4839.jpg” does not help. Equally, do not stuff SEO keywords into alt text. Alternative text exists to convey equivalent purpose or information, and unnatural keyword strings degrade the experience.

Consider an article about replacing a bicycle tire. “Person fixing bicycle” is technically descriptive but may miss the instructional purpose. “Tire lever inserted beneath the tire bead opposite the valve” may be much more useful if that is what the reader needs to see. Context determines quality.

For linked images, the alternative may need to communicate the link’s destination or action. If a logo links to the home page, “Company name — home” can be more useful than an elaborate description of the logo artwork. If the visible text next to the image already communicates the same purpose, avoid forcing users to hear duplicate information.

A refreshable Braille display illustrates why web content needs meaningful text structure rather than depending on visual presentation alone. Image: Eddau, CC0, via Wikimedia Commons.

5. Fix color contrast without destroying the design

Color contrast problems are common because modern interfaces often use pale text, subtle borders, translucent overlays, and muted placeholder colors. Do not judge contrast by eye alone. Measure it with a reliable contrast checker and compare it with the applicable WCAG requirement for the text or user-interface component you are evaluating.

Start with body text, navigation, buttons, form labels, error messages, captions, and text placed over photographs. Then check interactive states: hover, focus, selected, disabled, and validation states. Designers sometimes verify the default button but forget that its hovered text becomes low contrast against a new background.

Never use color as the only way to communicate status. A form that turns an invalid field border red but provides no icon, message, or programmatic error association can fail users who cannot distinguish the color difference. A stock chart that uses only green and red lines can become ambiguous for some people with color-vision deficiencies. Add labels, patterns, shapes, text, or other redundant cues.

Links inside paragraphs deserve special attention. If they are identified only by a subtle color shift, people may not recognize them as interactive. Underlines are a strong, familiar cue. If a design removes them, make sure the alternative distinction remains clear in normal, hover, and focus states.

When contrast testing becomes messy: text over gradients and images can have different ratios at different pixels. The easiest fix is often not calculating an average but changing the design: add a solid or sufficiently opaque background behind the text, reposition the copy, or select an image area that produces stable contrast.

6. Make zoom and responsive layouts survive real enlargement

Accessibility testing should include browser zoom and narrow viewports. People with low vision may enlarge text or page content dramatically. A layout that works only at 100% zoom is fragile.

Zoom the page to 200%. Look for clipped navigation, overlapping text, buttons that disappear outside containers, horizontal scrolling for ordinary reading, dialog boxes that extend beyond the viewport, and fixed headers that consume most of the available screen. Increase text spacing if your test tools support it and check whether text remains readable without being cut off.

Do not disable pinch zoom on mobile pages. A site may be responsive yet still require magnification for individual users. Also test landscape orientation where practical; some people mount devices or use orientations that cannot easily change.

Responsive design can improve accessibility when it lets content reflow into a single readable column. It can also create new barriers when desktop navigation becomes a custom mobile menu that is not keyboard accessible, when labels disappear and are replaced by ambiguous icons, or when controls become too small and tightly packed.

WCAG 2.2 introduced a minimum target-size criterion at Level AA with defined exceptions. Even outside formal conformance testing, the user-centered lesson is straightforward: tiny controls create problems for people with limited dexterity, tremors, touch-screen users, and anyone using a device while moving. Give controls enough size and spacing to reduce accidental activation.

7. Make forms understandable before you make them beautiful

Forms are where accessibility defects become expensive. A reader can abandon a difficult article, but an inaccessible checkout, application, login, or contact form can completely block a transaction.

Every input needs a meaningful label that remains available when the person starts typing. Placeholder text is not an adequate replacement for a label because it disappears, can have poor contrast, and may be mistaken for an example value. Connect visible labels to their controls programmatically so assistive technology can announce them correctly.

Group related controls. A set of radio buttons asking for a delivery method needs a clear group question. Required fields should be identified in text or another accessible way, not only by color or an unexplained asterisk. Instructions should appear before users encounter an unfamiliar input format when possible.

When validation fails, explain what happened and how to fix it. “Invalid input” is much less useful than “Enter the date as month/day/year.” Ensure errors are associated with the relevant fields and that users can find them after submission. If the page reloads with errors, focus management or an error summary can help the user understand what changed.

Do not erase valid fields when one field contains an error. Re-entering an entire application because the postal code was mistyped is frustrating for everyone and particularly burdensome for people who enter data slowly. WCAG 2.2 also includes a redundant-entry criterion intended to reduce unnecessary re-entry of information in the same process, subject to exceptions.

Password and authentication flows deserve their own test. WCAG 2.2 introduced accessible-authentication criteria. Avoid login processes that unnecessarily depend on cognitive-function tests such as memorizing or transcribing information when alternatives or mechanisms can support the user. Allow password managers and paste operations where security design permits; blocking paste often hurts accessibility and can encourage weaker passwords.

Practical form test: complete the entire form with the keyboard, intentionally create one error in each type of field, zoom the page, use browser autofill, and repeat the process with a screen reader if possible. The form should tell you where you are, what is required, what went wrong, and what succeeded.

8. Use link and button text that makes sense out of context

Pages filled with “Click here,” “Read more,” and “Learn more” force users to reconstruct meaning from surrounding text. Screen-reader users may navigate through a list of links. A list containing twelve identical “Read more” items is not useful.

Prefer descriptive text: “Download the 2026 accessibility checklist,” “View shipping options,” or “Read the keyboard testing steps.” You do not need to turn every link into a sentence. The goal is enough context to predict the destination or action.

Distinguish links from buttons. A link normally navigates to another location; a button performs an action such as opening a dialog, submitting a form, revealing a menu, or saving changes. Styling a link to look like a button is not automatically wrong, but the underlying semantics should match the behavior so assistive technology can announce the control correctly.

Icon-only buttons need accessible names. A magnifying glass may visually imply search, but the button still needs an accessible label. The same applies to hamburger menus, close icons, share controls, carousel arrows, copy icons, and trash-can buttons.

9. Treat captions, transcripts, and audio control as core content

If information is provided through video or audio, accessibility requires more than adding a player. Captions make spoken content available to people who are deaf or hard of hearing and can also help people watching in noisy or quiet environments, language learners, and users who process written language more easily.

Do not assume automatic captions are finished captions. Automatic speech recognition can misinterpret names, technical terms, numbers, accents, or multiple speakers. Review and correct captions when accuracy matters. Synchronization matters too; captions that appear long after the spoken words can be difficult to follow.

Audio descriptions may be needed when important visual information is not conveyed in the existing audio track. For example, a training video may silently show the exact menu option to select. If the narration only says “choose this option,” a person who cannot see the screen misses the instruction. The fix may be a separate audio description track or simply better narration that naturally includes the important visual details.

Transcripts can make podcasts and interviews searchable and readable, but a transcript and captions serve different interaction needs. Do not automatically treat one as a universal substitute for the other.

Avoid autoplaying audio. Unexpected sound can interfere with screen readers and can be disruptive in public or work settings. If animation or moving content starts automatically and lasts long enough to distract users, provide appropriate controls to pause, stop, or hide it when required.

10. Design motion and animation so users can remain in control

Animation can explain relationships and provide feedback, but it can also create accessibility problems. Rapid flashing can create seizure risks for some users. Parallax effects and large motion transitions can trigger dizziness or nausea in users with vestibular disorders. Constantly moving carousels can make reading difficult for people who need more time.

Respect the operating system’s reduced-motion preference where feasible. Developers can use the prefers-reduced-motion media query to reduce or remove nonessential transitions for users who request it. This is not an excuse to leave dangerous flashing content untouched; it is one component of a broader motion strategy.

Do not make a dragging gesture the only way to complete an action when a simpler pointer alternative can accomplish the same function. WCAG 2.2 added a Level AA dragging-movements criterion. A reordering interface, slider, map, or drag-and-drop uploader may need buttons, direct input, or another non-drag path depending on the function.

11. Check dialogs, popups, cookie banners, and third-party widgets

Many accessibility failures come from components the site owner did not build: consent managers, chat tools, booking widgets, review widgets, advertising modules, embedded forms, social feeds, payment components, and analytics dashboards. Outsourcing the code does not remove the barrier for the user.

For each third-party widget, test keyboard access, focus order, labels, zoom behavior, contrast, and screen-reader announcements. Open a cookie preference dialog using only the keyboard. Can you reach every category? Does the close button have a name? Can you save the choice? When the dialog closes, does focus return somewhere sensible?

Watch for overlays that claim to fix accessibility automatically. The U.S. Department of Justice’s general web-accessibility guidance warns that automated accessibility checkers and overlays can be helpful but must be used carefully; a clean automated report does not prove that everything is accessible. Accessibility requires testing actual content and interaction, not simply installing a badge or script.

If a vendor component fails, document the failure and contact the vendor with reproducible steps. Include the browser, keyboard sequence, expected behavior, actual behavior, and any assistive technology used. If the component blocks a critical journey and cannot be fixed promptly, consider an accessible alternative rather than accepting permanent exclusion.

12. Test with a screen reader at a beginner-friendly level

You do not need to become an expert screen-reader user to learn from a basic test, but approach it with humility: a sighted beginner using a screen reader is not a substitute for a person who relies on one daily.

Common options include VoiceOver on Apple devices, Narrator on Windows, TalkBack on Android, and NVDA on Windows. Learn the basic commands for reading, moving by headings, moving by links, and entering forms mode or interacting with controls. Then test one of your critical journeys.

Listen to the page title first. Is it specific enough to identify the page? Navigate by headings. Does the resulting outline make sense? Move through links. Are they descriptive? Inspect form fields. Are labels and required states announced? Open menus and dialogs. Are expanded, collapsed, checked, selected, and invalid states communicated?

Do not optimize for the screen reader by adding excessive ARIA everywhere. Native HTML should be preferred when it can provide the needed semantics and behavior. Incorrect ARIA can make a page less accessible by overriding useful native semantics or announcing states that do not match reality.

A common example is adding role="button" to a generic element but forgetting keyboard support. A screen reader announces “button,” yet pressing Space does nothing. The semantic promise and actual behavior disagree. A native button usually avoids this mismatch.

Websites should not assume every visitor uses a mouse or touchscreen with precise movement. This single-switch device supports access to an on-screen keyboard. Image: vtsaran, CC BY 2.0, via Wikimedia Commons.

13. Audit page titles, language, and reading clarity

Accessibility is not only a component problem. The basic language and metadata of a page affect orientation and comprehension.

Give every page a descriptive title. “Home,” “Page 2,” or a repeated company name across every tab does not help users distinguish browser tabs or understand search results. A good title identifies the page and, when useful, the site or organization.

Set the page’s primary language in markup. Screen readers use language information to choose pronunciation rules and voices. If a long passage switches to another language, mark that change where appropriate so assistive technology can pronounce it more accurately.

Write clear instructions. Accessibility benefits from plain language, especially when the user must make a decision or recover from an error. Avoid unnecessary jargon, unexplained abbreviations, and instructions that depend on visual position alone, such as “click the green button on the right.” Layout can change on mobile, and color may not be perceptible. “Select Continue” is more robust.

Break dense content into meaningful sections. Use paragraphs, lists, descriptive headings, examples, and summaries where they improve comprehension. Do not confuse plain language with oversimplification; complex subjects can remain accurate while being organized for readers who are under time pressure, have cognitive disabilities, are reading in a second language, or are simply scanning on a phone.

14. Make PDFs and downloads part of the accessibility audit

Many websites appear accessible until the user clicks “Download application,” “Annual report,” “Menu,” or “Instructions” and lands in an inaccessible PDF. Downloaded documents are part of the user journey.

Start by asking whether the information needs to be a PDF at all. HTML is often easier to make responsive, searchable, and usable across assistive technologies. If a PDF is necessary, it should have meaningful tags and reading order, document language, descriptive title, heading structure, alt text for informative images, properly identified table headers, useful link text, and accessible form fields where relevant.

A document created from a scanned paper may contain nothing but page images. Optical character recognition can add text, but OCR alone does not create a well-structured accessible document. Tables, headings, reading order, form fields, and image alternatives still need attention.

Include downloadable spreadsheets, slide decks, and word-processing files in the inventory. A beautifully accessible web page that links to an unusable application form still leaves the task unfinished.

15. Use automated testing for speed, not as a certificate

Automated tools are valuable because they can scan many pages and consistently detect certain machine-testable issues: missing attributes, some contrast failures, duplicate IDs, invalid ARIA combinations, missing form labels, empty buttons, and structural problems. They are excellent for regression testing.

What they cannot do reliably is determine whether alt text is meaningful, whether a heading hierarchy accurately describes the content, whether a keyboard workflow makes sense, whether a validation message is understandable, whether focus moves appropriately after a dynamic update, or whether a caption accurately represents the audio.

Use automated testing in three layers. First, run it during development so developers receive feedback before code is merged. Second, scan representative production pages after deployment. Third, monitor templates and components over time so a theme or plugin update does not silently reintroduce failures.

Do not use an automated score as the sole accessibility KPI. A page can score highly because the scanner only detected what it knows how to detect while a single keyboard trap makes the entire checkout impossible. Track barriers by user impact and critical journey, not just issue count.

16. Build a manual 10-minute accessibility check for every important page

A repeatable short check is better than an ambitious audit performed once and forgotten. Before publishing an important page, run this sequence:

Read the page title and verify that it uniquely describes the page.
Navigate the page using only Tab, Shift+Tab, Enter, Space, arrows where relevant, and Escape.
Confirm that keyboard focus is always visible and not hidden behind sticky content.
Review the heading outline and confirm that sections have meaningful hierarchy.
Inspect every informative image and verify that its text alternative matches its purpose.
Measure contrast for body text, interactive controls, and important states.
Zoom to 200% and check for clipping, overlap, lost controls, and unnecessary horizontal scrolling.
Submit each form with intentional errors and verify labels, instructions, and recovery.
Mute audio and verify captions or text alternatives for multimedia.
Run an automated checker, then investigate its findings rather than treating the score as a pass/fail certificate.

This check will not prove WCAG conformance, but it catches a surprisingly large class of high-impact mistakes before they reach users. W3C’s own Easy Checks resource makes a similar point: quick checks provide an initial picture, not a comprehensive evaluation.

17. Prioritize fixes by impact, frequency, and reach

An accessibility backlog can become overwhelming if it contains hundreds of scanner findings with no prioritization. Use three questions.

Impact: does the defect completely block a task, seriously slow it down, or create mild inconvenience? A keyboard trap is typically more severe than a minor decorative issue.

Frequency: how often is the defective component encountered? A broken menu on every page deserves attention before a similar issue in one obscure article.

Reach: is the problem inside a reusable component? Fixing a theme button, form field component, modal, or navigation pattern can repair hundreds of pages at once.

A practical order is often: critical blockers in revenue, service, safety, account, or application journeys; global template and navigation defects; high-traffic page barriers; repeated content-authoring problems; then lower-impact legacy content. This is a management approach, not a rule about legal priority.

Record why an item received its priority. Without that note, teams may later sort the backlog by whatever appears easiest and leave difficult blockers unresolved.

18. Fix the design system so problems do not keep returning

If every page requires a manual accessibility rescue, the underlying publishing system is broken. The greatest leverage usually comes from templates and components.

Build accessible defaults for buttons, links, form fields, focus styles, alerts, cards, navigation, tables, tabs, accordions, and modal dialogs. Document the required states: default, hover, focus, disabled, error, selected, expanded, loading, and success. Include keyboard behavior and accessible names in the component specification, not as a later QA note.

Create approved color combinations so editors do not have to calculate contrast from scratch every time. Add alt-text guidance next to the image uploader. Prevent heading styles from being selected only by visual size. Give video publishers a caption checklist. Include an accessible table pattern rather than encouraging editors to paste screenshots of spreadsheets.

For a WordPress site, inspect the theme, block patterns, plugins, page-builder widgets, and custom CSS. A theme can provide strong semantic foundations while one plugin introduces inaccessible controls. Conversely, a plugin may be accessible but customized CSS can remove focus outlines or create low contrast.

Accessibility belongs in procurement too. Before buying a theme, booking engine, learning platform, chat widget, or form product, ask the vendor for accessibility documentation and test the actual product. A marketing page that says “WCAG compliant” is not a substitute for evidence and hands-on testing.

19. Give content editors responsibilities they can actually control

Developers cannot solve alt text for images they never see, and editors cannot repair a JavaScript focus trap. Divide ownership.

Editors should normally be responsible for descriptive headings, sensible link text, image alternatives, captions and transcripts where needed, accessible tables, clear instructions, document quality, and avoiding images of text when ordinary text would work.

Designers should own contrast, focus visibility, target sizing, consistent interaction patterns, typography, responsive behavior, and states that do not rely on color alone.

Developers should own semantic implementation, keyboard behavior, focus management, accessible names and states, robust forms, dynamic announcements, ARIA where necessary, and automated regression tests.

Product owners and managers should own prioritization, acceptance criteria, vendor decisions, audit cadence, user feedback, and ensuring that accessibility is not removed from scope when deadlines become tight.

When responsibility is vague, everyone assumes someone else has handled it.

20. Include accessibility in the definition of done

The cheapest accessibility defect to fix is the one caught before launch. Add accessibility criteria to tickets and content checklists. A story for a new modal should include keyboard operation, focus placement, focus return, visible focus, screen-reader name and role, escape behavior, zoom behavior, and error states before the component is accepted.

A content ticket for a tutorial should include heading structure, meaningful links, alt text, captions for embedded instructional videos, and mobile reading checks. A redesign ticket should include contrast checks for every state, not only the desktop mockup.

Teams often say accessibility slows development when they really mean they are discovering requirements after the component is already built. Designing accessibility into the acceptance criteria reduces rework.

21. Establish a quarterly audit instead of waiting for a complaint

Websites change continuously. New plugins, articles, campaigns, staff, checkout flows, cookie tools, and browser updates can alter accessibility. A one-time audit ages quickly.

Every quarter, select a representative sample: home page, major landing pages, one long article, search, contact form, account flow, purchase or conversion flow, one page with video, one page with a table, and any newly launched feature. Repeat keyboard, screen-reader, zoom, contrast, and automated tests.

Compare results with the prior quarter. Did issue types fall? Are the same defects returning? If 80 percent of new problems are missing form labels, the answer is not more audits; it is fixing the form component and workflow.

Track user-reported accessibility issues separately and give them a clear response process. The DOJ specifically lists providing a way for the public to report accessibility problems as a useful practice. A visible accessibility contact method also gives users an alternative path when a defect has not yet been discovered internally.

22. Test with people who use assistive technology when the stakes are high

Technical standards and tools are essential, but they do not replace user experience. A site can satisfy individual criteria and still be exhausting to use because of unnecessary steps, repetitive announcements, confusing language, or poor focus management.

When possible, include people with disabilities in usability testing, especially for critical services, applications, checkout, health information, education, government services, and complex workflows. Compensate participants fairly for their time and expertise.

Do not ask a single participant to represent every disability. Accessibility needs vary. Someone who uses a screen reader may reveal different barriers from someone who uses voice control, magnification, captions, keyboard-only input, switch access, or reduced motion.

The objective is not to obtain a testimonial that the site is accessible. It is to discover where real people lose time, confidence, context, or access.

23. Understand what WCAG 2.2 changed in practical terms

WCAG 2.2 was published as a W3C Recommendation in October 2023 and added nine success criteria compared with WCAG 2.1 while removing the obsolete 4.1.1 Parsing criterion. For a working site team, the new criteria are useful because they focus attention on interaction problems that are easy to overlook.

Focus Not Obscured (Minimum): when a component receives keyboard focus, author-created content should not completely hide it at the Level AA requirement. Sticky headers and overlays are frequent causes.

Dragging Movements: functionality that uses dragging should have a single-pointer alternative unless dragging is essential. Think of sortable lists, sliders, and drag-and-drop interfaces.

Target Size (Minimum): pointer targets need sufficient size or spacing under the criterion’s specific conditions and exceptions. This is especially relevant to tightly packed mobile controls.

Consistent Help: when help mechanisms repeat across multiple pages, their relative order should remain consistent under the criterion’s scope. Consistency reduces the effort needed to find assistance.

Redundant Entry: information already entered during the same process generally should not need to be entered again unless an exception applies. This reduces memory and typing burden.

Accessible Authentication (Minimum): authentication should not force certain cognitive-function tests unless an alternative or assisting mechanism is available under the criterion. Real-world examples include unnecessary memory or transcription demands.

The Level AAA additions go further in areas such as focus appearance, enhanced focus visibility, and enhanced accessible authentication. Even if your target is Level AA, reading the AAA criteria can reveal design improvements that benefit users.

24. Do not confuse a legal target with a product-quality ceiling

Organizations often ask, “Which version of WCAG do we legally need?” That is a legitimate compliance question, but it is not the only design question.

In the United States, the DOJ’s 2024 Title II rule for state and local governments incorporated WCAG 2.1 Level AA as the technical standard for covered web content and mobile apps, with defined exceptions. In April 2026, the Department issued an interim final rule extending compliance dates: public entities with populations of 50,000 or more were given until April 26, 2027, while smaller public entities and special district governments were given until April 26, 2028. Private businesses operate under a different Title III framework; DOJ guidance explains that businesses open to the public must provide accessible goods and services and points to technical standards such as WCAG as useful guidance, but legal analysis depends on the organization and jurisdiction.

From a product perspective, however, a newer accessibility practice may be worth adopting even if a regulation references an older version. If a WCAG 2.2 improvement prevents a sticky header from hiding focus, users benefit now. Standards should inform the product, not become an excuse to ignore known barriers until a legal date arrives.

25. Build a 30-day accessibility improvement plan

Days 1–3: inventory and critical journeys

List your primary templates, top traffic pages, conversion journeys, forms, downloadable documents, videos, and third-party widgets. Choose five critical journeys. Record the pages involved and the business owner of each.

Days 4–7: baseline testing

Run keyboard tests, 200% zoom tests, heading reviews, alt-text reviews, and automated scans on those journeys. Capture issues with reproducible steps. Do not fix randomly while auditing; finish enough of the baseline to understand patterns.

Days 8–12: remove blockers

Fix keyboard traps, inaccessible navigation, unlabeled critical form controls, invisible focus, unreachable buttons, severe contrast failures, inaccessible authentication steps, and errors that prevent task completion. Retest each fix in the same way the issue was found.

Days 13–17: repair reusable components

Move from individual pages to global patterns. Update the design system, WordPress theme, reusable blocks, form components, menu, buttons, modals, and content templates. A component-level fix can eliminate hundreds of defects.

Days 18–21: content cleanup

Improve headings, alt text, link wording, tables, captions, transcripts, page titles, and downloadable files on the most important pages. Create short editorial rules so new content follows the same standard.

Days 22–24: third-party review

Test consent tools, chat, payment, booking, advertising, social, video, and other embedded services. Contact vendors with defects and document alternatives for critical blocked tasks.

Days 25–27: assistive-technology testing

Test representative journeys with at least one screen reader and, where practical, other relevant assistive technologies. If the site is high stakes, arrange usability testing with people who use assistive technology in daily life.

Days 28–30: governance

Create a quarterly test schedule, an accessibility issue contact path, ownership rules, release criteria, a vendor-procurement checklist, and a regression-testing plan. Accessibility should now be part of ordinary site maintenance rather than a special project.

26. A practical acceptance checklist for new pages

The page has a unique, descriptive title.
The primary language is identified correctly.
Headings reflect the real content hierarchy.
All interactive controls work with a keyboard.
Focus is visible and is not hidden by overlays or sticky content.
There are no keyboard traps.
Informative images have purposeful text alternatives.
Decorative images do not create unnecessary screen-reader noise.
Text and important interface states have sufficient contrast.
Information is never conveyed by color alone.
Text remains usable at 200% zoom.
The layout reflows without losing essential information or controls.
Form fields have persistent, programmatically associated labels.
Error messages explain the problem and how to fix it.
Valid data is not unnecessarily erased after an error.
Links and buttons have descriptive accessible names.
Videos have accurate captions when speech or meaningful audio is present.
Important visual-only video information has an accessible alternative.
Motion can be paused or reduced where required.
Drag-only interactions have appropriate alternatives when required.
Third-party widgets have been included in keyboard and screen-reader testing.
Downloads and PDFs required to complete the task are accessible.
An automated checker has been run, but manual checks were not skipped.

27. Common accessibility fixes that create new problems

Adding ARIA to everything: excessive or incorrect ARIA can hide native semantics or create misleading announcements. Use semantic HTML first.

Setting every image to empty alt: this makes genuine information disappear for nonvisual users. Decorative and informative images need different treatment.

Replacing visible labels with placeholders: the interface looks cleaner but becomes harder to understand after typing begins.

Removing outlines globally: the design may look minimal, but keyboard users lose their location.

Installing an overlay and declaring the project complete: automated scripts cannot correct every content, structure, keyboard, or usability barrier.

Making the mobile version visually simple by hiding content: responsive design should reorganize information, not remove essential functions from people using narrow or enlarged views.

Writing extremely long alt text for every image: more text is not automatically more accessible. Convey purpose efficiently and move complex explanations into nearby prose when appropriate.

Publishing captions without reviewing them: a visible caption track can still be unusable if names, numbers, or instructions are wrong.

28. How to measure improvement without chasing vanity scores

Create metrics that reflect actual access. Useful measures include the percentage of critical journeys that pass keyboard testing, the number of severe blockers open, median time to fix a user-reported barrier, percentage of new videos with reviewed captions, percentage of new images reviewed for alt purpose, percentage of reusable components with documented keyboard behavior, and number of regression failures found before production.

Automated issue counts can still be useful as trend data, especially if the scan scope remains consistent. If the number suddenly doubles after a theme update, investigate. But do not compare unrelated tools as if a 92 from one scanner and a 96 from another were an objective accessibility grade.

Qualitative findings matter. If three assistive-technology users independently become confused at the same checkout step, that is meaningful even if no scanner flags it.

Frequently asked questions

Can an automated tool tell me whether my website is WCAG compliant?

No automated tool can comprehensively determine accessibility or WCAG conformance on its own. Many requirements require human judgment, interaction testing, or evaluation of meaning. Automated scanning is useful for finding some classes of errors quickly and repeatedly.

Do all images need alt text?

All images need an appropriate text-alternative strategy, but that does not mean every image needs descriptive wording. Decorative images can often use an empty alt attribute so assistive technology ignores them. Informative images need an equivalent alternative, and complex charts may need both concise alt text and a longer nearby explanation or data representation.

Is WCAG 2.2 the current W3C Recommendation?

Yes. WCAG 2.2 became a W3C Recommendation on October 5, 2023. It builds on WCAG 2.1 and adds nine success criteria while removing the obsolete 4.1.1 Parsing criterion.

If my site passes a contrast checker, is the design accessible?

No. Contrast is one accessibility dimension. Keyboard access, focus visibility, headings, forms, text alternatives, reflow, target size, multimedia, motion, language, and dynamic behavior can still create barriers.

Should I target Level AA?

Level AA is a common organizational target because it includes Level A and AA criteria, and many policies or regulations reference that level. Your exact legal or contractual requirement can differ by jurisdiction and organization. From a product perspective, some AAA practices may still be valuable even when AAA conformance is not the formal target.

Does an accessibility statement make a site accessible?

No. A statement can explain your commitment, standards target, known limitations, and contact method, but it does not compensate for inaccessible functionality. Its value comes from transparency and giving users a way to report problems while the underlying site is actively maintained.

What should I fix first on a large old website?

Start with blockers in critical user journeys, then global components that affect many pages, then high-traffic content and repeated editorial problems. Build accessible defaults before attempting a page-by-page cleanup of the entire archive.

Conclusion: make accessibility a publishing habit, not a rescue project

The most important first step is not buying a scanner or rewriting the entire website. Choose one critical journey and complete it without a mouse. That simple test often reveals whether accessibility has been treated as a real interaction requirement or as a cosmetic checklist.

Then work outward: fix focus, semantics, labels, contrast, reflow, media alternatives, and document structure; test with assistive technology; repair reusable components; and add accessibility to the definition of done. The biggest mistake is waiting for a final audit after hundreds of inaccessible pages and components already exist.

An accessible website is not finished because it earns a score. It improves because the team keeps asking whether people can perceive the information, operate the controls, understand the process, and use the site with the technologies they rely on. That is the standard worth building into every release.

Sources and further reading

Image licensing: Accessibility.png by Julian Kücklich is dedicated to CC0. Refreshable Braille display 2010 0123.JPG by Eddau is CC0. Single switch onscreen keyboard.jpg by vtsaran is licensed CC BY 2.0. Licensing and source details are available on the respective Wikimedia Commons file pages.