Website Accessibility Demand Letter: A Developer's WCAG Verification Guide
A practical workflow for turning accessibility allegations into scoped tests, traceable 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
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 or user journey
A claimed barrier
A person's described experience
An assistive technology or input method
A WCAG success criterion
A screenshot, recording, or scanner result
A 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 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:
Record relevant current-state context.
Reproduce and document the alleged behavior.
Identify the affected source component or content.
Implement a controlled change.
Retest the original behavior.
Check related components and complete journeys for regression.
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.
| Example allegation | Technical questions worth investigating |
|---|---|
| The navigation cannot be used with a keyboard | Which navigation component and viewport? Can every interactive item receive focus? Is focus visible? Can menus be opened, traversed, and closed? Does focus move logically? |
| A form is inaccessible to a screen-reader user | Which form and field? Does each control expose an appropriate name, role, state, instruction, and error relationship? Which browser and screen reader were used? |
| Images lack text alternatives | Which images? Are they informative, functional, complex, redundant, or decorative? Is an alt attribute present, and does its value serve the image's purpose in context? |
| Links are ambiguous | Which links and surrounding context? Do repeated links expose distinguishable purposes programmatically and visually? Are card-level click targets coded consistently? |
| Focus is hidden behind a sticky banner | Which element, viewport, zoom level, and sticky component? Is the focused item fully or partly obscured? |
| Checkout cannot be completed | Which step fails? Does the failure involve keyboard access, labels, validation, status messages, authentication, focus, timeout, or a third-party payment component? |
| Content disappears at 200% zoom | Which page, browser, viewport, and orientation? Is information or functionality clipped, overlapped, lost, or unreachable? |
| A modal traps or loses focus | Where does focus move when the modal opens? Can all controls be operated? Can the modal be closed? Does focus return to a logical location? Is background content incorrectly reachable? |
| A PDF is inaccessible | Is the file in scope? Does it include appropriate tags, reading order, language, headings, meaningful links, alternative text, tables, and accessible form fields where relevant? |
An accessibility review converts an allegation into a defined test, a traceable finding, an owned remediation task, and a documented retest.
This workflow produces 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
Support 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 accessibility 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 verify 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 their 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 every article.
Define acceptance criteria before implementation.
A useful remediation 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
Keep the original finding, implementation work, changed version, retest evidence, and final status connected.
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
Supporting 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 user processes
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: Website Accessibility Conformance Evaluation Methodology
Need a Scoped Technical Accessibility 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 technical evidence, developer-ready remediation guidance, and post-remediation verification within an agreed scope.
Request an Accessibility Evidence Review
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.
