Received a Website Accessibility Demand Letter? How to Verify WCAG Findings Before Remediation

Before the business, counsel, agency, or development team can make informed decisions, everyone needs the same clear factual record:

Which accessibility barriers were alleged, which of them can be reproduced on the current website, which pages and user journeys are affected, what evidence supports each finding, and what should be retested after remediation?

That is the technical job in front of the team. It is separate from deciding whether the Americans with Disabilities Act applies, whether the demand is legally valid, how the organization should respond, or whether a violation occurred.

This guide walks businesses and counsel through how to organize a WCAG-oriented website accessibility review around defined scope, reproducible observations, traceable evidence, remediation ownership, and verification after changes.

Technical scope note: Auditzo provides technical accessibility observations, supporting evidence, remediation-oriented guidance, and retesting within an agreed scope. Auditzo does not provide legal advice, determine ADA applicability, validate or reject a demand, certify legal or WCAG compliance, calculate legal exposure, recommend a legal response, or predict the outcome of a claim. Legal questions and preservation instructions should be handled by qualified counsel.

If you need a technical review now, you can request a scoped accessibility evidence review or first view Auditzo's sample ADA/WCAG accessibility evidence report.

For law firms reviewing a client website matter: see Auditzo's technical website evidence support for legal teams.

Received a Website Accessibility Demand Letter? Start With These Technical Steps

The first technical objective is not to prove or disprove the entire demand. It is to prevent confusion about what was alleged, what version of the website was reviewed, what can still be reproduced, and what evidence is available.

1. Preserve the letter and its attachments

Keep the original correspondence and every supplied attachment in the form received. Depending on the matter, that material may include:

• A list of alleged accessibility barriers
• Page URLs
• Screenshots
• Automated scanner output
• WCAG success-criterion references
• Videos or screen recordings
• Assistive-technology descriptions
• Browser or device information
• Dates and times
• A complaint, draft complaint, settlement proposal, or other legal material

Do not treat an attachment as technically correct merely because it accompanied a demand. Also do not modify, annotate, rename, or overwrite the only available copy. Maintain a separate working copy for technical review.

Counsel should determine legal preservation obligations, privilege, work-product questions, recipients, deadlines, and response strategy.

2. Record the current website version before material changes

Websites are dynamic. A theme update, content edit, tag deployment, plugin release, component change, third-party widget update, or emergency fix can change the behavior that a later reviewer observes.

Where appropriate and under the organization's and counsel's direction, record relevant current-state context before material changes, such as:

• Production URL
• Date, time, and time zone
• Release, deployment, build, theme, or application version where available
• CMS and relevant plugin versions
• Browser and operating system
• Viewport or device profile
• Logged-in or logged-out state
• Language and locale
• Relevant screenshots or screen recordings
• Accessibility tool and version
• Assistive technology and version where used
• Pages, templates, components, and journeys reviewed

A current-state record does not automatically prove what the website did weeks or months earlier. It documents the conditions observed during the current review.

3. Route legal questions to counsel and technical questions to the review team

The legal team may need to evaluate jurisdiction, deadlines, claimant standing, statutory coverage, defenses, settlement, communications, confidentiality, preservation, or procedural requirements.

The technical team should focus on questions it can actually test, such as:

• Does the cited page still exist?
• Can the alleged barrier be reproduced?
• Under which browser, viewport, input method, and assistive-technology conditions?
• Is the issue isolated to one page or repeated through a shared component?
• Which WCAG success criterion is technically relevant?
• Does the supplied evidence match the current page and component?
• What user task is affected?
• What source-code, content, design-system, CMS, or vendor change may be required?
• How will the change be verified after implementation?

4. Avoid turning a scanner result directly into a legal conclusion

Automated accessibility tools are useful for discovering candidate issues. They cannot automatically evaluate every aspect of accessibility, and they may produce false positives, false negatives, or results that require human interpretation.

The World Wide Web Consortium explains that evaluation tools can assist accessibility review but cannot determine accessibility by themselves; human judgment remains necessary. See W3C's guidance on selecting accessibility evaluation tools.

An automated alert should therefore be treated as one of the following until reviewed:

• A candidate issue requiring manual verification
• A machine-testable failure supported by inspectable evidence
• A result requiring page or code context
• An inconclusive observation
• A potential best-practice improvement rather than a WCAG failure
• A duplicate instance of a shared component problem

5. Separate evidence preservation from remediation

