Website Accessibility Demand Letter: A Developer's WCAG Verification Workflow

A practical workflow for turning accessibility allegations into scoped tests, traceable WCAG findings, remediation tickets, and verified retest evidence.

When a business receives a website accessibility demand letter, the development team's first instinct is often to start fixing everything immediately.

That reaction is understandable. It can also make the technical record harder to explain.

If the website changes before anyone records the relevant page, component, environment, and observed behavior, the team may later struggle to answer basic questions:

• Which barrier was actually alleged?
• Could the team reproduce it?
• Which website version was tested?
• Was the issue isolated or part of a shared component?
• What evidence supported the finding?
• What changed during remediation?
• Was the original behavior retested?
• Did the fix create a regression elsewhere?

The useful engineering response is not "run a scanner and make the score green." It is to turn each material allegation into a scoped, reproducible accessibility test and maintain traceability from the original observation through the final retest.

This guide explains that workflow for developers, QA engineers, product teams, accessibility reviewers, agencies, and technical leaders.

Technical scope note: This is a technical accessibility workflow, not legal advice. A technical reviewer can document observable behavior, WCAG-oriented findings, supporting evidence, remediation guidance, and retest results within a defined scope. Qualified counsel should handle legal interpretation, deadlines, preservation instructions, privilege, response strategy, and questions about whether a law applies.

Table of Contents

• 1. Separate the Legal Question From the Technical Question
• 2. Record the Current Website State Before Material Changes
• 3. Translate Allegations Into Testable Questions
• 4. Define Scope Before Testing
• 5. Use Several Testing Methods, Not One Tool
• 6. Separate Candidates From Verified Findings
• 7. Build a Traceable Finding Record
• 8. Convert Findings Into Developer-Ready Remediation Tickets
• 9. Retest the Behavior and Check for Regressions
• 10. Organize the Evidence Package
• 11. A Practical Technical Review Checklist
• 12. Common Questions
• Official References

1. Separate the Legal Question From the Technical Question

A demand letter is a source of allegations and review questions. From an engineering perspective, it is not a substitute for testing.

It may identify a page, user journey, claimed barrier, assistive technology, input method, WCAG success criterion, screenshot, recording, scanner result, or time period.

It does not automatically establish:

• That the current page is identical to the version originally reviewed
• That the behavior occurs in every browser, device, or assistive technology
• That every cited WCAG criterion is technically applicable
• That a scanner covered the complete user journey
• That one issue affects every page built from a similar template
• That a current test proves historical behavior
• That WCAG conformance or nonconformance decides a legal claim
• That a violation, liability, damages, or remedy exists

The technical team should focus on questions it can actually investigate:

• Does the cited page still exist?
• Can the alleged barrier be reproduced?
• Under which browser, viewport, input method, and assistive-technology conditions?
• Which user task is affected?
• Is the issue isolated, repeated, or systemic?
• Which source component, content item, design token, CMS template, or vendor integration controls the behavior?
• Which technical requirement is relevant?
• What evidence supports the observation?
• How should the change be verified after implementation?

Counsel determines what those facts mean for the matter. The technical reviewer establishes what was observed within the defined scope.

2. Record the Current Website State Before Material Changes

Websites change constantly. A deployment, theme update, content edit, feature flag, plugin release, third-party widget update, or emergency patch can change what a later reviewer observes.

Where appropriate and under the organization's and counsel's direction, record the current technical context before making material changes:

• Production URL
• Date, time, and time zone
• Release, deployment, build, theme, or application version
• Relevant CMS and plugin versions
• Browser and operating system
• Viewport or device profile
• Logged-in or logged-out state
• Language and locale
• Accessibility tool and version
• Assistive technology and version, where used
• Tested pages, templates, components, states, and journeys
• Relevant screenshots, recordings, DOM extracts, or test notes

Keep the supplied letter and attachments in their original form. Do not annotate, crop, rename, or overwrite the only copy. Use separate working copies for technical analysis.

A current-state capture is still only a record of the website during the current review. It does not automatically prove what the website did weeks or months earlier.

The practical engineering sequence is:

