How to Make a Website Accessible: From Audit to Fixes (Checklist included)

Updated on: 10/08/2026

Making a website accessible requires fixing code-level barriers and verifying the experience with real user tools. Core priorities include establishing full keyboard operability, structuring content with proper HTML headings, designing with high color contrast, and adding descriptive alternative text for non-text content. Combining automated code scans to catch volume issues with manual screen reader testing ensures your site meets WCAG standards and works seamlessly for everyone.

Most websites have accessibility barriers. According to the WebAIM Million 2026 report, 95.9% of home pages tested had at least one automatically detectable WCAG failure, up from 94.8% the year before.

Here is our 2026 checklist

How to make your website accessible

1. Images and alt text

2. Color contrast

3. Use headings and lists correctly

4. Keyboard navigation

5. Form labels

6. Let users control time limits

7. Link text

8. Write in plain language

9. Multimedia content

10. Make downloadable documents accessible

11. Animations and moving content

12. Add a skip navigation link

13. Don't rely on formatting alone

There are two ways to find out your site isn't accessible: you discover it yourself, or someone tells you. The first is a much better position to be in.

13 Tips to Make Your Website Accessible

Add alt text to images

The most common failure, and also the most straightforward to fix systematically. Every informative image needs an alt attribute that describes what the image shows and why it's there not what it looks like. "Chart showing 34% growth in WCAG adoption across European financial services in 2024" is useful. "Chart" is not.

For decorative images dividers, purely aesthetic backgrounds, icons that add no information, use alt="". Screen readers will skip them entirely. For images that also function as links, the alt should describe the link destination, not the image.

One detail that often gets overlooked: the file name.

wcag-audit-results-dashboard.webp is indexable and meaningful. IMG_2034.webp tells nobody anything.

Ensure sufficient color contrast

Light gray text on white backgrounds, colored links on colored backgrounds, placeholder text in form fields with barely perceptible contrast: all of these are precisely measurable failures.

Something that gets missed regularly: color can't be the only way to communicate information. If an error in a form is indicated only by a red border, anyone who doesn't perceive that color difference won't see it. There needs to be a text alternative too.

Make your site keyboard navigable

• Put your mouse aside and press Tab. If focus disappears after a few interactions, if certain elements are unreachable, if a modal opens and you can't get out — you've found real problems.

• The most common issue: outline: none in CSS, used to remove the focus ring for aesthetic reasons without replacing it with anything visible. It's one of the most widespread failures and one of the most impactful for keyboard users.

• Modals and dialogs need explicit focus management: when they open, focus moves inside; while they're open, focus can't escape; when they close, focus returns to the element that triggered them.

• Custom interactive components dropdowns, accordions, date pickers, often need specific ARIA implementation to work correctly with screen readers. Test them all, with an actual screen reader rather than just tabbing through.

Use headings and lists correctly

Headings and lists let a screen reader user understand page structure without reading top to bottom.

• One <h1> per page, with nested levels in order, never skipped for visual reasons.

• Use real <ul>/<ol> markup, not typed-out numbers or dashes: only true list markup gets announced as a list.

• Bold text styled to look like a heading isn't one, and won't show up in heading navigation.

• Prefer native HTML elements over ARIA roles bolted onto generic elements use <button> instead of <div role="button">. The safest ARIA is often the ARIA you don't need.

Label your form fields correctly

A placeholder is not a label. It disappears as soon as someone starts typing, it isn't read consistently across all screen readers, and it doesn't meet WCAG requirements.

• Every field (<input>, <select>, <textarea>) needs a <label> element associated via for + id, or an aria-label, or an aria-labelledby.

• Error messages need to be in text, specific ("Enter a valid email address, for example name@example.com"), and programmatically linked to the field via aria-describedby. A red border alone is not sufficient.

• Related fields groups of checkboxes, radio button sets — need to be wrapped in <fieldset> with a <legend>. Without this structure, a screen reader has no way to communicate what the group is about.

Let users control time limits

Session timeouts and auto-submitting countdowns need a way out. Criterion 2.2.1 requires users can turn off, adjust, or extend a time limit before it expires.

• Warn users before a session expires, with a one-click way to extend it.

• Avoid time limits on forms unless there's a real reason for them.

• If a limit is unavoidable, state it clearly rather than letting the page silently expire.

Write descriptive link text

"Click here", "learn more", "read the article": these anchors mean nothing to someone navigating with a screen reader, because links are often read out as a list, stripped of surrounding context.

