Accessibility Remediation Best Practices: Source Code vs Runtime Fixes

Discovering accessibility issues is just the beginning. How organizations fix those issues determines whether remediation produces lasting compliance or temporary patches. The choice between source code remediation and runtime fixes shapes outcomes, costs, and long-term sustainability.

This guide covers remediation approaches, implementation best practices, and strategies for efficient, effective accessibility improvements.

Remediation Approaches Compared

Source Code Remediation

Fixes applied directly to website code:

Characteristics:

• Changes committed to codebase
• Deployed through normal release process
• Permanent improvements
• No runtime dependency

Examples:

• Adding alt attributes to HTML
• Implementing keyboard handlers in JavaScript
• Correcting heading hierarchy in templates
• Adding ARIA attributes to components

Advantages:

• Permanent fixes
• No external dependency
• Works for all users
• Legally defensible
• Improves actual quality

Runtime Fixes

Fixes applied through JavaScript after page load:

Characteristics:

• JavaScript modifies DOM at runtime
• Original code unchanged
• Depends on script execution
• May conflict with existing code

Examples:

• Overlay widgets adding ARIA
• Scripts injecting alt text
• JavaScript modifying focus behavior
• CSS injection changing contrast

Disadvantages:

• Temporary patches
• Dependency on third party
• Performance impact
• Potential conflicts
• Limited effectiveness

Why Source Code Remediation Wins

Permanence

Source code fixes become part of the product:

Source code: Once deployed, fix persists through all future loads, updates, and interactions.

Runtime: Fix only applies when JavaScript loads and executes successfully.

Reliability

Source code fixes work universally:

Source code: Works regardless of JavaScript execution, browser settings, or network conditions.

Runtime: May fail with:

• JavaScript disabled
• Script blocked by ad blockers
• Network timeouts
• Script conflicts

Performance

Source code doesn't add load:

Source code: No additional resources or processing required.

Runtime:

• Additional script download
• Parse and execution time
• DOM manipulation overhead
• Potential reflow/repaint

Legal Protection

Courts and regulators recognize source code as genuine compliance:

Source code: Demonstrates actual accessibility improvements, defensible as good faith effort.

Runtime: Has not been accepted as compliance evidence. Sites using overlays continue facing lawsuits.

Remediation Prioritization

Impact-Based Prioritization

Focus on issues affecting most users:

Critical priority:

• Complete access blockers (keyboard traps)
• Checkout/conversion failures
• Navigation inaccessibility
• Form submission barriers

High priority:

• Significant user flow issues
• Common template problems
• Critical content accessibility
• Error handling failures

Medium priority:

• Enhancement opportunities
• Content-level issues
• Secondary functionality

Low priority:

• Edge cases
• Minor enhancements
• Nice-to-have improvements

Template-First Approach

Fix templates before individual pages:

Rationale: One template fix resolves issues across all pages using that template.

Process:

1. Identify template-level issues
2. Prioritize by page usage
3. Fix template code once
4. Verify across page instances

Quick Wins First

Build momentum with fast improvements:

Examples:

• Adding missing alt text (content update)
• Adding lang attribute (one-line fix)
• Fixing skip links (simple template change)
• Correcting heading structure (HTML update)

Remediation Workflow

Issue Assessment

For each issue, determine:

Location:

• Template/component level?
• Content level?
• Third-party component?

Effort:

• Quick fix (minutes)?
• Standard fix (hours)?
• Complex fix (days/weeks)?

Impact:

• Users affected?
• Severity of barrier?
• Legal risk?

Implementation Process

1. Reproduce issue: Verify the problem exists and understand manifestation.

2. Identify root cause: Determine what code/content creates the issue.

3. Design solution: Plan the fix according to WCAG requirements.

4. Implement fix: Make code/content changes.

5. Test fix: Verify issue resolved without regressions.

6. Deploy: Release through normal deployment process.

7. Verify in production: Confirm fix works in live environment.

Verification Methods

Automated verification:

• Re-run scanning tools
• Confirm issue no longer detected
• Check for new issues introduced

Manual verification:

• Keyboard testing
• Screen reader testing
• Visual inspection
• User flow testing

Common Remediations

Missing Alt Text

Issue: Images lack alternative text.

Fix:

<!-- Before -->
<img src="product.jpg">

<!-- After -->
<img src="product.jpg" alt="Navy blue wool peacoat with brass buttons">

Effort: Low (content update)

Missing Form Labels

Issue: Form inputs lack associated labels.

Fix:

<!-- Before -->
<input type="email" placeholder="Email">

<!-- After -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com">

Effort: Low-Medium (template update)

Keyboard Inaccessible Menu

Issue: Dropdown menus don't work with keyboard.

Fix:

// Add keyboard handling
menu.addEventListener('keydown', (e) => {
  if (e.key === 'Enter' || e.key === ' ') {
    toggleMenu();
  }
  if (e.key === 'ArrowDown') {
    focusNextItem();
  }
  if (e.key === 'Escape') {
    closeMenu();
  }
});

Effort: Medium-High (JavaScript development)

Missing Skip Link

Issue: No mechanism to bypass navigation.

Fix:

<!-- Add as first focusable element -->
<a href="#main-content" class="skip-link">Skip to main content</a>

<main id="main-content" tabindex="-1">

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 1000;
}

Effort: Low (template update)

Focus Indicator Removed

Issue: CSS removes focus outlines.

Fix:

/* Before */
*:focus { outline: none; }

/* After */
*:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

Effort: Low (CSS update)

Color Contrast Failure

Issue: Text doesn't meet contrast requirements.

Fix:

/* Before: 2.8:1 contrast */
.subtle-text { color: #999; }

/* After: 4.5:1 contrast */
.subtle-text { color: #767676; }

Effort: Low (CSS update)

Managing Remediation at Scale

Batch Similar Issues

Group and fix related issues together:

Example batches:

• All missing form labels
• All color contrast failures
• All heading hierarchy issues

Component Library Updates

Fix components once, deploy everywhere:

Process:

1. Identify accessibility issues in components
2. Update component library
3. Deploy library update
4. All uses automatically fixed

CMS Integration

Enable accessible content creation:

Improvements:

• Required alt text fields
• Heading selection guidance
• Contrast checking in editor
• Accessibility validation before publish

Third-Party Content

Embedded Widgets

Third-party widgets may have their own issues:

Options:

• Contact vendor for fixes
• Find accessible alternatives
• Build custom accessible version
• Limit use of inaccessible widgets

Payment Processors

Payment forms often third-party hosted:

Options:

• Choose accessible providers
• Request accessibility improvements
• Document limitations
• Provide alternative payment methods

Advertising

Ad content often beyond control:

Options:

• Require accessible ads in contracts
• Use platforms with accessibility standards
• Limit dynamic ad content

Documentation and Tracking

Issue Tracking

Document remediation efforts:

For each issue:

• Original finding
• Fix implemented
• Testing performed
• Deployment date
• Verification result

Progress Reporting

Track remediation progress:

Metrics:

• Issues resolved vs. outstanding
• Issues by severity status
• Remediation velocity
• Regression rate

Compliance Evidence

Maintain records for legal purposes:

Documentation:

• Audit findings
• Remediation timeline
• Testing evidence
• Ongoing monitoring results

Continuous Improvement

Prevent New Issues

Build accessibility into development:

Practices:

• CI/CD integration (TestParty Bouncer)
• IDE tools (TestParty PreGame)
• Code review checklists
• Component library standards

Monitor for Regressions

Continuous monitoring catches backsliding:

Approach:

• Regular automated scanning (TestParty Spotlight)
• Regression alerts
• Trend monitoring
• Periodic manual audits

Evolving Standards

Stay current with WCAG updates:

WCAG 2.2: New criteria added requiring attention:

• Focus Not Obscured
• Dragging Movements
• Target Size
• Redundant Entry
• Accessible Authentication

Taking Action

Effective accessibility remediation requires source code fixes, systematic prioritization, and ongoing monitoring. Runtime patches may seem faster but don't achieve compliance and create ongoing dependencies.

Invest in permanent improvements through source code remediation, integrate accessibility into development workflows, and maintain compliance through continuous monitoring.

Schedule a TestParty demo and get a 14-day compliance implementation plan.

Related Resources

• Accessibility Remediation Cost Analysis
• WCAG 2.2 Level AA Checklist
• Automated Accessibility Monitoring