1. Record relevant current-state context.
2. Reproduce and document the alleged behavior.
3. Identify the affected source component or content.
4. Implement a controlled change.
5. Retest the original behavior.
6. Check related components and complete journeys for regression.
7. Keep the before-and-after records connected but distinct.

3. Translate Allegations Into Testable Questions

"The website is inaccessible" is not a test case.

Neither is "make the website ADA compliant" an actionable development ticket.

Start with the allegation and break it into observable behavior.

This workflow produces much better information than a generic full-site score because it connects the reported experience to a page, component, environment, user task, and expected behavior.

4. Define Scope Before Testing

Scope controls what the evidence can support.

A focused review with clear boundaries is more trustworthy than a broad conclusion built on unclear testing.

W3C's Website Accessibility Conformance Evaluation Methodology begins by defining the evaluation scope, exploring the target, and selecting a representative sample when every page or view cannot be evaluated.

Identify the Digital Assets

Confirm which assets are included:

• Public website
• Authenticated account area
• Web application
• Mobile web experience
• Native mobile application
• Documents and PDFs
• Embedded third-party services
• Videos and audio
• Chat, maps, booking, scheduling, or payment tools
• Downloadable resources

A website audit does not automatically include a native application, PDF library, authenticated portal, vendor-hosted service, or email template.

Select Representative Pages and Components

A useful sample may include:

• Homepage and primary navigation
• Header, footer, and repeated landmarks
• Product, service, property, or content templates
• Category, search, and filter interfaces
• Registration, login, and account recovery
• Contact, inquiry, or lead-generation forms
• Cart, checkout, booking, or scheduling
• Error states and validation
• Articles and downloadable resources
• Reusable dialogs, menus, tabs, accordions, carousels, cards, and data tables

Do not sample only by URL count.

Ten URLs built from one template may reveal less than five carefully selected pages covering five distinct components or journeys.

Include Complete User Processes

Testing one screen in a multi-step flow can miss the barrier that prevents completion.

Examples of complete processes include:

• Search to product to checkout
• Property search to inquiry submission
• Registration to email verification to login
• Appointment selection to confirmation
• Job search to application submission
• Donation selection to payment confirmation
• Password reset to restored account access

W3C's Understanding Conformance explains why complete processes matter when multiple pages are required to accomplish an activity.

Define Test Environments

"Screen-reader tested" is too vague to reproduce.

Record:

• Operating system and version
• Browser and version
• Screen reader and version
• Desktop or mobile device
• Viewport dimensions and zoom level
• Keyboard-only or other input method
• Touch orientation
• Language and locale
• Authentication state
• Settings or extensions that affect behavior
• Website version and test date

One browser and assistive-technology combination cannot represent every user.

Report what was tested and what was not.

State Material Exclusions

Examples include:

• PDFs were not reviewed
• The authenticated area was unavailable
• Payment was not completed
• Native mobile apps were excluded
• Only desktop web was reviewed
• Source-code access was not provided
• Third-party content was reviewed only at the user-facing layer
• Historical builds were unavailable
• User research with people with disabilities was not part of the engagement

Explicit exclusions prevent a scoped review from being misread as a whole-organization accessibility certification.

5. Use Several Testing Methods, Not One Tool

Automated tools are useful, but they do not evaluate accessibility by themselves.

W3C's guidance on selecting accessibility evaluation tools explains that human judgment remains necessary.

A practical review usually combines several methods.

Automated Candidate Discovery

Automated tools can efficiently identify some machine-testable patterns:

• Missing attributes
• Certain accessible-name problems
• Some color-contrast failures
• Form-control association issues
• Empty headings or links
• Document-language signals
• Some landmark and heading observations
• Certain ARIA problems

Treat the result as a candidate until its page context, user impact, technical mapping, and recurrence have been reviewed.

A tool may confirm that an image has an alt attribute. It may not determine whether that text communicates the image's purpose in context.

It may identify a button name but not whether focus moves correctly after the button opens a dialog.

Keyboard-Only Review

Test whether a keyboard user can:

