The audit that doesn't require a consultant
Most accessibility guides for non-specialists end up in one of two places. Either they're so general that you finish reading and still don't know what to actually do, or they dive straight into WCAG success criteria written for auditors and leave you more confused than when you started.
This isn't either of those. This is a practical walkthrough of the six areas where accessibility barriers appear most often, using tools that are free and already available to you, with concrete before/after examples and a simple framework for deciding what to fix first.
You don't need to be a developer to complete this audit. You need a browser, a checklist, and about two hours per page. If you find issues you can't fix yourself, what you'll have at the end is a prioritized list you can hand to someone who can.
One honest caveat before we start: this checklist will catch a significant portion of the barriers on most sites. It won't catch everything. A complete accessibility audit requires manual testing with assistive technology and, ideally, testing with disabled users. What this checklist gives you is a strong, documented starting point.
Before you begin: set up your tools
You'll need three tools. All three are free.
WAVE (wave.webaim.org): A browser extension (Chrome and Firefox) that overlays your page with visual icons showing accessibility issues. Excellent for getting a quick overview of structural problems: missing alt text, empty headings, missing form labels, and contrast errors.
Colour Contrast Analyser (paciellogroup.com/resources/contrastanalyser): A desktop app for Windows and macOS. You use it to eyedropper colors directly from your screen and check whether the contrast ratio meets WCAG thresholds. Faster and more accurate than CSS-based contrast checkers when colors are defined with gradients or images.
axe DevTools browser extension (deque.com/axe/devtools): Available free for Chrome and Firefox. More technical than WAVE but catches a wider range of issues. Use it alongside WAVE, not instead of it.
One more thing: you'll be navigating pages using only the keyboard for the keyboard navigation section. Have a page open in your browser before you start and know these keys: Tab moves forward through interactive elements, Shift+Tab moves backward, Enter activates buttons and links, Space activates checkboxes and scrolls, and the arrow keys move within components like dropdowns and radio groups.
Area 1: Heading structure
Why it matters
Screen reader users navigate pages primarily by heading. A common first step is pulling up a list of all headings on the page and using it as a table of contents to jump directly to the section they need. When headings are missing, out of order, or used for visual styling rather than document structure, this navigation method breaks completely. For sighted users, headings also provide the visual hierarchy that lets someone scan a page and decide whether to read it.
What correct looks like
A page should have exactly one <h1>: the page title. Every major section gets an <h2>. Subsections within those get <h3>. You should never skip a level (jumping from <h1> to <h3> with no <h2> in between) and you should never go back up to a higher level in the middle of a section without that section ending.
Read your headings as an outline. If you removed all the body text and read only the headings, would you have a clear, logical summary of the page's content? That's the test.
How to check
In WAVE, click the Structure tab in the sidebar. It shows you every heading on the page in order with its level. Look for:
<h1>Before/after examples
Before: A service page with the headings "Welcome," "Services," "Contact," and two <h3> tags with no <h2> parents. A screen reader user pulling a heading list sees a flat, meaningless outline with a structural break.
After: <h1> "Building permit applications," <h2> "What you need before you apply," <h2> "How to submit your application," <h3> "Submitting online," <h3> "Submitting by mail," <h2> "After you submit." Clear, scannable, navigable.
Common CMS-specific trap
Many CMS editors let you choose heading styles from a dropdown. Editors sometimes pick heading levels based on visual size rather than hierarchy. A heading they want to look small gets marked up as <h4> even if it's a top-level section. Remind your team: choose heading level based on position in the document structure, not based on how large you want the text to appear.
Area 2: Image alt text
Why it matters
Screen readers announce images by reading their alt text. Without meaningful alt text, a blind user either hears a filename ("image001.jpg," "banner_hero_2024_final_v3.png") or nothing at all, depending on how the image was added. Neither communicates anything useful. For images that convey information (charts, diagrams, screenshots, photos of people identified by name), missing or inaccurate alt text is a complete barrier to that information.
What correct looks like
Every <img> element needs an alt attribute. What goes in the attribute depends on the image's purpose:
alt=""). This signals to screen readers that the image should be ignored. Do not leave the alt attribute out entirely; that's different from an empty value and some screen readers will announce the filename instead.How to check
In WAVE, red icons with an "!" mark images with missing alt text. Yellow icons mark images with suspicious alt text (very short, or matching common patterns like the filename). Click each icon to see the full alt text value.
For a faster scan across an entire site, WebAIM's WAVE API or a tool like Screaming Frog (free for up to 500 URLs) can pull all image alt values into a spreadsheet. A visual review of that spreadsheet catches patterns: images with no alt, images with alt text that's just the filename, images where the alt text is clearly copy-pasted from an adjacent caption.
Before/after examples
Before: <img src="staff-photo-2024.jpg" alt="staff photo"> — tells a screen reader user nothing about who is in the photo or why they should care.
After: <img src="staff-photo-2024.jpg" alt="Priya Mehta, Communications Manager, City of Burlington"> — provides the same information a sighted user gets from the caption.
Before: A donut chart image showing budget allocation with alt="Budget chart".
After: alt="Donut chart: 42% of the 2025 operating budget is allocated to transportation services, 28% to recreation, 18% to planning, and 12% to administration." — the key data is in the alt text, not hidden behind a visual.
Area 3: Color contrast
Why it matters
Approximately 1 in 12 men and 1 in 200 women have some form of color vision deficiency. Many older users have reduced contrast sensitivity. Users in bright outdoor environments or on low-quality screens also struggle with low-contrast text. WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). These are minimums, not targets.
What correct looks like
The contrast ratio is calculated between the foreground color (text) and the background color. A ratio of 21:1 is black on white, the maximum possible. A ratio of 1:1 is identical colors, invisible. The 4.5:1 requirement for normal text means the foreground needs to be significantly darker or lighter than the background. Light grey text on a white background is a common failure. Teal text on a green background is another. Placeholder text in form fields is a particularly common low-contrast offender.
Three other contrast rules that get overlooked:
How to check
Run the page through WAVE first. It flags contrast failures it can detect from CSS values. It misses contrast issues where colors are applied dynamically, via images, or with CSS gradients, so manual spot-checking with the Colour Contrast Analyser is still necessary.
Focus specifically on:
Before/after examples
Before: color: #767676 on a #ffffff background. Contrast ratio: 4.48:1. Fails WCAG AA by a fraction.
After: color: #696969 on #ffffff. Contrast ratio: 4.61:1. Passes.
Before: White button text on a medium blue (#4A90E2) background. Contrast ratio: 2.97:1. Fails.
After: White button text on a darker blue (#1a5ba8). Contrast ratio: 6.14:1. Passes comfortably.
A useful workflow: when the Colour Contrast Analyser fails a combination, use the built-in "Brightness" slider to find the minimum adjustment needed to pass. This keeps the visual intent close to the original design while meeting the threshold.
Area 4: Keyboard navigation
Why it matters
Not everyone uses a mouse. Users with motor impairments, users of switch access devices, power keyboard users, and screen reader users all navigate with the keyboard. If an interaction requires a mouse to complete, those users are blocked.
The keyboard navigation test is also one of the fastest ways to find focus management problems that automated tools miss entirely.
What correct looks like
Every interactive element on the page (links, buttons, form inputs, checkboxes, dropdowns, accordions, carousels, modal dialogs) must be reachable and operable using only the keyboard. The focus indicator (the visible outline showing which element is currently focused) must be visible at all times. The navigation order must follow a logical sequence matching the visual layout.
How to check
Close your mouse. Do not touch it again until you've finished this test.
Tab through the entire page from top to bottom. At each step, ask:
Before/after examples
Before: A custom dropdown menu built with <div> and <span> elements. When you Tab to it, focus appears to land on the container but pressing Enter does nothing. You cannot open the menu or select an option without a mouse.
After: The same dropdown rebuilt using <button> for the trigger and <ul role="listbox"> with role="option" for the items, with keyboard event handlers for arrow navigation and Escape to close. Full keyboard access, and the semantics are correct for screen readers too.
Before: A page with no skip navigation link. To reach the main content, a keyboard user must Tab through a navigation menu with 14 links, then a utility header with 5 links, before reaching the first heading on the page. On every single page load.
After: A visually hidden <a href="#main-content">Skip to main content</a> as the first focusable element in the document. It becomes visible when focused. One Tab press and Enter to skip directly to content.
Things to document, not just pass/fail
Note the position on the page where you lost track of focus. Note any interactive element you couldn't activate. Note whether the skip navigation link exists and whether it works. This documentation is more useful for remediation than a simple count of failures.
Area 5: Forms
Why it matters
Forms are where users accomplish tasks: registering for programs, submitting applications, paying fees, contacting the organization. They are also one of the highest-density sources of accessibility barriers on most websites. A form with unlabelled inputs, no error messaging, or poor keyboard support blocks task completion entirely. For many users, that means a phone call that didn't need to happen, or a task abandoned.
What correct looks like
Every input field must have a visible label that is programmatically associated with the field. The label must describe what to enter, not just what the field is called. Error messages must be specific, written in plain language, and programmatically associated with the field they describe (so screen readers announce them when focus moves to the field). Required fields must be marked in a way that doesn't rely on color alone. Instructions must appear before the form, not after.
How to check
Run WAVE on any page with a form. It flags:
<fieldset> and <legend>) for related inputs like radio button groupsThen test the form manually:
Before/after examples
Before: An input field with placeholder text "Email" instead of an associated label. The placeholder disappears when the user starts typing. Users who tab away and return have no visible indication of what the field is for. Screen readers may or may not read placeholder text depending on the implementation.
After: A visible <label for="email">Email address</label> directly above the input. Placeholder text (if present) provides an example value ("[email protected]"), not the field label. The association is explicit and persistent.
Before: A form that highlights errored fields in red with no text explanation. A user with deuteranopia (red-green color blindness) may not perceive the red highlight. A screen reader user gets no announcement.
After: Errored fields are marked with a red border AND an inline error message below the field ("Please enter a valid email address. For example: [email protected]"). The error message has role="alert" so screen readers announce it immediately without the user navigating to find it.
Area 6: PDF accessibility
Why it matters
PDFs are common on public sector and organizational websites: annual reports, forms, meeting agendas, applications. An inaccessible PDF is a document that a screen reader user either can't read at all or reads as a jumbled stream of characters with no structure. Many PDFs on government and municipal websites are image scans of printed documents. To a screen reader, these are entirely blank.
PDF accessibility is a separate discipline from web accessibility, but the basic checks are manageable without specialist knowledge.
How to check
Check 1: Is the text selectable? Open the PDF and try to select and copy a sentence of body text. If you can't, the PDF is an image scan and has no accessible text at all. The remediation is either re-creating the PDF from the original source file with accessibility settings enabled, or running it through OCR (optical character recognition) and then adding structure.
Check 2: Does it have a title? In Adobe Acrobat Reader, go to File > Properties > Description. The Title field should contain a meaningful document title. "Annual Report 2024" is correct. "Untitled" or blank is a failure. The title is what screen readers announce first when opening the document.
Check 3: Is the document language set? In Acrobat, go to File > Properties > Advanced. The Language field should be set to the document's primary language (English, French, etc.). This tells screen readers which language rules to apply for pronunciation.
Check 4: Does it have tags and reading order? Tagged PDFs have a document structure that defines reading order, headings, lists, and table structure for assistive technology. In Acrobat, go to View > Show/Hide > Navigation Panels > Tags. If the Tags panel is empty, the document has no tags. The free version of Adobe Acrobat Reader can display tags but cannot create or edit them. Creating tagged PDFs requires the source document to be exported correctly from Word, InDesign, or another authoring tool with accessibility options enabled.
Check 5: Do linked images have alt text? In a tagged PDF, images should have alt text assigned. In Acrobat Pro (paid), you can view and edit this. Without Acrobat Pro, the fastest approach is to re-export the PDF from the original source file with proper alt text added to images there.
The honest recommendation on PDFs
For documents that need to be frequently updated or that contain primarily text, replacing the PDF with an accessible web page is almost always the better solution. Web pages are easier to make accessible, easier to update, and more usable on mobile. Reserve PDFs for documents that genuinely need to be printed, signed, or preserved as a fixed record.
The severity framework: what to fix first
After running through all six areas, you'll likely have more issues than you can address at once. Use this four-level framework to prioritize.
Level 1: Complete barriers (fix immediately)
These prevent a user from accomplishing their task at all:
Level 2: Significant barriers (fix in the current sprint or content update)
These degrade the experience to the point where many users will fail or give up:
Level 3: Partial barriers (schedule for remediation)
These create meaningful friction but most users can work around them:
Level 4: Best practice gaps (address in the next design or content pass)
These don't block tasks but represent quality gaps:
<h3> used for visual styling in a section where it's technically correct but slightly more specific than neededA two-hour audit session plan
Here is a realistic session plan for auditing one high-traffic page:
| Time | Task |
|---|---|
| 0:00 – 0:15 | Run WAVE and axe DevTools. Screenshot all flagged issues. |
| 0:15 – 0:35 | Manual heading structure review. Document all headings in order. |
| 0:35 – 0:50 | Alt text review for all images on the page. |
| 0:50 – 1:10 | Colour Contrast Analyser spot-check on body text, links, buttons, and form fields. |
| 1:10 – 1:35 | Keyboard navigation walkthrough. Tab through the full page. Document every issue. |
| 1:35 – 1:50 | Form review (if the page has forms). Manual label and error message check. |
| 1:50 – 2:00 | Compile findings into the severity framework. Assign Level 1–4 to each issue. |
At the end of the session you have a prioritized, documented list. Not every issue fixed, but a clear, actionable picture of where to start and what to escalate to a developer.
Starting an accessibility audit and not sure how to handle what you find? Get in touch for a structured review that turns your findings into a remediation roadmap your whole team can work from.