For each script that has an alternative, is this alternative relevant?
You have planned an alternative to your Google Maps map: a text form to search for an address. Good initiative. But if this form does not allow you to calculate a route while the map does, the alternative is not relevant. This is exactly what criterion 7.2 verifies.
Test 7.2.1 focuses on functional alternatives: can the user access the same content and accomplish the same tasks without JavaScript? A relevant alternative is an equivalent alternative, not a makeshift one. It can take the form of a link to an alternative version, HTML content that displays when JS is disabled, or a <noscript> component.
Test 7.2.2 concerns non-textual elements updated dynamically. A chart updated every thirty seconds: its aria-label must be updated in the same cycle. An attribute frozen on previous data becomes a lie for screen reader users. This is WCAG failure technique F20 in action.
Progressive enhancement solves both problems: a functional HTML base, JavaScript that enriches it. No separate alternative to maintain, no possible desynchronization.
2 tests to confirm that an alternative is offered for each script
Functional equivalence of JavaScript alternative
- Identify JavaScript components that propose a declared alternative: "Accessible version" link,
<noscript>block, fallback HTML version. - Disable JavaScript in the browser and reload the page to reveal alternatives that display automatically.
- For each identified alternative, verify that it gives access to the same content as the original JavaScript component.
- Verify that it allows accomplishing similar functionality (calculating a route, filtering data, submitting a form).
- If all alternatives are functionally equivalent: test validated. If an alternative is incomplete on a key functionality: test not validated.
Synchronized update of alternative of non-textual element
- Identify all non-textual elements (images, charts, gauges,
<canvas>,<svg>) whose content is modified dynamically by JavaScript. - For each, verify that a textual alternative is present:
alt,aria-label,aria-labelledby, or<title>on SVG. - Trigger the update of the non-textual content (wait for automatic reload or interact with the component).
- Observe in the DOM inspector if the textual alternative is modified at the same time.
- Verify that the updated alternative describes the new displayed content, not the old one.
- If the alternative is synchronized and relevant: test validated. If it is frozen or describes a previous state: test not validated.
Examples
❌ Non-compliant : Dynamic chart with frozen textual alternative
<canvas id="sales-chart" aria-label="September sales: 120k units"></canvas>
<script>
function updateChart(newData) {
drawChart(newData); // Updates the canvas visually
// The aria-label is NOT updated
}
setInterval(() => fetchData().then(updateChart), 30000);
</script>The chart displays October figures in real time, but the aria-label still announces "September sales". A screen reader user receives false data. This is WCAG failure technique F20: the alternative is not updated when the content changes.
✅ Compliant : Interactive map with complete functional alternative
<div id="map-container">
<div id="google-map" aria-hidden="true"></div>
<div id="map-fallback">
<p>This interactive map requires JavaScript.
Use the form below to calculate your route.</p>
<form action="/route" method="get">
<label for="departure">Departure address</label>
<input type="text" id="departure" name="departure">
<label for="destination">Destination address</label>
<input type="text" id="destination" name="destination">
<button type="submit">Calculate route</button>
</form>
</div>
</div>
<script>
document.getElementById('map-fallback').hidden = true;
initGoogleMap();
</script>The alternative provides the same functionality as the map: the user can calculate a route. It is visible when JS is disabled or when the map fails to load. The form allows accomplishing the same main task: test 7.2.1 validated.
Tips and pitfalls
⚠️ An alternative that displays content but does not allow interaction with it
This is the most common audit error. A data table replaces a filterable chart, but without the filters. The user sees the information but cannot manipulate it. Displaying is not equivalent to interacting: the alternative must cover functionality, not just static content.
⚠️ Confusing criterion 7.1 and criterion 7.2
Criterion 7.1 verifies that the script itself is natively accessible (ARIA roles, keyboard interactions). Criterion 7.2 verifies that the alternative to this script is relevant. A component can fail 7.1 and pass 7.2, and vice versa. These are two distinct audit scopes.
💡 No need to disable JS on the entire site
RGAA does not require disabling JavaScript on the entire page to audit criterion 7.2. The requirement applies only to scripts that declare an alternative. If a component is natively accessible (7.1 validated), it is not subject to 7.2.
⚠️ Asynchronous update: the alternative must follow in real time
For test 7.2.2, the textual alternative must be updated in the AJAX request callback, not in a delayed setTimeout. Open the DOM inspector and observe the aria-label attribute while the visual content changes: if the DOM does not move, it is non-compliant.
⚠️ Progressive enhancement satisfies 7.2 without a separate alternative
If your JavaScript component is built on top of a functional HTML base, there is no "alternative" properly speaking: the basic HTML is the no-JS version, and criterion 7.2 is satisfied natively. No parallel version to maintain.
Frequently asked questions
How to test RGAA criterion 7.2 without JavaScript enabled?
Only to reveal HTML alternatives that display automatically when JS is absent (test 7.2.1). You do not need to disable JS on the entire site: RGAA does not require it. The objective is to verify that declared alternatives are functionally equivalent, not to test each component in degraded mode.
When must a natively accessible JavaScript component provide a RGAA alternative?
No. Criterion 7.2 only applies to scripts "having an alternative" — it is in the criterion title itself. If your component is natively accessible (criterion 7.1 validated), you do not need to provide an alternative. The requirement applies to the quality of existing alternatives, not their creation.
Why does a <noscript> block not necessarily constitute a valid alternative to the script?
<noscript> is a valid alternative for test 7.2.1, provided its content is functionally equivalent to the JS component. However, it does not solve test 7.2.2 (updating an alternative in real time): <noscript> is only rendered when JS is disabled, not during dynamic execution.
How to verify that an alternative is properly updated for test 7.2.2?
Two methods: open the DOM inspector and observe the alt or aria-label attribute directly while the visual content changes. Or use NVDA in navigation mode: if the voice announcement still describes the previous state after the update, this is WCAG failure technique F20.