• Reach interactive elements
• See where focus is located
• Follow a logical focus order
• Operate menus, dialogs, tabs, accordions, carousels, and custom controls
• Avoid keyboard traps
• Skip repeated content where applicable
• Complete forms
• Dismiss overlays
• Reach validation messages
• Finish complete user processes

For material findings, record the exact keystrokes and observed result.

Screen-Reader Review

Depending on scope, review:

• Page title and language
• Heading structure and landmarks
• Link and button names
• Form labels, instructions, descriptions, and errors
• Names, roles, values, and states
• Focus and dialog announcements
• Dynamic status messages
• Tables
• Alternative text
• Reading and navigation order

Record the screen reader, browser, versions, commands, user task, expected behavior, actual behavior, and known limitation.

Zoom, Text Resize, and Responsive Reflow

Check for:

• Clipped or overlapping content
• Lost information or functionality
• Controls hidden at narrow widths
• Truncated instructions
• Sticky elements obscuring content or focus
• Menus that cannot be opened or dismissed
• Forms that become unusable

Color and Non-Color Cues

Review:

• Text contrast
• Non-text contrast for meaningful controls and states
• Focus indicators
• Error identification
• Selected and unselected states
• Required-field communication
• Charts, maps, or instructions that rely only on color

A sampled color value should be tied to the actual foreground, background, component, and state being evaluated.

DOM and Accessibility-Tree Inspection

Visual behavior does not show everything assistive technology receives.

Inspect:

• Native semantics
• Accessible names and descriptions
• ARIA roles, properties, and states
• Label relationships
• Headings and landmarks
• DOM order
• Hidden and exposed content
• Live regions
• Focus movement
• Disabled states
• Invalid nested interactions

ARIA is not a replacement for correct native semantics and operable behavior.

Forms, Instructions, and Errors

Forms frequently require manual review.

Check:

• Programmatic labels
• Persistent visible labels where needed
• Required-field communication
• Input purpose
• Instructions provided before users need them
• Group labels for related controls
• Error identification
• Error association
• Suggestions for correction
• Focus placement after submission
• Status announcements
• Multi-step form progress
• Session timeouts
• Accessible authentication

A placeholder is not always an adequate replacement for a persistent label.

Names, Roles, Values, and States

Custom controls may look operable while exposing incomplete or misleading information programmatically.

Review:

• Button and link names
• Expanded and collapsed states
• Selected states
• Checked and unchecked states
• Dialog names
• Tab relationships
• Combobox state and options
• Slider values
• Validation state
• Disabled state
• Live updates

Images and Non-Text Content

The correct treatment depends on the image's purpose:

• Informative images need an equivalent appropriate to context.
• Functional images need a name describing the action or destination.
• Decorative images should generally be ignored by assistive technology.
• Complex images may require a longer explanation. -- Text embedded in images may create additional barriers.

The presence or absence of an alt attribute does not complete the evaluation.

Dynamic Components

Manually operate:

• Dialogs
• Carousels
• Accordions
• Tabs
• Autocomplete fields
• Date pickers
• Infinite-scroll interfaces
• Toast notifications
• Chat widgets
• Cookie banners
• Embedded maps
• Video players
• Virtualized tables and lists

Test opening, operation, state changes, focus, announcements, closing, and recovery.

Third-Party Components

A website owner may not control the source code of a payment form, booking engine, property-search tool, map, chat service, or embedded document viewer.

The user-facing barrier can still affect the website journey.

For third-party services, record:

• Vendor and component
• Page and task
• User-facing failure
• Frame or embed boundary
• Available configuration
• Internal owner
• Vendor escalation path
• Workaround, if any
• Retest dependency
• Limitation caused by lack of source access

"Third party" explains ownership. It does not erase the user-facing barrier.

Documents and PDFs

If documents are included, review them separately.

Relevant areas may include:

• Tags and document structure
• Reading order
• Document title and language
• Headings
• Lists
• Tables
• Alternative text
• Link purpose
• Form fields
• Instructions
• Color contrast
• Security settings that affect assistive technology

A web-page audit does not automatically establish document accessibility.

6. Separate Candidates From Verified Findings