There may be good reasons to remediate serious barriers promptly. Technical documentation and remediation should still remain distinguishable.

A useful sequence is:

1. 1. Record the relevant current-state context where appropriate.
2. 2. Reproduce and document the alleged barrier.
3. 3. Identify the affected source component or content.
4. 4. Implement a controlled change.
5. 5. Retest the same behavior.
6. 6. Preserve the before-and-after records separately.

This avoids a common problem: the website is changed, but nobody can later explain which issue was fixed, what code or content changed, whether the original observation was verified, or whether the fix created a regression.

What a Website Accessibility Demand Letter Does and Does Not Establish

From a technical point of view, a demand letter gives the team a set of allegations and questions to investigate. It is not a substitute for testing.

It may identify:

• A page or user journey
• A claimed barrier
• A person's described experience
• An assistive technology or input method
• A WCAG criterion
• A screenshot, scanner result, or recorded interaction
• A time period

It does not automatically establish:

• That the cited page is unchanged
• That the issue occurs in every browser or assistive technology
• That every WCAG reference is technically correct
• That every detected issue blocked the described user
• That a scanner tested the full journey
• That the issue affects all pages
• That a current test proves historical behavior
• That WCAG conformance or nonconformance decides the legal claim
• That the ADA applies in the particular circumstances
• That a violation, liability, damages, or a legal remedy exists

Qualified counsel evaluates the legal meaning. A technical reviewer establishes what can be observed and reproduced within a defined scope.

Start With the Allegation, Not With a Full-Site Scanner Score

A useful review takes each material allegation and turns it into a testable question.

This approach is more useful than asking a generic tool to "check the entire website for ADA compliance."

Define the Accessibility Review Scope Before Testing

Scope determines what the evidence can support. A focused review with clear boundaries is more trustworthy than a broad conclusion built on unclear testing.

W3C's current WCAG Evaluation Methodology begins with defining the evaluation scope, exploring the digital product, and selecting a representative sample when every 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
• Support chat
• Maps
• Booking, scheduling, or payment tools
• Email templates or downloadable resources

A website audit does not automatically cover a native mobile application, PDF library, third-party portal, or authenticated product.

Identify representative pages and templates

Representative coverage may include:

• Homepage
• Primary navigation and footer
• Product, service, community, or property pages
• Category or search-results pages
• Search and filtering
• Contact or lead-generation forms
• Registration and login
• Account recovery
• Cart and checkout
• Booking or scheduling
• Support or chat
• Articles, guides, or resource pages
• Downloadable-document pages
• Error states
• Cookie or privacy interfaces where they affect access
• Reusable modals, carousels, accordions, menus, tabs, and cards

Include complete user processes where relevant

Testing one page in a multi-step journey may miss the barrier that prevents completion.

W3C's WCAG conformance guidance treats complete processes as important: when a page is part of a series of steps needed to complete an activity, the full process matters. For an ecommerce example, product selection alone does not establish that the cart, account, address, payment, validation, and confirmation journey is usable. See W3C's Understanding Conformance.

Potential complete processes include:

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

Define environments and assistive technologies

Record the environments used rather than writing only "screen-reader tested."

A useful record can include:

• Operating system and version
• Browser and version
• Screen reader and version
• Desktop or mobile device
• Viewport dimensions
• Zoom level
• Keyboard-only or switch-like input method
• Touch orientation
• Language and locale
• Logged-in or logged-out state
• Extensions or browser settings that may affect behavior
• Date, time, and website build or version

One assistive-technology combination cannot represent every user or technology combination. State what was tested and what was not.

State material exclusions

Examples include:

• Native mobile apps not reviewed
• PDFs excluded
• Authenticated areas unavailable
• Payment was not completed
• Only desktop web was tested
• Only selected screen-reader combinations were tested
• Third-party content reviewed only from the user-facing layer
• Source-code or design-system access was not provided
• Historical website versions were unavailable
• User research with people with disabilities was not included

An explicit exclusion prevents the reader from treating a scoped review as a whole-organization accessibility certification.

Choose the Technical Standard Without Making a Legal Claim

WCAG is a technical accessibility standard developed by W3C. WCAG 2.2 organizes testable success criteria under four principles: perceivable, operable, understandable, and robust, with A, AA, and AAA conformance levels. W3C encourages use of the latest WCAG version. See the official WCAG overview.

