Teams: Website Accessibility Checklist That Fixes High Impact Issues
This website accessibility checklist targets WCAG 2.2 Level AA, which is backward compatible with 2.1 AA, and treats the ADA’s web guidance as the governing legal reference. The first move, before you touch a single line of code, is to run an automated scan and follow it with a manual keyboard and screen reader pass on your most critical pages. That combination catches what tools alone miss.
TL;DR:
- Meeting WCAG 2.2 Level AA standards now ensures future compliance as it incorporates additional protections like focus visibility and larger touch targets.
- Start accessibility testing with an automated scan, then conduct manual keyboard and screen reader checks on high-traffic, critical pages such as checkout and contact forms.
- Ensure all images have meaningful alt text, color contrast ratios meet minimum thresholds, and multimedia content includes captions, transcripts, and audio descriptions.
- Confirm every interactive element is keyboard-operable, focus indicators are visible and unobstructed, and mobile touch targets meet minimum size requirements.
- Treat accessibility as an ongoing process, prioritizing high-impact fixes above all, and avoid relying solely on overlays or one-time audits for full legal and user experience compliance.
Table of Contents
Table of Contents
- How to Use This Website Accessibility Checklist
- Perceivable Checks: Text, Images, Color, and Alternatives
- Operable Checks: Keyboard, Focus, and Interactive Targets
- Understandable Checks: Language, Headings, and Predictable Behavior
- Robust Checks: Semantic HTML, ARIA, and Assistive Tech Compatibility
- Images and Media Accessibility Checks
- Forms and Custom Controls: Labels, Errors, and Verification
- Links, Navigation, and Semantic Structure
- What Does an Accessibility Audit Workflow Look Like?
- What Does tekrescue Bring to an Accessibility Engagement?
- The Checklist Is Not the Finish Line
- Get Your Site Audited and Fixed, Not Just Flagged
- Sources
- FAQ
How to Use This Website Accessibility Checklist
Treat this checklist as a working document, not a one-time audit you file away. WCAG 2.2 AA is the right target because it folds in every 2.1 AA criterion and adds newer protections like focus visibility and larger touch targets, so building to 2.2 now means you won’t have to redo the work when 2.2 supersedes 2.1 as the reference standard.
Start by sampling, not scanning everything at once. Pick your homepage, your most-visited product or service pages, your checkout or contact form, and any page with a PDF or video embed. That handful of pages usually reveals 80% of the patterns repeated across your entire site.
Prioritize in this order:
- Level A failures first. These block basic access entirely, not just convenience.
- High-traffic flows next. A broken checkout matters more than a forgotten footer link.
- Level AA polish after that, once the blockers are gone.
- Escalate to a full audit or an outside accessibility consultant when you find widespread ARIA misuse, a custom component library, or anything touching financial or medical data, since HIPAA-adjacent sites carry extra legal exposure.
Perceivable Checks: Text, Images, Color, and Alternatives
Perceivable is the first of the four WCAG principles, often shortened to POUR, and it governs whether people can actually detect your content in the first place, regardless of vision, hearing, or device.
Run through these on every representative page:
- Every informative image carries meaningful alt text that describes its purpose, not just its filename.
- Purely decorative images use a null (empty)
alt=""so screen readers skip them instead of announcing clutter. - Text and background colors meet a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, checked with a tool like WebAIM’s Contrast Checker or the axe browser extension.
- No instruction relies on color alone. “Fields in red are required” needs an icon, asterisk, or text label alongside the color.
- Every video includes captions, and a full transcript is available for anyone using a screen reader or reading in a noisy environment.
- Audio description gets added when a video conveys essential information visually that the audio track never mentions, like a silent product demo.
Text resizing matters more than most teams assume. Users need to zoom browser text up to 200% without content overlapping or getting clipped off screen, per the ADA’s guidance on assistive technology compatibility.
Pro Tip: Don’t write alt text like “image123.jpg” or stuff it with keywords for SEO. Screen reader users hear that text read aloud verbatim, so write it the way you’d describe the image out loud to a colleague on the phone. If you’re rebuilding image pipelines anyway, optimizing images for speed is a natural companion project to fixing alt text at the same time.
Operable Checks: Keyboard, Focus, and Interactive Targets
Operable means every interactive element works without a mouse. Unplug your mouse for ten minutes and try to complete your own checkout flow using only Tab, Shift+Tab, and Enter. Most teams discover their first real bug within sixty seconds of trying this.
Confirm the following:
- Every link, button, form field, and custom widget is reachable and usable with the keyboard alone.
- Focus never gets trapped inside a modal, dropdown, or widget with no way out except a browser refresh.
- A visible focus indicator, usually an outline or highlight, appears on whatever element currently has keyboard focus, and that indicator is never hidden behind a sticky header or overlay (a WCAG 2.2 addition called focus-not-obscured).
- Touch targets on mobile meet at least 24 by 24 pixels of spacing, so a thumb doesn’t accidentally tap the wrong icon on a cluttered toolbar.
- Any drag-and-drop interaction, like reordering a list or adjusting a slider, offers a non-drag alternative such as up and down buttons.
Skip navigation matters here too. A visible or focus-activated “skip to main content” link saves keyboard users from tabbing through twenty header links on every single page load. It’s a small fix that pays off on every page view, not just once.
Understandable Checks: Language, Headings, and Predictable Behavior
Understandable checks make sure content behaves the way a reasonable person expects it to, and that assistive technology can correctly interpret what language it’s even reading.
Work through these:
- Set the
langattribute on the<html>element (lang="en", for example) so screen readers pick the correct pronunciation engine automatically. - Mark any inline language shift, such as a French phrase in an otherwise English paragraph, with its own
langattribute. - Structure headings in logical order (H1, then H2, then H3) rather than skipping levels or choosing heading tags for their visual size.
- Write headings that describe the section’s actual content, not vague labels like “More Info.”
- Give every form field a visible label, not just a placeholder that disappears the moment someone starts typing.
- Write instructions before a form field is needed, and write error messages that name the specific problem and suggest a fix, like “Phone number must include an area code” rather than “Invalid input.”
- Keep help text, chat widgets, and navigation in the same place across your site so users build a reliable mental map instead of hunting for controls that moved.
Avoid unexpected context changes, too. A form that submits and jumps to an unrelated page without warning, or a dropdown that reloads the whole page on selection, breaks the predictability people depend on.
Robust Checks: Semantic HTML, ARIA, and Assistive Tech Compatibility
Robust is the principle developers own most directly: does your code hold up when parsed by browsers, screen readers, and voice control software your team never tested against?
The rule that saves the most rework: prefer native HTML elements over custom-built ones. A <button> element comes with keyboard support, focus handling, and screen reader announcements built in for free. A <div> styled to look like a button requires you to manually rebuild all of that with ARIA and JavaScript, and it’s easy to miss a state.
- Use ARIA roles and properties only when native HTML can’t do the job, and never as a substitute for actual semantic markup.
- Validate your HTML against the W3C validator; broken markup can silently break how assistive technology parses the page.
- Test with at least one major screen reader (NVDA or JAWS on Windows, VoiceOver on Mac) paired with a major browser, since rendering differences between combinations are common.
- Document any workaround or fallback behavior your team builds, so the next developer doesn’t accidentally strip it out during a redesign.
Images and Media Accessibility Checks
Images and media deserve their own pass beyond the general perceivable checks, because video and audio content introduce failure points that static images don’t.
- Write alt text that conveys the image’s purpose in context; a product photo needs different alt text on a listing page than in a size-comparison chart.
- Mark decorative images with a null
alt=""attribute so they’re skipped entirely by assistive technology. - Add synchronized captions to every video, and publish a full transcript alongside it for anyone who can’t or doesn’t want to play audio.
- Provide audio description for videos where visual-only content carries meaning the narration never states aloud.
- Choose or build a media player where play, pause, volume, and caption toggles are all keyboard operable and properly labeled for screen readers, not just clickable icons with no accessible name.
Forms and Custom Controls: Labels, Errors, and Verification
Forms are where accessibility failures cost the most, because a broken form doesn’t just annoy someone, it blocks them from completing a purchase, a booking, or a support request entirely.
- Every input needs both a programmatic name (via a
<label>element tied to the field) and a visible label a sighted user can read. - When a field fails validation, announce the error through both visual styling and text, and programmatically link that error message to its field so screen readers announce it in context.
- Write corrective instructions in every error message. “This field is required” is weaker than “Enter your email address in the format name@example.com.”
- Never deploy a CAPTCHA without an accessible alternative, such as an audio challenge or a logic question, since visual-only CAPTCHAs lock out screen reader users completely.
- Build custom widgets like date pickers or multi-select dropdowns with correct ARIA states (
aria-expanded,aria-selected) that update as the user interacts, and confirm they’re fully keyboard operable before shipping.
Links, Navigation, and Semantic Structure
Descriptive links and clean structure are what let people scan a page instead of reading every word of it, which matters even more for someone navigating by screen reader shortcuts.
- Write link text that describes the destination on its own. “Read our accessibility guide” beats “click here” every time, especially for screen reader users who often pull up a page’s link list separately from the surrounding text.
- Add a skip link near the top of every page, along with proper landmark regions (
<nav>,<main>,<footer>) so assistive technology users can jump straight to content. - Give data tables proper
<th>header cells with ascopeattribute, and never use a table purely for visual layout. - Group related items in semantic
<ul>or<ol>lists rather than a stack of styled paragraphs, so screen readers announce “list of five items” instead of five disconnected lines. - Keep navigation menus, search bars, and footers consistent across the site so users build confidence in where to find things.
A usability checklist built around these page-level items works well as a template for content teams doing recurring reviews, not just developers doing one-time builds.
What Does an Accessibility Audit Workflow Look Like?
A working audit moves through four stages, and skipping any one of them is where most remediation efforts quietly fail.
- Automated scan first. Tools like axe, WAVE, or Lighthouse catch machine-detectable failures fast: missing alt attributes, insufficient contrast, empty form labels. But automated tools cannot judge whether alt text is meaningful or whether navigation actually makes sense, so treat this as a first pass, not a finish line.
- Manual and assistive-technology testing next. Run keyboard-only navigation and a screen reader pass on the representative flows you scoped earlier: homepage, checkout, contact form, any embedded media.
- User testing where possible. Including people who actually rely on assistive technology in usability sessions surfaces friction that even a trained tester might miss.
- Document, prioritize, and re-test. Log every issue with its WCAG criterion, fix Level A failures first, then re-scan after remediation and set up ongoing monitoring so new content doesn’t reintroduce old problems.
A structured audit that scopes representative pages and prioritizes by severity consistently outperforms an ad hoc “fix what we notice” approach, mostly because it catches the flows nobody thought to check.
Pro Tip: Screenshot or screen-record every failure you find during manual testing, even minor ones. Six months later, when someone asks “didn’t we fix this already,” you’ll have proof instead of a guess.
What Does tekrescue Bring to an Accessibility Engagement?
Checklists tell you what’s broken. Fixing it at scale, and keeping it fixed as your site grows, is a different job. tekrescue runs accessibility work as a structured engagement, not a one-off scan:
- Scoped audits combining automated scanning with manual keyboard and screen reader verification on your priority flows.
- A prioritized remediation backlog, sequenced by severity, so Level A blockers get fixed before cosmetic AA polish.
- Verification testing after fixes ship, confirming the issue is actually resolved rather than just hidden.
- Ongoing monitoring so a new page or template doesn’t quietly reintroduce old failures.
- Team training so your content editors and developers stop creating the same accessibility bugs on every new page.
One warning worth repeating: an accessibility overlay widget bolted onto your existing site is not a substitute for this work. Overlays adjust surface-level styling but leave underlying markup, keyboard traps, and broken forms untouched, and they’ve become a common target in ADA-related legal complaints precisely because they promise a shortcut that doesn’t exist.
The Checklist Is Not the Finish Line
Here’s what most teams get wrong: they treat an accessibility checklist as a project with an end date instead of a standard they maintain. Fix the highest-impact, lowest-effort items first, things like alt text, contrast, and keyboard traps, because that’s where you get the most protection for the least engineering time.
Then build a process. A new landing page shipped without a contrast check next quarter undoes this quarter’s audit. Accessibility holds up only when it’s treated as ongoing product quality work, the same way you’d treat page speed or broken links, not as a checklist you close out once and file away.
— Randy Bryan
Get Your Site Audited and Fixed, Not Just Flagged
tekrescue is the alternative to a generic automated scan report that leaves you a spreadsheet of errors and no plan to fix them. Where a scan-only tool hands you a list, tekrescue’s team runs the full sequence: a scoped audit combining automated and manual testing, a prioritized remediation backlog your developers can actually work from, verification after fixes ship, and ongoing monitoring so new pages don’t quietly break what you already fixed.
This matters most for healthcare practices, financial services firms, and any small or medium-sized business facing real ADA exposure, since compliance and web design go hand in hand when your site is rebuilt or restructured. If your team is already planning a redesign, tekrescue’s web design process folds accessibility remediation into that build instead of treating it as a separate project down the line. Reach out for a scoped audit and a prioritized fix list you can actually execute against.
Sources
- ADA: Web Guidance and Resources
- WCAG 2.2 checklist & quick reference | Inclusense
- Strengths and limits of automated accessibility testing | WAVE Training (UMN Duluth)
- A step-by-step guide to conducting a web accessibility audit | UsableNet blog
- Basic Accessibility Checklist | Digital Accessibility (MSU)
FAQ
What Are the Four Principles of Web Accessibility?
WCAG organizes every success criterion under four principles, known as POUR: perceivable, operable, understandable, and robust. Content has to satisfy all four to be genuinely accessible, not just one or two.
How Do You Check if a Website Is Accessible?
Run an automated scan with a tool like axe or WAVE to catch machine-detectable issues, then follow up with manual keyboard-only navigation and a screen reader pass on your priority pages, since automated tools alone can’t judge whether alt text or navigation actually make sense.
How Can I Make Sure My Website Is Accessible?
Work through a structured checklist covering images, contrast, keyboard operability, forms, and semantic structure, then verify with both automated scanning and manual assistive-technology testing. tekrescue’s audit and remediation process follows this exact sequence for clients who need ongoing compliance, not a one-time fix.
What Are the Four Guidelines of WCAG?
WCAG’s guidelines fall under the same four POUR principles: perceivable, operable, understandable, and robust, each broken into specific testable success criteria at Level A, AA, and AAA.
Is WCAG 2.1 or 2.2 the Right Target?
Target WCAG 2.2 AA, since it’s backward compatible with 2.1 AA and adds newer protections like focus visibility and minimum touch target size, meaning you get full 2.1 coverage plus a more future-proof standard.
Recommended
Table of Contents