The same applies to raw URLs used as link text. A thirty-character web address read aloud by NVDA helps no one understand where they're going.

Write in plain language

Jargon and complex sentences create barriers for people with cognitive or learning disabilities. Not a strict WCAG 2.1 AA requirement, but it supports the same audience as the AA criteria target.

• Short sentences, common words, technical terms defined on first use.

• Break long paragraphs apart; bullet lists of three or more items.

• Avoid idioms and culturally specific references.

Make multimedia content accessible

Videos with audio need synchronized captions (criterion 1.2.2). Auto-generated captions from YouTube or similar platforms are not reliable enough on their own they fail regularly on technical terminology, proper nouns, and accents. Human review is necessary before publishing.

For audio-only content podcasts, recorded presentations a full text transcript is required. For videos where significant visual information isn't described in the audio, an audio description is needed. For organizations with large volumes of PDF documents, Accessiway's PDF Solution Suite covers document remediation for files that would otherwise remain inaccessible to screen readers.

Make downloadable documents accessible

PDFs, Word, and PowerPoint files need the same alt text, heading structure, and contrast as your web pages.

• Publish content as HTML instead of a downloadable file where possible.

• Run files through the accessibility checker in Word, PowerPoint, or Acrobat before publishing.

• Tag scanned PDFs: a scanned image with no underlying text is invisible to a screen reader.

Control animations and moving content

Auto-playing carousels, looping GIFs, sliders with automatic progression: these can all cause serious problems for people with photosensitive epilepsy or vestibular disorders.

Criterion 2.3.1 prohibits elements that flash more than three times per second. Criterion 2.2.2 requires that any moving content that starts automatically and lasts more than five seconds can be paused, stopped, or hidden by the user. If a carousel is necessary, add a visible pause control that works from the keyboard.

Add a skip navigation link

People navigating by keyboard or screen reader have to tab through your entire header and nav before reaching the main content, unless you give them a way to skip it.

• Add a "Skip to content" link as the first focusable element on the page, visually hidden until it receives keyboard focus.

• Point it to your main content area with an anchor link, or rely on the <main> landmark so assistive technology can jump there directly.

• Test it by loading the page and pressing Tab once, before clicking anywhere.

Don't rely on formatting alone

Screen readers don't announce visual formatting changes. If something is important, marking it bold or highlighting it red isn't enough for users who can't perceive those visual cues. Add a text label: "Important:", "Warning:", "Required:". This applies to error states, required fields, key instructions, and any other information currently communicated only through visual styling.

Where to start: the audit

An accessibility audit isn't a single thing. It's the combination of three types of review, each of which finds problems the others miss.

Automated scanning. Tools like WAVE, Axe DevTools, or Lighthouse analyze your code and flag mechanically detectable errors: images without alt text, form fields without labels, insufficient color contrast. They cover roughly 30–40% of real failures. Use them as a starting point, not a finishing line. The Accessiway website accessibility audit combines automated scanning with human review to cover both levels.

Manual testing. Navigate your site using only the keyboard, no mouse. Turn on a screen reader (NVDA on Windows, VoiceOver on Mac) and listen to how your pages are read aloud. What you find here , focus that disappears, illogical reading orders, modals that trap navigation, won't appear in any automated report.

Testing with people with disabilities. The most valuable test of all. People who use assistive technology every day have practical experience that no tool and no expert without that direct lived experience can replicate. Accessiway's User Testing service structures this phase for teams that want to involve people with disabilities in the review process on an ongoing basis.

The WCAG 2.1 AA criteria to prioritize

The Web Content Accessibility Guidelines (WCAG) 2.1 AA are the international technical standard that defines what an accessible website looks like. They form the technical baseline for the European Accessibility Act (EAA), which extended compliance requirements to private sector organizations across the EU from 28 June 2025, and underpin accessibility laws in many other jurisdictions including the Americans with Disabilities Act (ADA) and Section 508 in the United States.

There are 50 Level AA criteria. These are the ones most frequently violated:

1.1.1 — every informative image needs a descriptive alt text

1.2.2 — videos with audio need synchronized captions

1.3.3 — instructions can't rely solely on visual characteristics ("click the red button")

1.4.3 — contrast ratio between text and background: at least 4.5:1 for normal text, 3:1 for large text

1.4.4 — text must remain readable at 200% zoom without loss of content

2.1.1 — all functionality must be reachable and operable using only a keyboard

2.3.1 — nothing on the page should flash more than three times per second

2.4.4 — link text must describe the destination, not the action ("read the WCAG guidelines", not "click here")