Auditzo commonly uses WCAG 2.2 Level AA as a technical review baseline where appropriate. That choice does not mean WCAG 2.2 AA is automatically the legally controlling standard for every private business, jurisdiction, contract, settlement, government entity, or matter.

The U.S. Department of Justice explains that the ADA applies to state and local government services and to goods, services, privileges, and activities offered by businesses open to the public, including those offered through websites. Its general guidance identifies WCAG as useful technical guidance and notes that the page does not reflect the separate web-content requirements adopted for state and local governments under Title II in 2024. See Guidance on Web Accessibility and the ADA and the DOJ's fact sheet on the Title II web and mobile-app rule.

The applicable legal framework, title, jurisdiction, version, conformance level, contractual requirement, and remedy are questions for qualified counsel.

For Auditzo's technical testing scope and deliverables, review the WCAG 2.2 AA website audit.

Use Several Testing Methods, Not One Tool

A detailed accessibility review typically combines methods because different barriers appear at different layers.

Real Auditzo accessibility review: In one engagement, Auditzo reviewed seven representative pages and documented 29 manually verified findings across areas including keyboard access, focus behavior, forms, headings, third-party widgets, responsive reflow, and contrast. View the accessibility evidence case study.

Automated candidate discovery

Automated tools can efficiently identify certain machine-testable patterns, such as:

• Missing attributes
• Some accessible-name problems
• Certain color-contrast failures
• Duplicate IDs or structural signals where relevant to the rule
• Form-control association problems
• Some ARIA misuse
• Empty headings or links
• Document-language signals
• Certain landmark and heading observations

Automated results still require context. A tool may know that an image has alternative text but cannot always determine whether that text is meaningful for the image's purpose. It may detect a name but not whether the control behaves correctly in a complete journey.

Auditzo's automated privacy and website-tracking scans are not accessibility audits. WCAG-oriented accessibility testing is separately scoped and human reviewed.

Keyboard-only review

Keyboard testing can examine whether users 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
• Continue through complete processes

Record the exact keystrokes and observed behavior for material findings.

Screen-reader review

Screen-reader testing may examine:

• Page title and language
• Heading structure
• Landmarks and regions
• Link and button names
• Form labels, instructions, descriptions, and errors
• Names, roles, values, and states of controls
• Dialog and focus announcements
• Dynamic status messages
• Tables
• Images and alternative text
• Changes introduced without a full page reload
• Reading and navigation order

The report should identify the screen reader, browser, version, commands used, page, task, expected result, actual result, and limitation.

Zoom, text resizing, and responsive reflow

Review whether content and functionality remain usable when users enlarge text or content. Investigate:

• Clipping
• Overlap
• Horizontal scrolling at relevant conditions
• Hidden controls
• Truncated labels or instructions
• Sticky elements obscuring content or focus
• Menus that cannot be opened or dismissed
• Forms that become unusable
• Reordered content that loses meaning

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, state, and component being evaluated.

Code, DOM, and accessibility-tree inspection

Visual behavior alone may not explain what assistive technology receives. Technical inspection may examine:

• Native element semantics
• Accessible names and descriptions
• ARIA roles, properties, and states
• Label relationships
• Heading and landmark structure
• DOM order
• Hidden and exposed content
• Live regions
• Focus movement
• Event handlers
• Disabled states
• Invalid nested interactions
• Component-library behavior

ARIA should not be treated as a substitute for correct native semantics and operable behavior.

User evaluation

Involving people with disabilities can reveal real-world barriers, workarounds, and usability problems that standards-based review may not fully expose.

User evaluation and WCAG conformance evaluation serve different purposes. W3C recommends combining user involvement with standards-based evaluation and warns against generalizing from a small number of participants. See Involving Users in Evaluating Web Accessibility.

If user evaluation is included, document participant characteristics, tasks, technologies, scope, and the limits of the conclusions.

Technical Areas That Commonly Require Manual Verification

The following areas frequently require human judgment or interaction testing. Their inclusion here does not mean every item appears in every demand or website.

Navigation, focus, and keyboard access

Review:

• Skip links
• Header and footer navigation
• Dropdown and mega menus
• Mobile navigation
• Focus order
• Focus visibility
• Focus obscured by sticky content
• Keyboard traps
• Modal focus management
• Return of focus after closing a component
• Logical order across responsive layouts

Forms, instructions, and errors

Review:

• Programmatic labels
• Persistent visible labels where needed
• Required-field indicators
• Input purpose
• Instructions 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

