Remediation for Existing Websites
Remediation for Existing Websites: how real ADA fixes happen in a Django stack
remediation for existing websites: how real ADA fixes happen in a Django stack
A business calls after getting a demand letter. It usually says the website blocks screen reader users from placing an order or booking an appointment. The letter cites Title III of the Americans with Disabilities Act and lists failures under WCAG 2.1 AA.
The site is live, making money, ranking in search, and now it has to be fixed without breaking anything. That’s remediation work. It is slower than building a new site. It costs more than owners expect. It exposes bad code that sat unnoticed for years.
This article explains how remediation actually works when the backend is Django and the frontend is custom code. It covers timelines, pricing, trade-offs, testing, and what courts have looked at when companies claim their site is now accessible.
No theory. Just the mechanics.
Remediation is not adding an accessibility widget. It is rewriting code so people using assistive technology can operate the site independently.
The legal context comes from Title III of the ADA and enforcement positions from the U.S. Department of Justice. The DOJ’s 2022 guidance states that businesses open to the public must make their websites accessible and mentions WCAG as a useful standard.
Courts usually accept WCAG 2.1 AA as the technical benchmark. Not a law. A measuring stick.
Typical remediation scope includes:
- Fixing semantic HTML structure
- Adding alt text to meaningful images
- Making all functions keyboard accessible
- Correcting color contrast
- Labeling form inputs and error messages
- Making PDFs accessible or replacing them
- Fixing focus order and skip links
- Testing with screen readers
Each item turns into code changes. Real ones.
why Django sites need special handling
Django is a backend framework. It handles models, templates, routing, authentication. Accessibility problems often hide in templates and custom components.
I’ve seen the same pattern on dozens of Django sites:
- Templates reuse
<div>tags where<nav>or<main>should exist - Forms generated with custom widgets lack labels
- Pagination links don’t expose page numbers to screen readers
- Carousels use JavaScript that traps keyboard focus
- Image uploads never require alt text
The problem is structural. Django doesn’t enforce accessibility rules. Developers do.
A remediation job starts with a template audit.
a real example: a car dealership site
In October 2023 a used car dealership in Tampa sent over a demand letter they received. The site ran Django 3.2 with a custom React frontend. The complaint said blind users couldn’t filter vehicles or complete financing forms.
We ran NVDA screen reader tests.
Problems found in two hours:
- Vehicle cards had image-only links with no alt text
- Filters used custom dropdowns without keyboard support
- Form errors appeared visually but were not announced to screen readers
- Finance PDF disclosures were scanned images
The dealership had 1,800 vehicle listings. Fixing it required template edits, React component rewrites, PDF remediation, and content cleanup.
Total cost: $64,500 over five months. That included developer hours, QA testing, and legal reporting documentation.
Trade-off: search rankings dipped during rollout because URLs changed when the filtering system was rebuilt. Traffic recovered after six weeks. The owner accepted that because litigation risk was higher.
That’s remediation in practice.
step 1: audit before touching code
Every project starts with an accessibility audit. Not automated scans alone. Real manual testing.
Tools used:
- Axe-core browser extension
- WAVE evaluation tool
- NVDA screen reader on Windows
- VoiceOver on macOS and iOS
- Keyboard-only navigation
Automated scans catch about 30 percent of issues. Missing alt text, low color contrast, ARIA misuse.
Manual testing finds the rest. Broken focus order. Confusing link text. Modals that trap keyboard navigation.
A typical 50-page Django site audit takes 25–40 hours. Cost ranges from $2,500 to $8,000 depending on complexity.
The audit produces a list of failures mapped to WCAG success criteria. Example:
- 1.1.1 Non-text Content – missing alt text on 312 images
- 2.1.1 Keyboard – dropdown menu inaccessible
- 3.3.2 Labels or Instructions – checkout form unlabeled
Developers work from that list.
step 2: fixing templates and components
Django templates generate most HTML. If templates are wrong, the whole site is wrong.
Common fixes:
semantic structure
Replace generic containers with real landmarks.
<header>
<nav>
<main>
<footer>
Screen readers rely on landmarks for navigation. Without them, users get lost.
form accessibility
Django forms often render like this:
<input type="text" name="email">
Remediation adds labels:
<label for="email">Email address</label>
<input id="email" type="text" name="email">
Error messages need ARIA attributes:
<div role="alert">Email is required</div>
Without this, screen readers never announce the problem.
focus management
Modal dialogs require JavaScript changes so focus moves inside the modal and returns after closing.
That is not a CSS tweak. It is code.
image alt text
Content editors need an alt text field in the Django admin panel. Mandatory.
I add validation rules so images cannot publish without alt text unless marked decorative.
Content teams hate this at first. Then they get used to it.
step 3: frontend rewrites
Custom frontend frameworks are where accessibility breaks.
Carousels, infinite scroll lists, dynamic filters, tab panels. They often ignore keyboard users.
Fixing them requires:
- ARIA roles and states
- Visible focus indicators
- Keyboard event handlers
- Proper DOM order
React or Vue components must be rewritten. Sometimes from scratch.
One ecommerce site used a custom size picker built with <span> tags. Screen readers read nothing. Fixing it meant replacing the component with real <button> elements and adding state announcements.
Time spent: 18 developer hours for one widget.
Multiply that across a site.
step 4: document accessibility
PDFs cause lawsuits.
Many PDFs are scanned images. Screen readers see blank pages.
Fix options:
- Recreate PDFs in HTML
- Add tags using Adobe Acrobat Pro
- Provide accessible alternatives
I’ve billed 10 hours fixing a single 80-page menu PDF. Not cheap.
Businesses with thousands of PDFs often choose staged remediation. Courts sometimes accept phased plans if deadlines are clear.
Trade-off: some documents remain inaccessible during remediation.
step 5: testing again and documenting everything
After fixes, everything is tested again.
Keyboard navigation
Screen readers
Mobile accessibility
Color contrast
Results are documented in an accessibility statement posted on the site. That statement includes:
- Date of last audit
- Known limitations
- Contact method for accessibility issues
Courts look for good-faith effort. Documentation helps.
In Robles v. Domino’s Pizza, the Ninth Circuit did not require perfect accessibility. It required equal access to goods and services.
That difference matters.
why overlays don’t fix Django accessibility problems
Accessibility overlays promise instant compliance. Most inject JavaScript that adds alt text guesses or color filters.
They do not fix template structure. They do not label forms correctly. They do not make keyboard traps disappear.
Lawsuits have been filed against businesses using overlays. Courts still look at underlying code.
I’ve seen a Shopify store using an overlay get sued in New York in 2022. The overlay could not make checkout forms readable to screen readers. The case settled with real remediation requirements.
Overlays are cosmetic.
timeline for a real remediation project
Typical timeline for a mid-size Django site:
Week 1–3: audit
Week 4–6: template fixes
Week 7–10: component rewrites
Week 11–14: content cleanup
Week 15–18: testing and reporting
Four months minimum.
Sites with custom dashboards or user-generated content take longer.
If a demand letter sets a 60-day deadline, the timeline compresses and costs rise.
pricing reality
Businesses expect $5,000 fixes. That rarely happens.
Typical remediation costs:
Small brochure site (20 pages): $3,000–$10,000
Mid-size ecommerce site: $30,000–$120,000
Large marketplace or SaaS platform: $150,000–$500,000
Prices depend on code quality. Bad legacy code doubles the cost.
The cheapest option is building accessibility into the site from the start. Retrofitting is always harder.
That is not theory. That is invoice history.
limitations and criticisms of ADA web remediation
There are criticisms of how accessibility litigation works.
Some plaintiffs file dozens of cases. Businesses call it “drive-by litigation.” Courts have acknowledged the pattern but still allow cases when barriers exist.
Another limitation is WCAG complexity. The guidelines are technical. Small businesses struggle to interpret them without consultants.
There is also a trade-off between strict compliance and design freedom. High color contrast rules change branding. Keyboard navigation requirements limit fancy animations.
Some designers hate this. They say sites look plain. Accessibility still requires them.
One restaurant owner in Phoenix told me his new accessible site “looks like 2012.” He kept it anyway after a lawsuit settlement cost him $18,000 in attorney fees.
how courts evaluate “we fixed the site”
Courts don’t accept vague claims.
Businesses must show:
- Specific fixes implemented
- Dates of remediation
- Testing results
If barriers remain, the case continues.
In several federal cases, judges ordered companies to hire outside accessibility consultants and submit compliance reports every six months.
That is ongoing oversight. Not a one-time fix.
content editors are part of remediation
Accessibility is not only developer work.
Content editors must:
- Write meaningful link text
- Add alt text
- Avoid uploading image-only PDFs
- Maintain heading hierarchy
I add accessibility training sessions for editorial teams. Two hours each. Recorded.
Otherwise, new content breaks compliance in weeks.
A news site in Chicago spent $42,000 on remediation in 2022. Three months later, editors uploaded 200 inaccessible PDFs. The cycle repeated.
Accessibility requires discipline.
testing tools used in Django remediation
Common tools:
- Axe DevTools
- WAVE
- Lighthouse accessibility audit
- NVDA screen reader
- JAWS screen reader
- VoiceOver
Automated scans flag code errors. Screen readers reveal usability issues.
Testing on mobile devices is required. Many lawsuits involve mobile checkout failures.
SEO effects of ADA remediation
Accessibility work often improves SEO.
Semantic HTML improves crawlability. Proper headings help indexing. Alt text helps image search.
But short-term traffic dips can happen if URLs change or navigation is rebuilt.
One ecommerce client saw a 12 percent traffic drop during remediation. It recovered after 45 days.
Accessibility is not an SEO strategy. It sometimes overlaps.
Django-specific fixes that show up repeatedly
In real projects, these problems repeat:
- Missing
langattribute in<html>tag - CSRF error pages inaccessible to screen readers
- Custom pagination lacking aria labels
- Image thumbnails with no alt text
- Autocomplete fields unusable with keyboard
- Cookie consent popups trapping focus
Fixing these once helps across the site.
Reusable accessible components save time.
building accessibility into the development workflow
Real teams add accessibility checks to CI pipelines.
- Automated Axe tests in GitHub Actions
- Manual keyboard testing before deploy
- Accessibility review in code pull requests
Without workflow changes, remediation is temporary.
I’ve watched teams fix accessibility, then break it with a redesign three months later.
That’s normal.
why “error-free” claims are unrealistic
No large website is error-free. New content introduces new problems. Third-party plugins update. Browsers change behavior.
Accessibility is a maintenance task.
Courts don’t expect perfection. They expect effort and progress.
Businesses claiming perfect compliance often face new complaints months later.
Reality is messy.
documentation and accessibility statements
A good accessibility statement includes:
- Standard followed, like WCAG 2.1 AA
- Date of last audit
- Known issues
- Contact email or phone
This shows intent to fix problems.
It does not prevent lawsuits. It shows good faith.
final view from the trenches
Remediation for an existing Django site is code work, content cleanup, testing, and documentation. It takes months. It costs real money. It sometimes hurts design preferences and short-term SEO.
But after remediation, sites are easier to use. Keyboard navigation works. Screen readers can read product details. Forms are clearer.
That is the outcome courts look for when evaluating ADA Title III accessibility claims.