A Fortune 500 Accessibility Audit Identified the Issues. Implementing Them Across Six Languages Was the Real Work.

The Situation

The client owned three domains: a primary corporate site and two supporting properties serving distinct business functions. Each was published in six languages. The audit had been performed against all three.

The findings spanned the surface area you would expect at this scale: contrast failures inside brand-owned colour tokens, interactive components without keyboard or screen reader support, forms with missing programmatic labels and silent error states, carousels that played without controls, video without captions, and a long list of third-party embeds (PDFs, maps, and other inserted content) that arrived on the page without any accessibility scaffolding around them.

None of the individual issues were exotic. What made the remediation work substantial was the combination they sat inside. A Fortune 500 web presence with brand tokens that could not be casually edited. Three connected domains. Six language versions of every fix. And a meaningful portion of the interactive surface rendered through React components.

Why Remediation Was the Hard Part

An audit is a static document. Remediation is the part that has to ship. On a multilingual estate with this kind of reach, that distinction matters.

Brand-owned colour and contrast tokens

Several contrast failures sat inside colour tokens that were part of the client's global brand system. We could not unilaterally darken a brand colour. Each contrast adjustment had to be resolved at the usage layer (changing the background a token sat on, increasing font weight, switching to a different approved token, adjusting state colours for links, buttons, and focus) or escalated to the brand owners for an approved tonal variant.

This part of the work was as much coordination as code. Each proposed change went through brand review before reaching the staging environment.

React-rendered interactive components

The most demanding piece of the remediation was the interactive layer rendered through React. These components had been built for visual behaviour first and accessibility second. Roles were missing or wrong, state changes were not announced, focus was lost on re-render, and keyboard interaction worked partially or not at all depending on which sub-component was active.

Each component needed a real rebuild of its accessibility model. Roles, names, and states declared correctly. Focus surviving re-renders and routing back to a sensible place when modals, drawers, and overlays closed. State changes that mattered to a screen reader user (selections, expansions, errors, loading) announced through live regions without flooding them. None of this could be applied uniformly across components because each one had its own state model.

Dropdowns, forms, and error states

Forms across all three domains relied on a mix of native and custom dropdown controls. Native selects worked. The custom dropdowns, the styled ones the design system preferred, were the ones flagged by the audit. They needed correct roles, keyboard operation, programmatic state, and accessible names that flowed through the translation pipeline.

The error-state work was equally material. Failing fields needed programmatic association between the error message and the input, the message itself had to be announced when it appeared, and required-field status had to be exposed correctly rather than left as a visual asterisk. Each fix was translated and verified across all six locales.

Carousels and slideshows

The carousels on the site autoplayed, did not expose a pause control to assistive technology, did not handle keyboard navigation cleanly, and lost focus when slides changed. Each of these is an individual fix in isolation. Together, they meant the carousel components had to be re-architected, not just patched. Pause and play controls exposed properly. Slide changes announced where it mattered. Focus managed when users interacted with controls. Reduced-motion preferences respected.

Embedded content: video, PDFs, and maps

A meaningful portion of the page content was not owned by the client's sites at all. Videos were embedded from external players. PDFs were either linked or embedded inside iframes. Maps were embedded from a third-party provider. The source documents could not be edited as part of the engagement.

What could be fixed was the embedding itself. Videos were configured to load with captions available and player controls exposed to assistive technology. PDF links and embeds were rewritten so the purpose, file type, and behaviour were clear to a screen reader user before the link was activated, with proper iframe titles where PDFs were displayed inline. Map embeds received accessible names, were taken out of the keyboard tab order where they trapped focus, and were paired with text-based alternatives (address, directions, contact) so the underlying information was reachable without the map widget itself being usable.

Images across six languages

Alt text gaps were spread across the asset library, and they were not symmetrical between language versions. Some images had alt text in English and nothing in the other five locales. Others were decorative on some pages and meaningful on others. Closing this required a per-locale pass, not a single global change.

Six language versions of every fix

Every accessible name, helper text string, error message, and announcement we introduced during the project had to exist in all six languages. Hardcoded English strings were not an option. Each new label and message was routed through the translation pipeline, registered in the site's translation memory, and verified in every locale before the fix was considered shipped.

Working across development, staging, and production

The team had a development environment, a staging environment, and production. Each change moved through that pipeline before reaching live users, which removed the risk of shipping a broken fix into a Fortune 500 web presence directly. What it did not remove was the locale multiplication. A fix that passed verification in English on staging still had to be checked in German, where compound words ran longer and could wrap where they did not in English, and in each of the other four locales. Promotion to production was paced so that no business unit was caught out by a layout shift in their language.

The Gap Between the Audit and the Work

The audit document listed issues. It did not say, for each issue, which of the three domains it appeared on, which of the six languages it affected, which component generated it, or what the downstream consequences of fixing it would be. Building that mapping was the first piece of real work.