Names, roles, values, and states

Custom components 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

Headings, landmarks, and page structure

Review whether structure helps users understand and navigate the page:

• Descriptive page title
• Page language
• One clear content hierarchy
• Meaningful headings
• Main, navigation, search, complementary, and footer regions where appropriate
• Lists marked as lists
• Tables used and marked appropriately
• DOM and reading order consistent with meaning

Links, buttons, cards, and repeated content

Review:

• Link purpose in context
• Repeated "Learn more" or "View details" links
• Cards containing nested or conflicting interactive elements
• Links styled as buttons and buttons styled as links
• Icon-only controls
• New-window behavior where relevant
• Repeated navigation blocks
• Empty or duplicate accessible names

Images and non-text content

The correct treatment depends on 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 mere presence or absence of an alt attribute does not complete the evaluation.

Dynamic components

Review user-facing behavior of:

• Modals
• Carousels
• Accordions
• Tabs
• Autocomplete fields
• Date pickers
• Infinite scroll
• Toast notifications
• Chat widgets
• Cookie banners
• Embedded maps
• Video players
• Virtualized tables or lists

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

Third-party widgets and embedded services

A website owner may not control the underlying source code of a booking engine, payment tool, property-search widget, map, chat service, or embedded document viewer. The user-facing barrier can still affect the website journey.

Record:

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

Do not silently remove third-party findings merely because another vendor owns the code.

Documents and PDFs

If documents are in scope, 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.

Convert Candidate Results Into Verified Findings

An evidence-backed report should distinguish result types.

Verified technical finding

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

Candidate issue

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

Inconclusive observation

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

Best-practice or usability observation

The behavior may warrant improvement but is not represented as a failure of the cited WCAG success criterion based on the available evidence.

Not reproduced in the defined test

The issue was not observed under the documented test conditions. This does not prove that it never occurred in another version, browser, device, assistive technology, user state, or period.

This classification is more honest and useful than forcing every scanner alert into "pass" or "violation."

Build a Traceable Accessibility Finding

Every material finding should be reviewable without guessing where it came from.

Recommended fields

• Finding ID
• Short descriptive title
• Reviewed URL or view
• Template, component, or journey
• User task
• Test environment
• Input method or assistive technology
• Steps to reproduce
• Expected accessible behavior
• Observed behavior
• User impact
• Relevant WCAG success criterion
• Conformance level
• Supporting evidence IDs
• Recurrence or affected instances
• Technical severity
• Remediation owner
• Suggested remediation direction
• Retest method
• Known limitation
• Status

Illustrative finding record

Finding ID: A11Y-KB-04

Page: Property detail template
Component: Image gallery modal
Environment: Windows 11, Chrome 151, keyboard-only review
User task: Open the gallery, move through images, and close the modal

Steps:
1. Navigate to the "View gallery" button with Tab.
2. Press Enter.
3. Continue pressing Tab through modal controls.
4. 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 rather than
the control that opened the modal.

Expected behavior:
Keyboard focus should remain within the active modal while it is open, all modal
controls should be operable, and focus should return to a logical location when
the modal closes.

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

Technical mapping:
Review against the applicable keyboard, focus-order, focus-visibility, and
component-semantics requirements within the agreed WCAG 2.2 AA scope.

Recurrence:
Shared gallery component observed on the reviewed property templates.

Limitation:
The observation represents the pages, component version, browser, viewport,
and test period listed above. Other assistive-technology combinations were not
tested for this finding.

Legal conclusion:
Not provided. Reserved for qualified counsel.

The example deliberately separates observation, technical mapping, recurrence, remediation context, and legal interpretation.

Evidence Should Explain the Barrier, Not Just Decorate the Report

Screenshots are useful, but many accessibility failures concern interaction, focus movement, programmatic semantics, announcements, or responsive changes that a static image cannot fully show.

A finding may use:

• Full-page or component screenshot
• Annotated working screenshot
• Short screen recording
• Keyboard interaction record
• 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 original, working, and report evidence correctly

• Original capture: Preserved after collection or intake without silently overwriting it.
• Working copy: Used for annotation, cropping, comparison, analysis, or redaction.
• Report extract: A selected portion used to explain the finding.
• Redacted copy: A modified version from which sensitive or identifying information was removed.

Do not label an annotated, cropped, converted, or redacted image as identical to the original.

Protect sensitive information

Accessibility evidence can expose:

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