Do not force every tool alert into "pass" or "violation."

Use result types that communicate the actual state of the review.

Verified Technical Finding

The reviewer reproduced the issue under documented conditions and connected it to inspectable evidence and an applicable technical requirement.

Candidate Issue

A tool or preliminary check surfaced a signal that still requires manual verification or more context.

Inconclusive Observation

The reviewer could not confirm or exclude the issue because of missing access, dynamic behavior, inconsistent results, unavailable historical context, third-party limitations, or insufficient evidence.

Best-Practice or Usability Observation

The behavior may warrant improvement, but the available evidence does not support reporting it as a failure of the cited WCAG success criterion.

Not Reproduced in the Defined Test

The issue was not observed under the documented conditions.

This does not prove it never occurred in another build, browser, device, state, assistive technology, or period.

This classification is more honest, more useful to developers, and easier to defend during retesting than a flat scanner export.

7. Build a Traceable Finding Record

Every material finding should be understandable without asking the original tester to reconstruct it from memory.

At minimum, record:

• Finding ID and descriptive title
• Reviewed URL or view
• Component, template, or journey
• User task
• Test environment
• Input method or assistive technology
• Steps to reproduce
• Expected behavior
• Observed behavior
• User impact
• Relevant WCAG success criterion and level
• Supporting evidence IDs
• Recurrence or affected instances
• Technical severity
• Remediation owner and direction
• Retest method
• Limitation
• Status

Here is an illustrative record that could be stored as YAML, JSON, or a structured issue in the team's tracker:

id: A11Y-KB-04
title: Focus moves behind the open gallery modal

location:
  page: Property detail template
  component: Image gallery modal
  recurrence: Shared component on reviewed property templates

environment:
  operating_system: Windows 11
  browser: Chrome 151
  input_method: Keyboard only
  viewport: 1440 x 900

user_task: Open the gallery, move through the images, and close the modal

steps:
  - Navigate to the View gallery button with Tab
  - Press Enter
  - Continue pressing Tab through the modal controls
  - Press Escape to close the modal

observed_behavior: >
  Focus moved behind the open gallery and reached page links that were
  visually obscured. After Escape, focus returned to the start of the
  document instead of the control that opened the modal.

expected_behavior: >
  Focus remains within the active modal while it is open. All modal controls
  are keyboard operable, and focus returns to a logical location after close.

evidence:
  - SCR-A11Y-014
  - VID-A11Y-006
  - DOM-A11Y-009

technical_mapping:
  baseline: WCAG 2.2 AA
  review_areas:
    - Keyboard access
    - Focus order
    - Focus visibility
    - Component semantics

limitation: >
  This observation applies to the listed component version, browser,
  viewport, input method, and test period. Other assistive-technology
  combinations were not tested for this finding.

legal_conclusion: Not provided; reserved for qualified counsel

Notice what this record does not say.

It does not call the site "ADA compliant" or "noncompliant."

It describes a reproducible behavior, the technical review areas, the evidence, the affected component, and the limits of the observation.

8. Convert Findings Into Developer-Ready Remediation Tickets

A finding report is not yet an implementation plan.

First identify the layer that controls the issue:

• Content
• HTML semantics
• CSS
• JavaScript interaction
• Component library
• Design-system token
• CMS template
• Authoring workflow
• Third-party vendor
• Document-generation process
• Product requirement

Then group repeated instances by source.

Fixing a shared card component is usually better than editing 40 repeated cards.

Updating the modal pattern is better than patching a single popup.

Correcting CMS heading rules is better than manually repairing each article.

Define acceptance criteria before implementation.

A useful ticket can look like this:

ticket: WEB-2841
finding: A11Y-KB-04
owner: Frontend platform team
component: GalleryModal

required_behavior:
  - Move focus to the modal when it opens
  - Keep keyboard focus within the active modal
  - Allow every modal control to be operated from the keyboard
  - Close the modal with its visible close control and Escape
  - Return focus to the control that opened the modal
  - Prevent background content from being exposed as active modal content