2.4.7 — keyboard focus indicator must be visible at all times during keyboard navigation

3.3.2 — every form field needs a programmatically associated label

4.1.2 — all interactive elements must have a name and role that assistive technologies can read

Which tools do you need

No single tool finds everything. Use more than one.

For automated scanning: WAVE overlays errors directly on the page — the most readable format for non-developers. Axe DevTools as a browser extension gives more detailed explanations with links to the specific WCAG criteria. Lighthouse, built into Chrome DevTools, is useful if you already run it for other technical audits. It also measures the Core Web Vitals that affect how usable a page feels for people using assistive technology, and its new experimental Agentic Browsing category tests whether AI agents can navigate your site using the same accessibility tree screen readers rely on

For contrast: the TPGi Colour Contrast Analyser is the standard. It works offline, samples any color directly from the screen, and is more precise than online checkers for borderline cases.

For screen readers: NVDA on Windows with Firefox is the most widely used combination among real users. VoiceOver on Mac with Safari. TalkBack on Android with Chrome. Testing with only one isn't sufficient they behave differently with the same code.

For keyboard: no tool needed. Tab, Shift+Tab, Enter, Space, arrow keys. Note every point where focus disappears or where you can't activate something.

How to organize remediation

Remediation is the correction work that follows the audit. The main risk is treating it as a list to tick off rather than a process to manage.

Start with triage. Classify each issue by:

• User impact

• Frequency (how many pages or components it affects)

• Estimated fix effort

Critical errors on reusable components like global navigation, header, footer, shared form elements go to the top. Fix them once and the same barrier is resolved across hundreds of pages.

Every fix needs:

• An owner

• An estimate

• A deadline

The WCAG criterion it addresses, tagged on the ticket, you'll need this for your Accessibility Statement and to demonstrate progress over time

Jira, Linear, and GitHub Issues all work. What matters is that tracking exists and is shared across design, development, and QA.

Accessibility fixes break easily in subsequent deployments. Documenting expected behavior and integrating accessibility checks into your CI/CD pipeline is what separates a one-off project from a sustainable practice. For teams that want internal training on these processes, Accessiway Academy offers structured programs for developers, designers, and content teams.

Frequently asked questions

When can a website be considered accessible?

A website is considered accessible when anyone, regardless of disability or assistive technology, can navigate, understand, and complete every key task without barriers. Conforming to WCAG 2.1 Level AA standards across both automated checks and manual testing provides the legal and technical baseline for accessibility.

What is an Accessibility Statement and do I need one?

An Accessibility Statement is the public document where an organization declares its site's conformance level with WCAG, lists known barriers not yet corrected, and provides a way for users to report problems. For organizations subject to the EAA, it's mandatory.

For public sector organizations in the US, Canada, and Australia, equivalent requirements apply under local law. It must include your conformance status, known barriers with reasons they haven't been fixed, available accessible alternatives, a contact for reporting issues, and a reference to the relevant enforcement mechanism.

How long does remediation take?

It depends on the size of the site and how many barriers exist. A site with a consistent architecture and a small number of templates can complete a meaningful first remediation in four to six weeks. A large portal with dozens of templates and legacy content can take six to twelve months of structured work. In both cases, starting with reusable components is the most efficient approach: fix them once, and the same barrier is resolved across the entire site.

What's the difference between WCAG 2.1 AA and AAA?

Level AA is the legal benchmark it's what the EAA, ADA, Section 508, and most national accessibility laws require. Level AAA is more demanding and includes criteria that aren't legally required: extended audio descriptions, simplified language, sign language for pre-recorded content. Reaching AAA on specific high-traffic features is a reasonable goal for organizations that want to go further, but it isn't a compliance requirement. The WCAG guidance page has a full breakdown of levels and what each one entails.

Should I use an accessibility overlay?

No. Overlay widgets promise instant compliance by injecting a script into your site, but they don't fix the underlying code. Testing has repeatedly shown they introduce new barriers instead, and several vendors have been named in the same lawsuits they claim to prevent.

How much does an accessibility audit cost?

It depends on site size and whether testing is automated only or includes manual and disability-user testing. Free tools like WAVE or Axe DevTools catch roughly 30–40% of real issues at no cost; a full audit costs more but finds what automated tools miss.

If you're mapping out your remediation path, the our digital accessibility platform combines automated scanning with human expertise to identify barriers, prioritize them, and track progress over time. You can also start with a free audit to get an initial picture of where your site stands.