Use access controls, secure transfer, minimization, redaction, retention instructions, and authorized-recipient lists appropriate to the matter. Counsel and the responsible organization should determine privilege, work-product, legal-hold, and disclosure requirements.

Prioritize Findings Without Calling Severity a Legal Conclusion

Technical severity should describe user impact and remediation urgency within the reviewed system. It should not be presented as a damages estimate, liability rating, lawsuit probability, or legal conclusion.

Example technical severity model

The names and thresholds may vary by engagement. The report should define them.

Consider recurrence and ownership separately

One visible failure may originate in:

• A shared design-system component
• A CMS template
• Content-entry practices
• Theme CSS
• JavaScript behavior
• An embedded vendor
• A page-specific edit
• A document-generation workflow

Record both the affected instances and the probable source owner. This helps the implementation team fix the source rather than patching screenshots one page at a time.

Distinguish Current-State Testing From Historical Reconstruction

A test performed today documents today's observable behavior under the stated conditions. It does not automatically establish what happened on the date alleged in a letter.

Historical review may require available materials such as:

• Archived builds
• Source-control history
• Deployment records
• CMS revisions
• Theme or plugin versions
• Earlier audit reports
• Earlier screenshots or recordings
• Prior accessibility statements
• Issue-tracker records
• Vendor release history
• Previously supplied evidence

If an earlier version cannot be reconstructed, say so explicitly. Do not present current behavior as proof of historical behavior.

Plan Remediation Around Components, Journeys, and Ownership

Remediation is more effective when findings are converted into owned implementation tasks.

1. Identify the source layer

Determine whether the finding is primarily caused by:

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

2. Group related instances

Examples:

• Fix the shared card component rather than editing 40 repeated cards.
• Fix the form-control component rather than adding one-off labels to each page.
• Correct the heading rules in the CMS template rather than manually changing every article.
• Update the modal pattern rather than patching a single popup.

3. Define acceptance criteria before implementation

An implementation ticket should state:

• Affected component or content
• Relevant user task
• Expected accessible behavior
• Applicable WCAG-oriented requirement
• Keyboard behavior
• Screen-reader behavior where relevant
• Responsive and zoom behavior
• Test environment
• Evidence required for closure
• Regression areas

"Make it ADA compliant" is not an actionable development ticket.

4. Do not treat the presence of a tool as proof of remediation

Whether the site uses a plugin, widget, overlay, automated service, theme feature, or monitoring platform, verify the actual user-facing behavior.

The technical question is not "Is the tool installed?" It is:

Can users complete the relevant tasks under the defined test conditions, and do the reviewed pages and components meet the agreed accessibility requirements?

5. Keep vendor-dependent items visible

For third-party components, assign:

• Internal business owner
• Vendor contact
• Contract or procurement owner
• Technical workaround owner
• Target date
• Retest trigger
• Replacement decision if remediation is unavailable

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

Retest the Fixes and Preserve the Result

A ticket marked complete is not the same as a verified fix.

Retest the original behavior

Use the original finding's:

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

Record any necessary environment changes.

Check for regressions

A change can repair one behavior and damage another. For example:

• Adding focus containment may prevent the modal from closing.
• Changing a button to a link may alter keyboard interaction.
• Visually hiding text may remove it from the accessibility tree.
• Adding ARIA may override correct native semantics.
• Increasing contrast may remove a visible state distinction.
• Reordering the DOM may affect the visual layout or reading sequence.

Test the component and the complete journey, not only the single line of code changed.

Use clear retest statuses

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

Maintain before-and-after references

The retest record should connect:

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

That traceability is useful to developers, business owners, accessibility teams, and counsel without claiming that the record guarantees legal compliance.

What a Technical Accessibility Evidence Package Can Include

Deliverables depend on scope, but a structured package may contain:

Executive summary

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

Scope and methodology

• Domains and assets
• Pages and templates
• Complete processes
• Browsers and devices
• Assistive technologies
• Automated and manual methods
• Exclusions
• Sampling approach

Findings register

• Finding IDs
• Affected pages and components
• Steps to reproduce
• Observed and expected behavior
• WCAG-oriented mapping
• Evidence references
• Severity
• Recurrence
• Remediation ownership
• Limitations

Evidence index

• Screenshots
• Videos
• Code or DOM extracts
• Screen-reader notes
• Tool outputs
• Contrast measurements
• Reflow comparisons
• Original, working, redacted, and report-file distinctions