test_matrix:
  - Windows 11, Chrome 151, keyboard only
  - Windows 11, Chrome 151, NVDA
  - macOS, Safari, VoiceOver

regression_areas:
  - Image navigation
  - Close control
  - Page scroll position
  - Property card links behind the modal
  - Other dialogs using the shared focus utility

closure_evidence:
  - Pull request or changed version
  - Keyboard retest notes
  - Screen-reader retest notes
  - Updated recording
  - Final retest status linked to A11Y-KB-04

This is actionable.

"Make the modal ADA compliant" is not.

Do not treat the presence of an overlay, plugin, widget, automated service, monitoring platform, or theme feature as proof that a verified barrier was fixed.

The relevant technical question is:

Can a user complete the defined task under the documented test conditions, and does the reviewed component meet the agreed accessibility requirement?

9. Retest the Behavior and Check for Regressions

A merged pull request or completed ticket is not a verified fix.

Retest the original finding using the recorded:

• Page or representative template
• Component
• User task
• Steps
• Browser and viewport
• Input method
• Assistive technology, where relevant
• Expected result

Record the changed version and any environment differences.

Then test beyond the exact line of code that changed.

Accessibility fixes can create new problems:

• Focus containment can make a modal impossible to close.
• Changing a button to a link can alter keyboard behavior.
• Visually hiding text can accidentally remove it from the accessibility tree.
• Adding ARIA can override correct native semantics.
• Increasing contrast can remove a selected-state distinction.
• Changing DOM order can affect visual order or reading sequence.

Use retest statuses that state what actually happened:

• Verified resolved
• Partially resolved
• Not resolved
• Could not retest
• Regression identified
• No longer present because the page or component was removed
• Accepted limitation or deferred item, as determined by the responsible team

Maintain one connected traceability chain:

Original finding
  -> supporting evidence
  -> remediation ticket
  -> changed version
  -> retest evidence
  -> final status

This record is useful to developers, product owners, accessibility teams, business leaders, and counsel.

It still does not guarantee legal compliance or accessibility for every person and environment.

10. Organize the Evidence Package

Screenshots alone are rarely enough.

Many accessibility barriers involve interaction, focus movement, announcements, programmatic semantics, or responsive changes that a static image cannot fully explain.

Depending on the finding, useful evidence may include:

• Full-page or component screenshot
• Annotated working screenshot
• Short screen recording
• Keyboard interaction notes
• Screen-reader transcript or tester notes
• Accessibility-tree extract
• DOM or code extract
• Color measurement
• Automated-tool result
• Reflow comparison
• Form-submission and error sequence
• Component inventory
• Affected-page list

Label Evidence Correctly

Use clear distinctions:

• Original capture: Preserved after collection without silently overwriting it.
• Working copy: Used for cropping, annotation, comparison, or analysis.
• Report extract: Selected to explain a finding.
• Redacted copy: Modified to remove sensitive or identifying information.

Do not describe an annotated, cropped, converted, or redacted file as identical to the original.

Protect Sensitive Information

Accessibility evidence may expose:

• Account details
• Email addresses
• Form values
• Internal URLs
• Authentication state
• Health, employment, financial, or property information
• Legal correspondence
• User recordings
• Client-identifying details

Use appropriate access controls, secure transfer, data minimization, redaction, retention instructions, and authorized-recipient lists.

Counsel and the responsible organization should determine legal-hold, privilege, work-product, and disclosure requirements.

Executive Summary

A structured evidence package may include:

• Reviewed assets and testing period
• Technical baseline
• Main user journeys
• Verified-finding summary
• Systemic patterns
• Priority themes
• Important limitations

Scope and Methodology

Document:

• Domains and digital assets
• Pages, templates, and complete processes
• Browsers, devices, and assistive technologies
• Automated and manual methods
• Sampling approach
• Exclusions

Findings Register

Include:

• Finding IDs
• Affected pages and components
• Steps, expected behavior, and observed behavior
• WCAG-oriented mapping
• Evidence references
• Severity and recurrence
• Remediation owner
• Limitations

Remediation Roadmap

Organize:

• Core-journey blockers
• Shared-component changes
• Content corrections
• Design-system changes
• Vendor dependencies
• Document work
• Retest sequence

Retest Report

Document:

• Original finding reference
• Remediated version
• Retest environment
• Evidence
• Result
• Remaining limitations
• Regression notes

You can review an example structure in Auditzo's sample ADA/WCAG accessibility evidence report.

A Real Review: 7 Pages and 29 Verified Findings

Auditzo completed an evidence-backed review of a Wix-based real-estate website covering seven representative pages and important inquiry journeys.

Automated tools supported candidate discovery, but the final report included only manually reviewed findings.

The engagement documented 29 verified findings involving:

• Accessible names
• Keyboard focus
• Persistent form labels
• Heading hierarchy
• Link purpose
• Embedded widgets
• Responsive reflow
• Visual contrast
• Non-text content

The findings were organized by severity, user impact, recurrence, and remediation ownership.

That separated:

• Shared template and component fixes
• Page-specific content changes
• Wix-configurable items
• Third-party widget dependencies
• Retesting priorities

This was not represented as a demand-letter engagement.

It is relevant because it shows the same engineering workflow moving from pages and journeys to verified findings, ownership, remediation, and retesting.

Read the complete real-estate website accessibility evidence review case study.

11. A Practical Technical Review Checklist

Supplied Materials and Current State

• Preserve the original supplied files and keep working copies separate.
• List every cited URL, component, criterion, and user experience.
• Record the production URL, review date, and website version.
• Identify recent material changes.
• Document browser, operating system, viewport, language, and authentication state.
• Keep current-state observations separate from historical claims.

Scope

• Identify websites, apps, documents, authenticated areas, and third-party components.
• Select representative pages and templates.
• Include relevant complete user processes.
• Define the WCAG version and level used as the technical baseline.
• Define browsers, devices, input methods, and assistive technologies.
• State exclusions and access limitations.

Testing

• Use automated tools for candidate discovery, not as final conclusions.
• Perform keyboard review.
• Perform screen-reader review where relevant to scope.
• Review zoom, text resize, and responsive reflow.
• Review forms, errors, instructions, and status messages.
• Review navigation, focus, dialogs, and dynamic components.
• Review names, roles, values, states, links, images, color, and structure.
• Review documents and third-party components separately where included.

Findings and Evidence

• Assign a stable finding ID.
• Connect the finding to its page, component, environment, and task.
• Record steps, expected behavior, and observed behavior.
• Link screenshots, recordings, code extracts, tool results, or tester notes.
• Distinguish original, working, redacted, and report copies.
• Protect sensitive information.
• State the limitations.

Remediation and Retesting

• Identify content, code, design-system, CMS, or vendor ownership.
• Group repeated issues by their source component.
• Write testable acceptance criteria.
• Prioritize core-journey barriers and systemic fixes.
• Keep vendor-dependent items visible.
• Retest the original steps on the changed version.
• Check related components and complete journeys for regression.
• Link retest evidence and final status to the original finding.

Boundaries

• Keep technical observations separate from legal conclusions.
• Do not call a scoped review an ADA or WCAG certification.
• Do not generalize one test combination to every user.
• Do not use a current audit as automatic proof of historical behavior.
• Route legal strategy, deadlines, preservation, privilege, and response decisions to qualified counsel.

12. Common Questions

Is an Automated Accessibility Scan Enough?

No automated tool can evaluate every aspect of accessibility.

Tools can discover candidates and confirm some machine-testable conditions. Manual review is still needed for areas such as keyboard interaction, focus management, meaningful alternative text, form usability, status announcements, complete processes, and many screen-reader behaviors.

Does Passing an Automated Scan Prove the Website Is Accessible?

No.

It means the tool did not detect certain configured, machine-testable issues during that scan.

It does not establish full WCAG conformance, accessibility for every user, or legal compliance.

Is WCAG 2.2 AA Automatically the Legal Standard for Every Business?

No.

WCAG 2.2 AA is a useful technical accessibility baseline.

The applicable legal standard, version, level, jurisdiction, contract, regulation, or settlement requirement is matter-specific and should be evaluated by qualified counsel.

