Remediation Language: Communicating Effectively with Developers

Even a perfect accessibility audit report can be rendered useless if the developer receiving it doesn't understand what they need to do. And from the developer's perspective, receiving a report that is only a list of problems without solutions feels like a complaint, not a collaboration.

This is why the ability to speak remediation language — writing technical remediation recommendations that are precise, practical, and empathetic — is the crown skill of an Access Squad auditor. This article teaches you how to turn audit findings into instructions a developer can act on within minutes.

---

Core Principle: Auditors Are Not Programmers, But Must Understand Code

A common misconception is that an accessibility auditor must be able to rewrite problematic code. This is not true. An auditor's job is not to program — an auditor's job is to precisely define what is technically needed for a component to become accessible.

Think of a building inspector. They don't need to be able to install pipes themselves to say, "The drainage system on the third floor doesn't meet Safety Standard X. The drainage pipes need to be widened by at least 5 cm." They know what is wrong and what is correct based on standards, and it's the contractor's job to figure out how to fix it.

Similarly, an accessibility auditor must know:

• Name (accessible name): What will the screen reader announce?
• Role: How should this component behave (button, link, dialog)?
• Value: What is the current status or value of this component?
• Relationships: Is this element programmatically connected to its description or label?

---

Three Types of Remediation Recommendations

1. Semantic Remediation: Use the Right HTML Element

The most powerful and easiest-to-implement recommendation is suggesting the replacement of an incorrect HTML element with the correct one.

Issue: "The 'Add to Cart' button cannot be focused or activated via keyboard."

Technical Finding: The element used is a <div> with a JavaScript onClick handler.

Remediation Recommendation:

Replace the <div class="add-to-cart"> element with a <button type="button"> element. The <button> element natively supports keyboard focus (Tab), activation (Enter/Space), and has an implicit role="button" recognized by all screen readers. No JavaScript changes are needed — simply change the HTML tag.

This is the best example of remediation. The solution is one line; the impact is massive.

2. WAI-ARIA Remediation: Add Attributes for Custom Components

When custom components (which cannot be replaced with semantic HTML elements without completely overhauling the visual design) must be retained, WAI-ARIA is the solution.

Issue: "The custom tab navigation component does not communicate which tab is currently active."

Remediation Recommendation:

On the elements functioning as tabs, add:

• role="tab" on each tab button.
• aria-selected="true" on the active tab, and aria-selected="false" on others. Update these values via JavaScript when tabs change.
• On the associated content panels, add role="tabpanel" and aria-labelledby="[id-of-related-tab]".

Screen reader users will hear: "Product Description tab, selected, 1 of 3."

3. Relationship Remediation: Connect Related Elements Programmatically

Many accessibility issues occur not because an element is missing, but because elements that should be connected are not programmatically linked.

Issue: "When a user incorrectly fills out a form, an error message appears but the screen reader doesn't know that message is related to the problematic input field."

Remediation Recommendation:

1. Add aria-describedby="[error-message-id]" attribute to the problematic <input> element.
2. Give the error message element a unique ID, e.g., id="email-error-msg".
3. Add aria-invalid="true" to the <input> element when in an error state.
4. Ensure keyboard focus automatically moves to the first error field after the user presses Submit.

---

How to Write Recommendations That Build Trust

The quality of the relationship between auditor and developer team greatly determines whether fixes will be genuinely implemented or merely patched to "pass the audit."

Use Solutive Language, Not Critical Language

• ❌ Avoid: "You've completely ignored the needs of blind users across the entire checkout flow."
• ✅ Use: "The checkout flow currently has three barriers we can fix incrementally. The highest priority is ensuring the 'Continue to Payment' button is keyboard accessible."

Include Code Snippets When Possible

Developers greatly appreciate concrete examples. If you already know the solution, include a small code snippet:

<!-- BEFORE (problematic) -->
<div class="btn-primary" onclick="addToCart()">Add to Cart</div>

<!-- AFTER (fixed) -->
<button type="button" onclick="addToCart()">Add to Cart</button>

This eliminates ambiguity and massively speeds up developer work.

Show the Real User Impact

Recommendations that explain "why this matters to real users" are more likely to be prioritized than those that only cite WCAG criteria numbers.

"Without this fix, users who rely solely on keyboard or screen reader will be completely unable to complete a purchase. This isn't just an accessibility issue — it's a conversion blocker for approximately 15% of the population."

---

Building Long-Term Relationships with Developer Teams

The best auditors don't come once, hand over a report, and leave. They build a sustained consultative relationship.

Best Practices:

• Joint Triage Session: Offer a brief session (30 minutes) after the report is delivered to walk through findings with the developer team, answer questions, and clarify priorities.
• Retesting: After developers claim to have fixed an issue, the auditor conducts a retest to verify. This is a healthy cycle.
• Ongoing Education: Occasionally share articles, guides, or brief demos of "what it feels like to use this product with a screen reader" with developer teams. Organically grown empathy produces far better products than mere regulatory compliance.

---

Conclusion

Remediation language is the bridge between the lived experience world of blind users and the technical code world of developers. An Access Squad member who masters all three pillars — semantic remediation, WAI-ARIA remediation, and relationship remediation — and can deliver them with empathy and clarity, is an invaluable asset to Indonesia's technology industry.

You are not just finding problems. You are defining their solutions. And that is the true power of a professional accessibility auditor.

References

- W3C. WAI-ARIA Authoring Practices 1.2. https://www.w3.org/WAI/ARIA/apg/ - Firth, A. Practical Web Accessibility: A Book Apart. - Mancilla, R. Guide to Digital Accessibility. - Revilla Munoz, O. & Carrera, O. Web Accessibility: WCAG 2.2 made easy.