Remediation roadmap

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

Retest report

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

You can view Auditzo's sample accessibility evidence report and accessibility evidence package example to review the expected reporting structure before requesting an engagement.

Example: Seven Pages, 29 Manually Verified Findings

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

The work combined automated candidate discovery with manual verification and documented 29 verified findings involving accessible names, keyboard focus, persistent form labels, heading hierarchy, link purpose, embedded widgets, responsive reflow, visual contrast, and non-text content.

The findings were organized by severity, user impact, recurrence, and remediation ownership. This helped separate:

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

This engagement is not represented as a demand-letter matter. It is included because it demonstrates how a real accessibility evidence review can move from pages and user journeys to verified findings, implementation ownership, and a remediation roadmap.

Read the full case study: Real Estate Website Accessibility Evidence Review: 7 Pages, 29 Verified Findings.

How Auditzo Supports Accessibility Demand-Letter Technical Review

Auditzo can work with businesses, law firms, agencies, developers, and accessibility teams to investigate the technical questions identified for review.

Depending on the agreed scope, support may include:

• Review of allegations and supplied technical material
• Definition of pages, templates, components, and journeys
• WCAG 2.2 AA-oriented testing
• Automated candidate discovery
• Manual keyboard review
• Screen-reader testing using defined combinations
• Zoom and responsive reflow review
• Form, navigation, modal, link, image, contrast, and structure testing
• Third-party component observations
• Screenshot, video, DOM, and interaction evidence
• Finding-to-evidence traceability
• Technical severity and recurrence analysis
• Developer-ready remediation guidance
• Remediation ownership mapping
• Post-remediation verification
• Evidence-package organization for business, technical, and counsel review

Review Auditzo's ADA website accessibility audit, WCAG 2.2 AA website audit, or accessibility remediation support.

Law firms can also review Auditzo's technical website evidence support for legal teams.

What Auditzo does not do

Auditzo does not:

• Provide legal advice
• Interpret the demand for the recipient
• Decide whether the ADA or another law applies
• Determine claimant standing
• Recommend whether or how to respond
• Communicate with a claimant as legal representative
• Determine whether a violation occurred
• Calculate damages, settlement value, or legal exposure
• Certify ADA or WCAG compliance
• Guarantee prevention or dismissal of a claim
• Guarantee accessibility for every person, disability, browser, device, or assistive technology
• Provide an expert-witness opinion, sworn declaration, or litigation testimony unless separately scoped, qualified, agreed, and documented

Auditzo's role is deliberately narrower: establish clear technical observations and help teams fix and verify the website behavior within the agreed scope.

Review Auditzo's audit methodology and audit scope and limitations before selecting an accessibility review path.

Website Accessibility Demand Letter Technical Review Checklist

Matter and supplied materials

• Preserve the original letter and attachments.
• Record the date received and route deadlines to counsel.
• Keep original and working copies separate.
• List every cited URL, component, criterion, and user experience.
• Record any supplied browser, assistive technology, device, date, or screenshot context.

Current-state context

• Record the production URL and review date.
• Record the website build, theme, plugin, or deployment version where available.
• Identify recent material changes.
• Document browser, operating system, viewport, language, and login state.
• Keep current-state observations separate from historical claims.

Scope

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

Testing

• Use automated results as candidate discovery, not final conclusions.
• Perform keyboard review.
• Perform screen-reader review where scoped.
• Review zoom, text resizing, and responsive reflow.
• Review forms, errors, instructions, and status messages.
• Review navigation, focus, dialogs, and dynamic components.
• Review color, non-color cues, links, images, and structure.
• Review documents and third-party components separately where included.

Evidence

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

Remediation

• Identify content, code, design-system, CMS, or vendor ownership.
• Group repeated issues by source component.
• Write testable acceptance criteria.
• Prioritize core-journey barriers and systemic fixes.
• Track vendor-dependent items.
• Do not treat tool installation as proof of remediation.

Retesting

• Retest the original steps.
• Record the remediated version.
• Check related components and complete journeys for regression.
• Link the retest to the original finding and implementation ticket.
• Record resolved, partial, unresolved, inconclusive, and regression statuses accurately.

Boundaries

• Keep technical observations separate from legal conclusions.
• Do not call a scoped review an ADA 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 counsel.

Frequently Asked Questions

What is a website accessibility demand letter?