Some audit findings, written generically, turned out to be a single shared component used in dozens of places. Fixing the component fixed every instance. Other findings, written as a single issue, were actually six instances (one per language) because the translated DOM diverged from the source in ways the audit had not captured. The audit's count of issues and the count of actual fixes did not match in either direction.

We rebuilt the issue list as a remediation plan organised by template, component, embed type, and locale. Fixes that could be made at the code layer were separated from those that required translation work, brand approval, or third-party embed configuration. That plan was what the rest of the engagement worked from.

What We Did

The work moved in tracks that ran in parallel where they could and serialised where they could not. Each track was scoped, executed, verified across all six locales on staging, and promoted to production before the next batch began.

Colour and contrast adjustments

Contrast failures were resolved through usage-layer changes wherever possible, and through brand-approved tonal variants where a token itself had to change. Focus, hover, disabled, and error states across links, buttons, and form fields were brought up to conformance, with the brand team signing off on each change before it shipped.

React component rebuilds

The interactive components rendered through React were the most concentrated body of work. Each component received a proper accessibility model: roles, accessible names, states, keyboard operation, focus management on mount and unmount, and announcements for the state changes that mattered to a screen reader user. Components were tested both in isolation and inside the pages that used them.

Forms and dropdowns

Forms across all three domains were rebuilt to associate labels programmatically with their inputs, expose required-field status correctly, announce errors when they appeared, and provide error text that screen readers could associate with the failing field. Custom dropdowns received correct roles, keyboard handling, and accessible names. Native dropdowns were left in place where they already worked.

Carousels and slideshows

Carousel components were re-architected to expose pause and play controls, support keyboard navigation, manage focus when slides changed, and respect reduced-motion preferences. Autoplay behaviour was reviewed against the requirement that users have meaningful control over moving content.

Video accessibility

Embedded video was configured to load with captions available and player controls exposed to assistive technology. Where videos were used to convey information not available elsewhere on the page, the embedding was paired with a textual fallback.

PDF, map, and other embed remediation

PDFs were not edited at the source. What changed was the way they were referenced from the sites: link text describing the document and its file type, iframe titles where PDFs were embedded inline, and clear indication of behaviour before the link was activated. Map embeds received accessible names, were prevented from trapping keyboard focus, and were paired with text-based alternatives so the underlying information was reachable without the map widget.

Image and alt text coverage

The asset library was reviewed per locale. Missing alt text was added in each language, decorative images were marked correctly, and image variants that differed between language versions received translated alt text rather than a default fallback.

Translation pipeline updates

Every new accessible name, helper text, and announcement introduced during remediation was translated into all six languages and registered in the site's translation memory. Nothing was left as a hardcoded English string. The pipeline was extended so future content and feature work would inherit the same coverage.

Cross-locale verification

Every change went through a verification pass on staging in all six languages before being promoted to production. Automated tooling caught the structural failures (contrast, missing attributes, broken hierarchies). Manual testing covered the parts that required judgement: keyboard flow through React components, announcements firing at the right moment, error handling in real forms, and embed behaviour for video, PDFs, and maps.

The Outcome

All three domains reached conformance across all six languages within the engagement window. The brand system remained intact. The translation pipeline was extended cleanly to cover the new accessibility surface. No business unit experienced a regression in their language during the rollout.

The internal documentation produced during the project (the remediation plan, the per-locale verification notes, the component-level guidance) was handed back to the client's web and brand teams so future content and feature work would stay inside the conformance envelope rather than drifting back out of it.

What This Means for Multilingual Enterprise Sites

If you run a multilingual web estate at enterprise scale, the patterns that made this engagement substantial are likely already present in your environment.

The audit is the start of the work

A WCAG audit identifies issues. It does not tell you which component generates them, which language variants are affected, which fixes require brand approval, or which fixes will ripple through translation. Building that map is its own piece of work and is usually where remediation projects stall.

Multilingual makes every fix wider

A single accessibility fix on a monolingual site is one change. The same fix on a six-language site can be six changes, each with its own translation, layout, and verification requirements. Scoping accessibility work without accounting for locale multiplication is how timelines slip.

Custom React components carry most of the work

Custom interactive components rendered through React rarely behave correctly for assistive technology without a deliberate rebuild. Surface patches do not solve focus loss on re-render, missing state announcements, or broken keyboard models. The component has to be reworked, which is a different cost profile to fixing static markup.

Brand sign-off has to be in scope from the start

Contrast failures often live inside brand-owned colour tokens. Remediation that does not include the brand team in the loop either ships changes the brand will later roll back, or stalls indefinitely waiting for approval that was never requested correctly.

You can fix the embedding when you cannot fix the source

Videos, PDFs, and maps that arrive on the page from third-party sources often cannot be edited at the source. What can be fixed is the way they are embedded: link text, iframe titles, focus behaviour, and text-based alternatives that put the underlying information within reach of someone who cannot use the widget itself.

Conformance drifts without ongoing ownership

A site reaches conformance and then drifts out of it the next time a new feature ships, a new template is added, or a new piece of content is published without translation coverage on its accessible names. The handover documentation is what determines whether the work holds.