The WAVE browser extension is a practical way to check multilingual website accessibility before a translated page goes live. A translation can be accurate and still fail readers when its language is not identified, its form fields lose useful labels, or its new wording no longer fits the screen. This guide explains how to use WebAIM WAVE to inspect accessibility errors, contrast, page structure and text alternatives in real pages, then decide what needs human review.
For localization quality assurance, WAVE works best as a visual investigation tool rather than a compliance certificate. It places indicators alongside the rendered page, so an editor can connect a reported problem to the heading, link, image, field or navigation component a visitor encounters. That is particularly helpful when the same website exists in English, Arabic, Spanish, Japanese and other languages whose reading conventions and interface lengths differ.
To evaluate a translated website with WAVE, install the official browser extension, open the precise language version, run the report, review the Details and Structure views, investigate flagged elements, correct the source or localized content, and retest the same page state. The extension can inspect dynamic and private pages in the browser; it does not replace keyboard, screen-reader or user testing. The important question is not how many icons appear but whether people can find information and complete their tasks.
The useful answer in one minute
WAVE is a collection of accessibility evaluation tools developed by WebAIM. The browser extension runs in Chrome, Firefox and Edge. Unlike the public URL-based checker, the extension evaluates what is rendered in your browser, including pages that require a login or are assembled dynamically. WebAIM states that the extension’s evaluation happens locally in the browser rather than sending page content to its server. Check your organization’s extension-installation and data-handling policies before using any browser tool in a sensitive environment.
A sensible first pass covers five things. Confirm that the correct locale was loaded; inspect error and contrast indicators; examine headings and landmarks; assess images, links and form labels in context; and follow up with manual keyboard and assistive-technology testing. Treat green features as information, not proof that every user can navigate successfully. Treat alerts as questions that require judgment, not automatic failures. Record the exact page, locale, state, browser and finding so another person can reproduce the issue.
Why translation can create accessibility problems
Localization changes more than the words visible in a paragraph. It can alter a button label, a placeholder, an image, a title, an abbreviation, a language switcher or the relationship between instructions and controls. A German translation may occupy much more horizontal space than its English source. An Arabic version may change visual reading direction while leaving the logical source order untouched. A Japanese page may contain English brand names that require a different pronunciation. A translated form may move the visible question into a decorative heading while leaving the input without an associated programmatic label.
These differences matter because users do not interact with all pages in the same way. Some enlarge text, use a keyboard rather than a pointer, navigate by headings, hear spoken labels through a screen reader, or need plain instructions. A perfectly translated warning that appears only as a faint icon can remain inaccessible. An error message that says ‘invalid value’ without identifying the affected field forces readers to guess. Good translation quality therefore includes whether the audience can perceive, understand and operate the delivered interface.
WAVE can expose part of this gap, particularly when it highlights missing alternatives, labels, structural patterns and low-contrast text. It cannot judge whether a translation is idiomatic, whether a legal disclaimer is correct or whether the interface makes sense to an actual user. Pair the visual findings with linguistic review and task-based testing.
Set up the extension safely
Start at the official WAVE extensions page rather than downloading an unknown imitation. Choose the browser supported by the team and check the publisher. Install it in a testing profile if browser extensions are restricted on production workstations. For sensitive systems, obtain permission from the organization’s security or accessibility owner. Local processing is useful, but it does not excuse a team from following its own access controls.
Create a reproducible test setup. Record the browser and version, operating system, viewport, text zoom, locale, theme, login role and whether any consent banner or dialog is open. If a page uses an account, use a dedicated test account with synthetic information. Verify that translation strings and fonts have loaded fully. On an application that updates after a network request, wait until the content stabilizes before evaluating the screen.
Click the extension icon while the target page is open. The WAVE interface appears on the page and in its sidebar. If your browser offers a shortcut or context-menu action, it may be convenient, but the icon is the simplest documented entry point. Refreshing the page or triggering WAVE again can dismiss the overlay. Always check the original screen without the overlay afterward; an evaluator’s decorations are not part of the released user interface.
Build a baseline before interpreting icons
A baseline protects the team against confusing an old defect with a new localization regression. Begin with the source-language page and the same workflow in a translated locale. Use the same viewport and authentication state. Take a note of the page title, visible heading, active step and important controls. Do not compare a source-language home page with a translated checkout page and call the different issue totals a translation problem.
Consider a booking flow with English, French and Arabic versions. Open the confirmation step in each language, not merely the landing page. If the French version has a translated button but an unlabeled date picker, record the element and reproduction steps. If the Arabic version changes the card order, investigate whether the change was intentional, whether keyboard focus follows the intended sequence and whether the information remains comprehensible. A comparative baseline makes the discussion concrete.
The objective is to isolate the smallest problem that actually affects a person. Page-level counts are useful for prioritizing large inventories, but they should not be treated as a ranking of how accessible different languages are. A single unlabeled emergency action may matter more than many lower-impact alerts.
Understand the WAVE report categories
WAVE groups findings such as Errors, Contrast Errors, Alerts, Features, Structural Elements and ARIA indicators. Errors flag conditions that its rules can identify as accessibility problems. Contrast findings relate to text legibility. Alerts identify situations that deserve human examination. Features show accessibility-relevant characteristics of a page. Structure helps expose headings, regions and other semantic organization. ARIA indicators show related attributes and roles that can shape how assistive technologies understand the interface.
The category is not a substitute for context. A heading is a structural feature, but a heading can still be vague or mistranslated. An alternative text attribute may exist while describing the wrong image. An ARIA label can be syntactically present while repeating the same meaningless word on every button. An alert may reflect deliberate design that is acceptable after human inspection. Rather than clearing icons for their own sake, ask what the user receives from the element and how that can be tested.
Open each finding in the Details panel, then inspect its explanation and location. Use the Reference panel or WebAIM documentation to understand why a rule was triggered. When several identical icons arise from one shared component, the underlying defect may require a single component fix followed by retesting in every locale. When findings differ across locales, investigate content, direction, formatting and translation variables.
Check the document language first
A multilingual page should normally declare its primary human language accurately in the HTML language attribute. This informs pronunciation and other language-sensitive processing. A French page that still declares English can be read with unexpected pronunciation, even when the visible words are correctly translated. WAVE can help identify missing or invalid language declarations, but a valid code does not guarantee that the selected language matches the content.
Use language tags appropriate to the actual audience and script. A region subtag can be relevant when wording or formatting differs, while not every page needs one. Distinguish English content inside a Japanese page from the Japanese page as a whole. If there are meaningful passages in another language, examine whether they need a local language declaration. Product names, isolated proper nouns and technical identifiers may call for more nuanced judgment than an indiscriminate tag on every word.
In a bilingual help article, try moving through a sentence with a screen reader after checking the markup. Does the correct voice or pronunciation behavior occur, given the device’s available language voices? Does the page title identify the language and topic? WAVE identifies structural clues; direct reading tests expose the experience.
Inspect heading structure rather than just heading counts
Many readers scan translated pages by their headings. Screen-reader users may jump directly among headings, so the outline needs a coherent route. WAVE’s Structure view helps an editor see whether a page has an informative primary heading and logically nested sections. It can reveal a visually large section title implemented as ordinary text or an unexpected heading level inserted by a translation component.
Do not assume every document must have a perfect uninterrupted numerical sequence in every situation; the key test is whether the hierarchy accurately describes the relationships. In a troubleshooting guide, the major stages might be ‘Symptoms’, ‘Checks’ and ‘Repair’. Subheadings should describe the relevant task rather than repeat generic phrases such as ‘More information’ six times. A translation that removes the distinction between ‘Before installation’ and ‘After installation’ can turn a useful outline into a hazard.
Review headings in the actual language, not by comparing character counts. Some terms need a different natural word order. If a heading becomes too long to display on a narrow screen, solve the layout problem without deleting meaning. Re-run WAVE and navigate the heading list with an assistive technology to verify both structure and usefulness.
Examine landmarks and navigation
Landmarks such as navigation, main content and footer help readers jump around a site. WAVE can display these structural elements and make missing or unusual regions easier to investigate. A translated header may look correct while an entire menu is placed outside its intended navigation structure. Reused template fragments can also produce duplicate main regions or multiple identically labeled navigation areas.
Ask a practical question: if a person skips repeated navigation, where do they arrive? They should reach the meaningful main content rather than a decorative banner, repeated promotion or an untranslated introductory block. If a page has more than one navigation region, its accessible label may need to distinguish primary navigation from a language selector or in-page contents list. The text should be translated where appropriate and remain consistent across the site.
A language selector deserves particular care. Its accessible name should make its purpose understandable before a user opens it. Language names should be recognizable, and changes should not unexpectedly lose focus or erase unsaved form data. WAVE may flag structural aspects, but task testing is needed to confirm the switching journey.
Audit image alternatives as communication
An image’s text alternative is not a caption copied into a hidden field. It is a short, context-sensitive replacement for the information the image conveys. WAVE can flag images that lack alternatives, but cannot reliably determine whether existing alternatives communicate the right meaning. On a multilingual travel page, a photograph that illustrates a landmark may need a concise translated description. A decorative flourish may correctly have an empty alternative so it is skipped. A chart may need a brief alternative plus a longer explanation of its data.
Review what the image does in the specific page. If the image functions as a link, the alternative should usually communicate the destination or action. If the same image is accompanied by a complete textual description, repeating the whole description may create unnecessary noise. If text is embedded inside an image, a translated image file may be needed, and the alternative should still make its purpose accessible.
An especially common error occurs when the visual file changes by locale but the alternative remains from an earlier edition. Compare image content, caption, alternative text, destination and surrounding explanation. Never translate an alternative in isolation without checking what the updated image actually shows.
Review links and actions in context
A translated link can fail in two different ways: the destination may be wrong, or the name may be unhelpful. WAVE can identify certain empty or suspicious links, but ‘click here’ can remain technically valid while being poor navigation text. A user moving through a list of links should hear destinations such as ‘Download the French instructions’ or ‘Read the refund policy’, not a repetitive series of ‘Learn more’ labels.
For buttons, describe the action rather than the icon shape. A magnifier that opens search needs a clear search name; a trash icon that deletes a saved language setting needs an accurate destructive-action name. Translate accessible labels from the action’s actual purpose and confirm that the tooltip, visible text and spoken label do not conflict. If the button changes state, the changed state must be communicated appropriately.
Check the completed interaction. A button may be well labeled and still open an untranslated dialog, change focus unpredictably or deliver a validation message in another language. A WAVE report is a starting point for identifying the component, not a replacement for trying the flow.
Examine forms field by field
Forms combine visible prompts, programmatic labels, examples, help text, required-state information and error messages. Each component can be localized separately, which is why forms deserve their own audit. A form field with a translated placeholder but no proper label may appear understandable until the reader begins typing and the placeholder disappears. WAVE may identify missing or suspicious labels, but the human tester must check whether the correct question is associated with the correct input.
Imagine a shipping address form. A translator changes ‘State’ to a term appropriate to the destination country, but the backend still requires a US state abbreviation. That is a data-design conflict, not a translation typo. The label, accepted values, error message and help text must agree. A date field may display day/month/year while the validator assumes month/day/year. Check the actual task with valid and invalid sample entries.
Error messages should identify the affected field and explain the next action. They must not depend on color alone. Required status should be communicated beyond a red asterisk when necessary. After a failed submission, the user should be able to find, understand and correct errors without losing entered information.
Treat contrast findings as evidence, not decoration
WAVE can flag many low-contrast text situations and presents contrast-related information. Yet automatic calculation can be difficult over gradients, background images, transparency and changing states. Inspect the actual text against its real background in each locale, including hover, focus, disabled and error states where applicable. A translation may wrap onto a different background region or extend past a colored badge, changing the effective contrast.
WCAG contrast criteria distinguish ordinary text and large text; do not casually apply one threshold to everything. A design that passes in its default light theme may fail under dark theme or high-contrast settings. Likewise, a green success message may lose meaning for someone who does not distinguish the color. Pair text and meaningful icons with color where possible.
When a contrast warning appears, identify the computed foreground, background, text size and state before changing the palette. A rushed color change can harm other themes or brand contrast. In some cases the right fix is to move text away from a photographic background or add a solid backing, not simply darken every word.
What the Structure and Styles views can reveal
Removing styling temporarily can expose whether the content has an intelligible document order. The styled page may look like three well-organized columns, while its underlying order interleaves sections from different columns. On a right-to-left page, CSS can visually rearrange cards without fixing the reading sequence. The unstyled or structure-focused view helps locate these differences for subsequent manual testing.
Headings, lists and tables should use meaningful elements rather than visual tricks. A sequence of sentences separated by decorative bullets is not necessarily a list in the accessibility tree. A chart laid out using a table may produce confusing navigation. Translated tables can also reverse column presentation without preserving logical header relationships. WAVE may expose clues but a screen reader and keyboard are often required to judge the completed experience.
Do not treat the browser overlay’s rendering as the final authority on reading order. It is one useful view of the page. Cross-check with the document structure, actual tab progression and the spoken interface in the languages being supported.
Hidden components still need consideration
Menus, dialogs, accordions and tabs often begin hidden. WebAIM explains that WAVE can evaluate elements that are currently hidden, because those elements may become visible later. This can produce findings that confuse an editor who cannot see the referenced control in the initial screenshot. Rather than dismissing the finding, open the component in its intended state and examine its labels, focus behavior and content.
For a translated account menu, the initial closed state may pass while the expanded menu contains an untranslated label or a duplicate identifier. A dialog may contain correctly translated body text but have no accessible title. An accordion may announce its heading without indicating whether its panel is expanded. Test both closed and open states, including errors and success messages where relevant.
There are situations where an issue in permanently inaccessible content is not user-facing, but the team should document that judgment instead of simply suppressing all hidden-state findings. A future redesign may expose the same component.
Multilingual and right-to-left page checks
Arabic, Hebrew and other right-to-left interfaces need more than mirrored margins. The document direction, text direction, number runs, punctuation, icons, tables and keyboard progression should remain coherent. WAVE can help reveal structure, labels and some visual defects, but it cannot infer all intended bidirectional-text semantics. A visual reversal may be deliberate; a scrambled account number or amount is not.
Build a small test set containing addresses, decimal numbers, currency values, phone numbers, dates and names mixing scripts. Compare their visual order with copy-and-paste behavior and spoken output. Inspect buttons whose icon position changes with direction: a ‘next’ arrow may need mirroring, while a brand mark or media-play symbol may not. Long words in German, Thai line breaking and CJK fonts require different checks; language coverage should follow actual product audiences.
Do not create a blanket rule that every translated screen must look like the English screen. Preserve the meaning and task while respecting the locale’s reading conventions. WAVE identifies some accessibility problems; native-speaking testers should validate the language and expected conventions.
Dynamic interfaces and changing page states
Single-page applications can replace components without a full reload. A language switch may rewrite text, populate a result list, create an error banner or open a modal. Run WAVE against the relevant rendered state rather than assuming the first load covers everything. On a search page, evaluate the empty state, results state, no-results message and selected filter. On a checkout, check validation errors as well as confirmation.
If an error appears only after interaction, save enough detail to reproduce it: which button was pressed, which example input was used and which locale was active. Avoid using confidential production data in test records. Screenshots help locate visual issues, but written reproduction steps and programmatic element identifiers make them actionable to developers.
WAVE does not simulate all assistive-technology behaviors or judge whether an announced live update is timely. After investigating the visual structure, test keyboard focus, announcements and status feedback with relevant assistive technologies. An apparently clean report can coexist with a keyboard trap or a missing status announcement.
A practical review route for a translated landing page
First, open the exact localized landing page and confirm that its visible language, page title, primary heading and declared language agree. Next, inspect the WAVE Details view for high-confidence errors and contrast findings. Then review headings, landmarks, alt text and link names. Finally, use the keyboard to follow the main call to action into its destination.
Suppose an Italian product page has a beautiful translated hero banner but an image-only ‘Start free trial’ action. If the link’s accessible name is absent, the main conversion pathway is inaccessible to some users. Repair the link name in the shared component or locale resources, then confirm that it announces the action correctly in Italian. Retest the English page too, because shared code changes can affect every locale.
Record whether the problem is inherited from the template or introduced by translation. The distinction helps determine ownership: design system, frontend engineering, content or linguistic QA. It also prevents a localization team from being blamed for defects that predate the translated release.
A practical review route for an account settings screen
Account settings combine nested navigation, descriptive text, toggles and potentially sensitive actions. Open the translated account page in a test environment and evaluate the screen with WAVE. Check whether each toggle’s accessible name distinguishes the setting, whether its current state is communicated, and whether related instructions still refer to the correct control.
For a Portuguese locale, a generic ‘Activate’ label used for several switches may not tell a person which setting will change. A better name connects the action to the setting, while state announcement remains a separate concern. If the team uses a shared toggle component, check whether accessible names come from the same localization resources as visible labels or from an overlooked default string.
After fixes, use keyboard and screen-reader testing to operate the settings and confirm that the correct value was saved. The report alone cannot establish that a setting changed or that a confirmation is understandable.
Worked example: a bilingual health-information page
Imagine a public health information page with English explanations, an Urdu translation and embedded English technical terms. WAVE may show a correctly declared document language even when the English technical section lacks appropriate language handling. The editor should identify which passages need pronunciation consideration and which abbreviations can remain unchanged for professional accuracy.
Check whether charts contain explanatory text, whether alert banners are distinguishable without color and whether the main heading communicates the guidance’s purpose. A translated label that reverses ‘eligible’ and ‘not eligible’ is a semantic error invisible to WAVE and demands bilingual verification. A referral link with no accessible name is a structural problem that WAVE may reveal. The two reviews complement one another.
Use hypothetical data in demonstrations and follow the relevant organization’s clinical and privacy controls. Accessibility testing must never be used as a reason to expose sensitive records.
Worked example: government service eligibility
A local government form may offer multiple languages but require users to enter a fixed identifier. If the translated instructions say ‘reference number’ while the accessible label remains ‘application ID’, users may not realize the two terms refer to the same field. Compare visible label, accessible name, help text, examples and error messages. WAVE can direct attention to label associations, but terminology consistency needs editorial review.
Run the tool on the initial form, the validation-error screen and the review-and-submit screen. Test one valid synthetic identifier and one intentionally invalid one. If the submit button is disabled with no explanation, note that separately. An accessibility fix may involve clearer explanatory text and a more robust component state, not just a different string.
The final acceptance test is whether a person using assistive technology can complete the intended public-service task in the selected language.
Worked example: an e-commerce product variation
Consider a store with size, material and currency selectors. In the Spanish locale, a variant option may be visibly translated while the selector’s accessible label remains the English term ‘style’. WAVE may identify a missing label but not necessarily a misleading one. Compare the selected value announcement with the product specification and price display.
Try a long translated option that wraps onto two lines. Confirm that the text is visible at higher zoom and that the selection remains operable by keyboard. Open an out-of-stock variation and check whether its status is communicated without relying solely on a gray color. If the localized page uses a different currency, audit that the amount and currency symbol are clear and not confused by bidirectional formatting.
Retest cart and checkout, not only the product page, because selection meaning must survive the whole purchase path.
Worked example: travel booking dates and rooms
A hotel website may translate its booking labels but present a date picker built for English month names. WAVE can help find labels and page structure, yet it cannot tell whether a week starts on the correct local day or whether an ambiguous date such as 04/05/2027 is interpreted correctly. Inspect both the date field’s name and the rendered calendar’s navigation controls.
Use a scenario crossing a month boundary, select a date with the keyboard, move into room options and check the confirmation summary. If a required field errors, verify that the error is linked to the correct input. Large translation strings may obscure next-month buttons on small screens. A visually balanced English calendar is not evidence that the localized calendar works.
This case demonstrates why accessibility and internationalization tests should share a realistic user journey.
Worked example: an online course and quiz
An educational course may use H2 headings for lesson sections and visually bold paragraphs for quiz questions. WAVE’s structure display can reveal whether the interface treats those questions as ordinary paragraphs rather than labels or headings. The exact semantic solution depends on whether the item is a section, fieldset or interactive question. The reviewer should inspect the code and try it with a screen reader rather than inserting heading tags at random.
A translated multiple-choice question should preserve the relation between the prompt and its available answers. On submission, the feedback must identify the correct question and state what happened; a red border alone is inadequate. If the content includes a mathematical formula, reading the symbols correctly becomes a separate accessibility concern.
Test retry and progress states. A report from the course landing page cannot cover a timed quiz.
Worked example: a dashboard that mixes languages
A global logistics dashboard may show German navigation, English status codes, Japanese customer names and Arabic destination names. Treat each text type according to its role. Status codes may be invariant technical identifiers, while explanatory labels should follow the chosen language. WAVE’s indicators can expose missing labels and structure, but not decide whether a technical code was translated incorrectly.
Check charts, tables and status badges separately. Data-table headers must identify quantities and units; an untranslated header can make an otherwise correct number ambiguous. If a color carries alert meaning, add an intelligible text status. Test a narrow viewport where translated labels wrap and columns scroll. Check focus order through the table and any popover explanations.
A successful audit preserves operational identity: a shipment reference must not change merely because the display language changes.
Worked example: consent and privacy controls
A cookie or privacy-choice panel often appears before the main page. It may be visually polished in every locale yet have ambiguous button names, broken focus handling or options that are difficult to compare. Run WAVE while the panel is open. Inspect button labels, heading structure, contrast, form controls and the relationship between explanatory text and choices.
Translate consent choices without changing their legal meaning. ‘Accept selected’, ‘Reject optional’ and ‘Save preferences’ are different actions and should not collapse into one vague term. The evaluator must also verify that the selection actually works and that a user can leave the dialog with the keyboard. WAVE cannot tell whether the choice was recorded accurately or whether the policy text reflects local law.
A good test record preserves both the linguistic and functional findings without storing real visitor consent data.
Worked example: a right-to-left navigation drawer
In an Arabic mobile layout, the menu drawer may open from the right while its links remain in the correct logical reading order. Another implementation may merely reverse the visual column with CSS. These two designs may look identical in a screenshot yet behave differently for keyboard and assistive-technology users. WAVE’s structure clues can suggest where to investigate, but focus progression and spoken navigation must be tested directly.
Open the drawer, move through all links and nested items, switch language and return. Check that closing the drawer returns focus to a sensible place. Verify that numerals, abbreviations and mixed-script labels remain understandable. Record the precise bad transition, not just ‘RTL broken’. This gives engineers a reproducible input and keeps the localization discussion focused on reader impact.
Worked example: documents linked from a web page
A web page may offer translated PDFs and audio files. WAVE can check the accessibility of the HTML link surrounding each download, not the full accessibility of the downloaded file. A link named ‘Spanish guide, PDF’ can help readers decide what to open, but the PDF must also be evaluated for tags, reading order, language metadata and contrast through appropriate document-specific tools.
Ensure that link labels distinguish the language, format and purpose without becoming painfully long. When versions differ, a visible revision date or document identifier can prevent users from opening an outdated translation. Check that the file opens correctly and that the linked target actually matches its advertised language.
Do not declare the whole publication accessible because the web page’s WAVE report looks clean. The linked artifact has its own accessibility and content quality requirements.
Worked example: accessible error recovery
A translated registration page can have accurately labeled fields on its first load and still fail completely during error recovery. Trigger a synthetic invalid password, an email formatting error and a missing required field. Run WAVE after the errors appear, then inspect headings, status message, field relationships and contrast. Determine whether each error tells the user what to fix without exposing confidential information.
Keyboard navigation should make it possible to reach the errors and return to their fields. A screen reader should communicate the changed state at an appropriate time. The localized message should avoid vague blame and should not translate technical placeholders as if they were ordinary prose. For example, a sample email address stays an example; it should not become an instruction to enter someone else’s account.
Repeat after corrections to confirm that success feedback is understandable and focus is not lost.
Prioritize fixes by human impact
Start with issues that block essential tasks: missing accessible names on primary controls, broken forms, unreachable navigation, unreadable text and incorrect language delivery. Next address structural inconsistencies that create confusion or unnecessary effort. Record low-risk cosmetic items too, but do not let an easy icon-count reduction displace repair of a severe barrier.
Use a simple evidence record: locale and URL, page state, affected control, observation, expected behavior, reproduction steps, responsible team and retest result. If a component is shared across languages, note that a single fix may need regression checks in many locales. If a translator can correct a text alternative in the content system, distinguish that from a code defect requiring engineering.
A release decision is not a universal numerical threshold from WAVE. It is a documented judgment about whether remaining barriers are acceptable for the purpose, audience and applicable accessibility requirements.
Hand findings to translators and developers without confusion
A report that says ‘WAVE found 17 errors’ is rarely enough. Tell the developer which element is affected, what a visitor experiences and how to reproduce it. Tell the translator which actual string, context and locale need revision. Provide a screenshot and a short description when useful, but also preserve the underlying test route for someone who cannot rely on screenshots.
Separate language issues from semantic HTML issues. If an image’s alternative says ‘decorative blue pattern’ but the image is now a flowchart, the fix is editorial and perhaps structural. If a visible field prompt has no programmatic association, the component needs repair. If a heading has the wrong translated meaning, a native-speaking reviewer must own that correction. Assigning the right owner reduces rework.
Once fixed, re-run WAVE, compare the same screen states and perform a direct keyboard or screen-reader confirmation. Avoid treating ‘no errors displayed’ as a universal certificate.
Ten questions readers often ask
Is WAVE free, and does it require an account?
The public checker and browser extensions are available through WebAIM. Consult the current official site for product terms and any paid API or enterprise services. The browser extension can be used directly on a page without relying on a WAVE server evaluation for that page. Enterprise settings and browser policies can affect whether installation is allowed, so confirm local permission before testing a protected environment.
Does a green report mean a translated page meets WCAG?
No. WAVE reports findings from its rules and helps a human inspect a page. Many meaningful requirements cannot be established by automated inspection, including whether instructions make sense, whether all keyboard workflows function, and whether translated text is accurate. A clean automated result is one piece of evidence, not a conformance claim. Manual evaluation and relevant assistive-technology testing remain necessary.
Can WAVE check a password-protected dashboard?
The browser extension is designed to inspect the page as rendered in your browser, which can include authenticated and dynamically generated content. Use authorized test accounts and synthetic data. Keep test screenshots and exported findings inside approved systems. A private site may still be subject to the organization’s information-security policies even when the extension does not transmit page content to the WAVE server.
Can WAVE tell whether a language translation is correct?
No. It cannot validate factual meaning, cultural suitability or the consistency of legal and technical terms. It can help locate structural and accessibility defects that affect how translated content is delivered. A native-speaking subject reviewer should assess the words, while technical reviewers assess names, focus, semantic relationships and interaction. Both roles are needed for multilingual release quality.
Why do some alerts appear on visually hidden items?
WAVE evaluates some hidden elements because they may become visible when a menu opens or a dialog appears. Open the intended component state and investigate whether a user can encounter the issue. If an element truly never becomes available, document the rationale for treating a particular finding as not applicable. Avoid dismissing every hidden-element alert merely because it is absent from the first screenshot.
Should every image have a descriptive alt attribute?
Every image needs an appropriate text-alternative decision, not necessarily a long spoken description. Informative images generally need meaningful alternatives. Purely decorative images may have empty alternatives so they are skipped. Linked images need names that communicate their action. The right decision depends on what the image contributes in that specific page and language.
Does WAVE test keyboard traps and focus order?
It can reveal useful structural clues, but direct keyboard testing is essential to determine whether a person can enter, move through and leave interactive components. Try menus, dialogs, forms, calendars and error states using the keyboard alone. Use screen-reader testing where appropriate. Another tool’s assisted tab-stop visualization may complement WAVE, but neither should replace trying realistic tasks.
How should a team compare ten language versions?
Choose representative templates and high-risk journeys, then run a consistent test matrix that records locale, page state, browser and result. Include languages with long words, non-Latin scripts and right-to-left direction where supported. Check shared components across all versions and conduct deeper linguistic review in each language. Avoid comparing only total issue counts; inspect the severity and origin of individual defects.
Can WAVE evaluate an accessible PDF or EPUB?
WAVE is primarily for evaluating web content. It can assess the web page that links to a document, but a PDF, EPUB or other publication needs its own specialist tests for document structure, reading order, language and navigation. The reader’s end-to-end experience includes the file after download, so audit that artifact separately and make sure its link describes the actual document.
What is the final release check?
Repeat the exact affected user journey in the target language after fixes. Confirm the intended content, heading structure, form associations, link names, contrast, keyboard navigation and screen-reader behavior. Record unresolved limitations with owners and decisions. Treat the WAVE report as evidence of an investigation, not the final decision itself.
Official references and related learning
The primary references are WebAIM’s WAVE browser extensions, the WAVE help and interpretation guide and the WebAIM evaluation guide. For the normative accessibility principles, use the current W3C WCAG materials rather than treating a tool’s colored icons as a standard.
For complementary workflows on eduKateSG, read axe-core CLI accessibility rules, Pa11y CLI reporting and NVDA screen-reader testing. WAVE’s distinctive strength is making issues visible in their actual page context; the other guides address command-line reporting and direct user-experience validation. An accessible translation is one that readers can genuinely use, not merely one that passes a scan.