A website accessibility demand letter is generally correspondence alleging that a website, application, document, or digital experience contains accessibility barriers and requesting some form of action. The precise legal meaning, deadlines, claims, and response options should be reviewed by qualified counsel.

From Auditzo's perspective, the letter identifies technical questions that may need to be tested and documented.

Is an accessibility demand letter the same as a lawsuit?

Generally, a demand letter is correspondence rather than a filed court action. A complaint, summons, or other filed material creates a different procedural situation. If the recipient is unsure what documents were received or what deadlines apply, qualified counsel should review them promptly.

Does receiving a demand letter prove that the website violates the ADA?

No. Receiving an allegation does not itself establish ADA applicability, a violation, liability, or a remedy. A technical review can investigate whether specific accessibility barriers can be observed or reproduced. Counsel determines the legal significance.

Should the website be changed immediately?

That decision can involve legal, accessibility, security, operational, and business considerations. Counsel and the responsible organization should decide the sequence.

From a technical evidence perspective, document relevant current-state behavior before material changes where appropriate, keep preservation and remediation records separate, and retest after changes.

Is an automated accessibility scan enough?

No automated tool can evaluate every aspect of accessibility. Tools are useful for candidate discovery and some machine-testable checks, while manual review is 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 that the website is accessible?

No. A scan can report that it did not detect certain machine-testable issues under its configuration. 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 technical accessibility baseline that can support structured testing. Which legal standard, version, level, jurisdiction, contract, regulation, or settlement requirement applies is a matter-specific question for qualified counsel.

Can Auditzo tell us whether the demand is valid?

No. Auditzo can test specified pages and user journeys, review supplied technical evidence, document observed barriers, map findings to the agreed WCAG-oriented scope, explain limitations, and verify remediation. Auditzo does not determine whether a legal demand or claim is valid.

Can a current audit prove what the website did months ago?

Not automatically. A current audit documents the website as observed during the current test. Historical conclusions may require archived builds, source history, deployment records, CMS revisions, previous screenshots, earlier reports, or other timestamped material.

How many pages should be tested?

The appropriate scope depends on the website, allegations, templates, components, and user journeys. A representative review should account for unique page types, repeated components, important content, complete processes, third-party tools, authenticated areas, and material states. Testing the homepage alone is rarely enough to represent a complex website.

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, version, commands, and limitations rather than simply stating "screen-reader compatible."

Does every accessibility review need user testing with people with disabilities?

User evaluation can provide valuable real-world insight, but it is not interchangeable with WCAG conformance evaluation. If included, it should be clearly scoped and combined with standards-based review. Results from a small number of participants should not be generalized to all users or disabilities.

Are accessibility overlays or widgets enough to close the findings?

The presence of any tool does not by itself prove that the alleged or verified barriers have been resolved. Retest the actual pages, components, and user journeys under the defined conditions. Some fixes may require changes to source code, content, design systems, templates, documents, or third-party services.

Should PDFs and downloadable documents be included?

Include them when they are cited, important to the user journey, or part of the agreed scope. Document accessibility requires its own review. A website-page audit does not automatically cover PDF tags, reading order, forms, tables, alternative text, or document language.

What should happen after remediation?

Retest the original finding using the documented steps and relevant environment, record the changed version, check for regressions, and connect the retest evidence to the original finding and implementation task.

Can Auditzo provide remediation guidance?

Yes. A scoped accessibility review can include developer-ready remediation direction, affected-component mapping, ownership guidance, and retest instructions. Fix implementation and repeated verification should be separately defined when they extend beyond the audit scope.

Does Auditzo certify ADA or WCAG compliance?

No. Auditzo provides WCAG-oriented technical observations and evidence within a defined scope. It does not provide ADA certification, WCAG certification, legal advice, or a guarantee of compliance or accessibility for every user and environment.

Official Accessibility 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: WCAG Evaluation Methodology
• W3C: Selecting Web Accessibility Evaluation Tools
• W3C: Involving Users in Evaluating Web Accessibility

Need to Verify Accessibility Allegations and Plan the Fixes?

If your business or client has received a website accessibility demand letter, Auditzo can scope a technical review around the cited pages, components, user journeys, and WCAG-oriented questions.

The goal is not to replace counsel or declare a legal outcome. It is to give business, legal, accessibility, and development teams a clearer technical record:

• What was reviewed
• What could be reproduced
• Which evidence supports each finding
• Which components and journeys are affected
• Who may need to remediate them
• How the changes should be retested
• What limitations remain

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.