Can a Current Audit Prove What the Website Did Months Ago?

Not automatically.

A current audit documents the website during the current test.

Historical reconstruction may require:

• Archived builds
• Version-control history
• Deployment records
• CMS revisions
• Earlier reports
• Screenshots or recordings
• Issue-tracker records
• Vendor release history
• Other timestamped material

If an earlier version cannot be reconstructed, say so clearly.

Do not present current behavior as proof of historical behavior.

How Many Pages Should Be Tested?

The answer depends on:

• Allegations
• Website architecture
• Unique templates
• Shared components
• Third-party tools
• Authenticated areas
• Important user journeys
• Material page states

Testing the homepage alone is rarely representative of a complex site.

Select the sample by unique template, component, state, and process, not only by URL count.

Does Every Audit Need Screen-Reader Testing?

The method should match the technical questions and agreed scope.

Screen-reader review is important for many semantic, form, navigation, dynamic-content, and interaction issues.

The report should identify the screen reader, browser, versions, commands, and limitations rather than simply saying "screen-reader compatible."

Does Every Review Need User Testing With People With Disabilities?

User evaluation can provide valuable real-world insight, but it is not interchangeable with a standards-based WCAG evaluation.

If user evaluation is included, document:

• Participant characteristics
• User tasks
• Technologies used
• Review scope
• Limitations

Do not generalize the experiences of a small number of participants to every person or disability.

Are Accessibility Overlays or Widgets Enough to Close Findings?

The presence of a tool does not prove that an observed barrier was resolved.

Retest the actual pages, components, and tasks under defined conditions.

Some fixes require changes to:

• Source code
• Content
• Design systems
• CMS templates
• Documents
• Third-party services

Should PDFs and Downloadable Documents Be Included?

Include them when they are:

• Specifically cited
• Important to a user journey
• Part of the agreed scope
• Used for forms, instructions, policies, applications, or essential content

Document accessibility requires a separate review.

A website-page audit does not automatically cover PDF tags, reading order, tables, alternative text, forms, or document language.

What Should Happen After Remediation?

Retest the original finding using the documented steps and relevant environment.

Then:

• Record the changed version.
• Inspect related components.
• Test the complete journey.
• Check for regressions.
• Connect the retest evidence to the original finding.
• Record the final status accurately.

Does a Technical Accessibility Review Certify ADA or WCAG Compliance?

No.

A scoped review can provide WCAG-oriented observations, evidence, remediation guidance, and verification within defined boundaries.

It does not provide:

• ADA certification
• WCAG certification
• Legal advice
• A guarantee of legal compliance
• A guarantee of accessibility for every person, browser, device, and assistive technology

Official References

• U.S. Department of Justice: Guidance on Web Accessibility and the ADA
• W3C Web Accessibility Initiative: WCAG Overview
• W3C: How to Meet WCAG 2.2 Quick Reference
• W3C: Understanding WCAG 2.2
• W3C: Understanding Conformance
• W3C: Website Accessibility Conformance Evaluation Methodology
• W3C: Selecting Web Accessibility Evaluation Tools
• W3C: Involving Users in Evaluating Web Accessibility

Need a Scoped Technical Review?

If a business or client has received a website accessibility demand letter, the useful technical outcome is a record that explains:

• What was reviewed
• What could be reproduced
• Which evidence supports each finding
• Which components and journeys are affected
• Who controls the remediation
• How the changes should be retested
• What limitations remain

Auditzo provides manual WCAG-oriented accessibility reviews, supporting evidence, developer-ready remediation guidance, and post-remediation verification within an agreed scope.

• Request an Accessibility Evidence Review
• View the Sample ADA/WCAG Report
• Review Accessibility Remediation Support

Auditzo provides technical accessibility observations, evidence, remediation guidance, and verification within an agreed scope. It does not provide legal advice, determine ADA applicability or violations, certify compliance, or guarantee the outcome of a claim.

This article is adapted from Auditzo's complete guide: Received a Website Accessibility Demand Letter? How to Verify WCAG Findings Before Remediation.