ANDI, the Accessible Name & Description Inspector, is a free browser-based accessibility testing tool created by the U.S. Social Security Administration. For a translated website, it helps a reviewer inspect what interactive controls are called, whether forms convey useful instructions, and whether headings, links, tables and images make sense beyond their visible appearance. This guide explains how to use ANDI for multilingual accessibility testing without confusing a detected alert with a complete assessment of the user experience.
If you are looking for an ANDI accessibility testing tutorial, start with the page and language that your users actually encounter. A translated registration form can look polished while a button still announces its English internal label; a German navigation menu can visually fit while its accessible name contains a stale placeholder; and an Arabic interface can have attractive right-to-left layout without sensible keyboard focus order. ANDI helps expose these issues for closer investigation.
This practical guide covers installing the ANDI bookmarklet, inspecting accessible names and descriptions, using its focused modules, interpreting page analysis and alerts, and building reproducible evidence for localization teams. It includes applied examples across language switching, data tables, error messages, hidden panels, images, landmarks and multilingual release testing. No single automated tool certifies WCAG conformance or guarantees that a translated interface is understandable; that conclusion requires human testing as well.
- Start with a real task in a named locale rather than scanning an abstract homepage.
- Inspect ANDI Output and the components that produced an accessible name or description.
- Move between focusable elements, graphics, links, tables, structures, contrast, hidden content and frames using the appropriate module.
- Compare visible language, accessible language, instructions, keyboard behavior and the outcome of the task.
- Record precise defects with build, route, element, steps, expected result and actual result.
- Retest after repair with the same language and state; add screen-reader and native-speaker review where needed.
What ANDI is, and what it is not
ANDI is a browser bookmarklet, sometimes called a favelet. After adding it to the bookmarks toolbar, you open the page under test and activate the bookmark. Its on-page interface analyzes the current document, highlights relevant elements, reports accessibility information and offers modules for specific areas of inspection. This is especially useful for reviewers who want a guided view of the page rather than reading every attribute manually in browser developer tools.
The central feature is not simply an error count. ANDI helps show the calculated accessibility output for an element and the components contributing to that output. A button may receive a name from its visible text, an associated label, an ARIA label or another relationship. A translator needs to know which source actually reaches assistive technology; correcting a visible label alone may leave a different accessible string unchanged.
ANDI does not replace browser accessibility trees, real screen readers, keyboard testing, a WCAG evaluation methodology or linguistic review. A correctly named element can still be in the wrong order, call the wrong action or communicate a mistranslation. A warning can indicate a useful investigation rather than a proven failure. A clean panel is a starting point for evidence, never a blanket release certificate.
Its scope is important. A single run reflects the page and state accessible to the tool at that moment. If a menu is closed, a modal has not appeared, or a translated error message is only displayed after submission, you have not tested that state. Dynamic web applications, frames, shadow DOM, scripts and altered page structure introduce further limitations. Keep a human test path alongside every automated inspection.
Install the bookmarklet safely
Open the official ANDI installation page at https://www.ssa.gov/accessibility/andi/ and use its installation instructions. The site offers a draggable bookmarklet for desktop browsers and explains how to show the bookmarks bar when necessary. Save the tool in a testing profile that you control; avoid following unofficial copies of its bookmark code through search results or copying scripts from untrusted pages.
Navigate to a page you are authorized to test. Choose a public or controlled staging route in the intended language, wait for the actual user-facing state, and activate ANDI. The analysis interface appears on the page. If the interface does not load, first check browser restrictions, page content-security policy, extension interference and whether JavaScript or the testing environment blocks bookmarklets. A failed injection is not a finding about the page’s accessibility.
When working with sensitive information, prefer a safe staging fixture over a production account full of personal data. Record screenshots only after masking customer names, addresses, financial details and session tokens. Store page URLs carefully; even a URL parameter may contain account information. For a multinational team, decide in advance whether test evidence can cross borders or must stay in a local approved repository.
ANDI’s official documentation notes that the bookmarklet updates itself. The user still needs to verify that the tool opens correctly in the chosen browser and that its output corresponds to the current interface. If the tool and the site conflict, make a separate developer-tools observation rather than forcing a diagnosis based on a broken overlay.
Understand the basic inspection interface
The default focusable-elements analysis concentrates on interactive controls. As you inspect an element, look at the ANDI Output, the component information and the page-analysis alerts. Do not reduce these separate areas to a single pass or fail. The output gives a reason to investigate how the control will be announced; an alert points to a possible problem; the rendered page tells you what the user sees and can manipulate.
Use previous and next element navigation to walk through a flow deliberately. The highlighted element should correspond to the control a user encounters when moving through the page. When an accessible name differs from the visible wording, identify the naming source before deciding which translation file to edit. An ARIA attribute added by a component library can override content supplied through the normal text resource bundle.
Try the tab-order indicators where applicable, then run an actual keyboard journey. An indicator reveals an order calculated from the page, but it does not prove a keyboard user can operate a menu, dismiss a dialog or recover after a locale switch. Test Tab, Shift+Tab, Enter, Space and Escape according to the control’s expected behavior. Document any mismatch between visual order, focus movement and task progression.
A reviewer should be able to explain why each observation matters. Instead of writing ‘ANDI shows an alert,’ describe the user consequence: ‘The account-settings button has no accessible name in the Spanish route, so a screen-reader user hears a generic button and cannot distinguish it from the adjacent security control.’ The second statement is actionable because it identifies a user task and a missing meaning.
Accessible names: inspect the actual announced identity
An accessible name answers a basic question: what is this control? It may come from visible content, a programmatic label, a referenced element or another naming mechanism governed by accessibility specifications. Names should communicate the same essential action or purpose as their visible counterparts. Translation quality therefore depends on the accessible naming path, not merely the screen text.
Consider a page with a French visible button reading ‘Enregistrer’ while its aria-label says ‘Delete record’. The button might operate correctly, but its name tells some users to expect a destructive action. ANDI can make this discrepancy easier to locate. The repair is to choose one truthful action, correct the language resources and ensure the programmatic name and visible wording agree.
For icon-only controls, a meaningful localized name is indispensable. A magnifying-glass icon might mean search, zoom or inspect depending on context. ‘Icon’ and ‘button’ are not adequate labels for a search control. Test the button inside the actual dialogue or toolbar, not as a detached component: ‘Search products’ and ‘Search this document’ are different user intentions.
Do not assume that adding aria-label is always the best fix. Native buttons with clear visible text often already have appropriate names. Extra ARIA can introduce duplicate, misleading or out-of-sync translations. Inspect the components used in the name calculation, preserve visible words when possible, and use programmatic labels when the interface genuinely needs them. The accessible name should remain stable enough for recognition while accurately reflecting changes in state.
Descriptions, instructions and errors
The accessible description adds information beyond the name, such as a format requirement or help text. A name like ‘Date of birth’ can be correct but insufficient when an unfamiliar locale expects a specific input format. In a Japanese form, the example might use a year–month–day convention; in another market, the visual sample could use day–month–year. The accessible explanation must agree with the displayed example and the accepted input.
Use ANDI to examine relationships that contribute to descriptions, including references from instructions and error messages. Then submit the form with a known invalid value. Many sites only render the error state after validation. A complete test must inspect the field before submission, after the error appears, after correction and after the user moves away. Error text should identify what failed and how to repair it, in the same language as the form.
An error like ‘Invalid input’ may be technically announced but is educationally weak. ‘Enter the postal code using five digits’ is much more useful when that is the actual requirement. Translate the condition, not only the phrase. If countries on the same site accept different postal-code formats, derive the message from the relevant locale and business rule; never hard-code one market’s format into all languages.
Avoid automatically focusing every error without considering the task. A well-designed form may use an error summary, field-level feedback, live announcements and focus management together. ANDI can help inspect names and relationships; a screen reader and keyboard session determine whether the complete interaction is understandable, timely and recoverable.
Links and buttons are different promises
Use the links-and-buttons module to review interactive wording, duplicates and differences in accessible names. A link normally promises navigation to a destination; a button normally promises an action in the current interface. Localization can blur that distinction when a short translation turns ‘View policy’ into ‘Submit policy’ or hides the destination behind a generic ‘Click here’.
Two links called ‘More information’ can be acceptable if context makes their destinations clear, but repeated ambiguous links across a card grid are difficult to navigate out of context. Review what a user learns from a list of links. A localized link should indicate its destination or object when that distinction affects choice: ‘Read shipping policy’, ‘Read returns policy’ and ‘Read warranty terms’ each make a different promise.
Test translated link destinations as well as names. A Spanish-label link that opens an English document may be an intentional fallback, but users should not be surprised. A link can have a correct accessible name and still direct people to an unavailable, regionalized or unauthenticated route. Note the expected language, actual destination, any document language and the fallback explanation.
If a link opens a new tab or downloads a file, make that behavior predictable where it matters. Avoid flooding every name with repetitive announcements, yet do not hide consequential behavior. ANDI helps inspect the name; browser behavior and actual navigation determine whether the translated experience matches the promise.
Tables: test meaning one cell at a time
The table module, tANDI, examines one table at a time. This design is valuable because the difficult part of a table is not whether it looks aligned. It is whether a data cell can be associated with the right row and column headers. Open the target table, inspect header relationships and move through cells to see the information the table structure is making available.
Imagine a multilingual shipping-rate table with rows for regions and columns for standard, express and overnight service. A screen reader must connect a price to both a region and a service level. If a translated header is visually placed over the wrong column, the data becomes misleading. If markup relies only on spacing and bold text, the association may not exist for assistive technology.
Review colspan, rowspan, nested headings and stacked headers deliberately. Complex tables may require explicit identifiers and references. Check whether translations have caused a heading to wrap in a way that visually suggests the wrong association. A table can pass a structural rule while using a false unit, such as pounds instead of kilograms, so the linguistic and quantitative review must accompany the markup review.
Use the table list and navigation controls to inspect every important data table, not just the first one ANDI presents. Record the row label, column label, cell value and expected relationship. For financial and medical tables, require a second reviewer to confirm units, decimal separators and the interpretation of ranges before publication.
Structures: headings, landmarks and language
The structures module helps review headings, landmarks, lists and related page organization. A heading is useful because it announces a new subject and enables navigation; it is not simply text styled in a large font. Translate it for the reader and preserve the hierarchy that explains how sections fit together. A French ‘Conditions’ heading used for an eligibility block should not become a vague ‘Information’ heading that destroys useful navigation.
Landmarks such as main, navigation and search help readers bypass repeated content. A product may contain both global navigation and a local documentation menu, so names sometimes need to distinguish them. If the app has two ‘Navigation’ landmarks, consider whether ‘Main navigation’ and ‘Help navigation’ would more accurately describe the choices in the current language.
Language metadata matters at the page and component level. A route declared as English while its body is Arabic may cause inappropriate speech pronunciation or navigation. When a genuine quotation, product name or phrase uses another language, the correct markup may identify that span rather than changing the whole page. ANDI’s structure inspection helps flag opportunities; verify rendered language, DOM metadata and speech behavior directly.
Right-to-left layout is a separate issue. The Arabic or Hebrew reading experience can have correct language tags but wrong visual ordering of mixed numbers, phone numbers or abbreviations. Inspect directionality and punctuation with actual representative content. Do not assume that flipping a flexbox row makes dates, addresses and embedded codes understandable.
Graphics and image alternatives
The graphics module, gANDI, helps distinguish meaningful images from decorative images and inspect alternative-text issues. A localized product chart may contain words in the bitmap that do not exist in the HTML. A translated label outside the image is not enough if the chart conveys an additional relationship, trend or decision. Decide what information the image contributes to the task, then provide an appropriate text equivalent.
An image of a red warning triangle beside a fully explicit sentence may be decorative. A flowchart that shows approval moving from manager to finance requires meaningful alternative information or an adjacent accessible explanation. Avoid mechanically translating a file name into alt text. The goal is equivalent meaning, not an inventory of visible pixels.
When a linked image acts as a control, its accessible name should express the destination or action. ‘Logo’ is generally weaker than an accurate organization or home-page identity when that is the link’s purpose. For international brands, preserve approved names and scripts while considering local pronunciation and familiarity. If logos contain embedded text, document whether the local edition uses a localized asset.
Test images at text zoom and narrow viewport widths. Meaningful captions can disappear in responsive layouts; alternative text is not a substitute for preserving essential visible labels. Use gANDI as one inspection tool alongside the content owner who understands what the original graphic was intended to teach.
Contrast and visual state
The color-contrast module can help identify candidates for closer investigation. Contrast is not a general aesthetic preference; it influences whether readers can distinguish text, icons, boundaries and states. Measure actual foreground and background combinations. A gradient, transparent overlay or text on a photograph may produce more than one contrast result across the same element.
WCAG 2.2 Level AA normally requires a ratio of at least 4.5:1 for ordinary text and 3:1 for qualifying large text; relevant non-text graphical and interface boundaries are generally assessed against 3:1 where the criterion applies. Different exclusions and definitions matter. A tool result must be read with the applicable criterion and actual rendered size in mind.
Localization can expose contrast bugs that were absent in the source-language design. Longer translated text may wrap onto a lighter part of a background image. A newly added status label may inherit a disabled-looking color despite remaining interactive. A different font can have thin strokes that are harder to perceive even when a numeric ratio is unchanged.
Inspect hover, focus, active, disabled, warning and error states rather than sampling only the page at rest. For difficult visual combinations, use a dedicated contrast measurement tool and keep the actual sampled colors as evidence. ANDI can direct attention to suspicious elements, but it cannot decide whether the content and state communication are sufficiently clear to every reader.
Hidden content, overlays and frames
Hidden content is a frequent source of multilingual defects. A collapsed accordion can contain an untranslated answer or a stale instruction that becomes visible only after interaction. Use the hidden-content module to understand what exists in the document and how it is exposed. Then activate the component as an ordinary keyboard or screen-reader user would.
A modal dialog introduces a different set of checks. Its accessible name, description, focus placement, focus containment and close action all matter. A translated ‘Cancel’ button must not become ambiguous beside a destructive action. When the dialog closes, focus should return to a sensible place so that a user does not have to restart navigation from the top of the page.
Frames may contain content from a different product or vendor. The frame itself needs an intelligible identity where applicable, and its internal language, forms and keyboard behavior require separate testing. A payment widget in English inside a Portuguese checkout may be intentional or a serious localization gap. Record the responsible component owner before assigning a fix.
Shadow DOM and application-driven updates can make some automated observations incomplete. If a component is invisible to the inspection tool, use developer tools and a real assistive technology session. ‘Not inspected’ must never be silently reported as ‘passed’. Reproducible evidence includes the browser, component state and any relevant loading or authentication conditions.
A practical multilingual test matrix
Build a small but meaningful matrix before scanning. Choose source and target languages that differ in text length, script direction, morphology and input conventions. For example, a sample might include English, German, Arabic and Japanese. Those are examples, not a universal requirement: actual market languages and product risks determine the selection.
Include at least one public page, one account-based journey, one form with an error, one data-heavy page and one dynamic control. Mark the device and browser used for each. Where a page has country variants, check whether amounts, measurement units, names and contact methods are localized consistently rather than assuming a shared language implies a shared market.
Keep design changes and translation changes distinguishable. If the German release uses an updated component library while the English release uses an older one, a difference in accessible naming may come from the library version. Store the build identifier and compare like with like. A misleading defect report can send translators to change a string when a developer must correct markup.
Use a second pass to review fixes rather than treating the first scanner result as complete. Retest the specific failing element, its neighboring controls and a realistic end-to-end task. Close a ticket only when the defect is fixed for the named locale and state, and clearly state what other locales remain untested.
Applied case 1: Language switcher
The visible switcher lists English, العربية and 日本語, but its icon-only trigger is announced as ‘globe’. The reviewer opens the target route and inspects the trigger with ANDI, then tests the keyboard sequence. A useful name could express ‘Choose language’ in the interface language. The expanded choices should identify languages unambiguously, and focus should behave predictably after selection. Check whether the current selection is communicated without forcing a user to infer it from the address bar. Record the old and new route, the spoken names, the selected state and the restored focus position.
Applied case 2: Search icon in a product catalogue
A magnifying-glass button is visually recognizable, yet the accessible name on the Korean route remains ‘Open filter’. ANDI reveals the component’s naming source. Do not simply change every occurrence of the word ‘filter’; the icon may be shared with a different control elsewhere. Identify the exact component and translation key. After repair, activate search with keyboard and screen reader, confirm that the input receives focus, and make sure the results heading identifies the query. The practical success condition is finding a product, not seeing a green scan panel.
Applied case 3: Required field in a registration form
A Spanish form displays an asterisk but offers no accessible indication that the surname field is required. ANDI can help inspect the field’s name and related description. Test a blank submission to see whether the error becomes discoverable. Asterisk-only convention is weak when readers cannot identify the meaning of the symbol. Provide visible and programmatic required-state communication, translate the guidance, and retest the field using keyboard and screen reader. Capture the initial and error states, including the exact phrase announced after failed submission.
Applied case 4: Placeholder used as a label
An Arabic shipping-address form uses placeholder text as its only field identification. The placeholder vanishes after the user starts typing and may not provide a dependable accessible label. Inspect the form with ANDI and confirm whether a real label exists. Fix the component so the field retains a stable name even when populated, focused or invalid. Check country-specific address parts without assuming postal codes, regions and street numbers follow one universal format. A successful test includes entering a full address and returning to an earlier field without losing its meaning.
Applied case 5: Date input instructions
The English account page requests a birth date as month/day/year, while the translated interface displays a day/month/year example but retains an English accessible description. ANDI helps reveal the mismatch, but the accepted format must also be tested. Enter an ambiguous date such as 04/05 only in a controlled fixture, then inspect the interpreted value. Prefer explicit format guidance and a suitable input control to relying on cultural guesses. Record the submitted date, displayed value, accessibility output and server interpretation; these four facts must agree.
Applied case 6: Password reveal control
A French account screen shows an eye icon next to a password field. The button is called ‘Show password’ regardless of its current state. Inspect the button before and after activation and determine whether the label or state tells the user what will happen next. If the visible text changes to ‘Masquer le mot de passe’, ensure the accessible output does not stay in English. Verify that the field type changes as intended and that focus remains stable. This is a privacy-sensitive interaction, so test using a harmless fixture rather than a genuine password.
Applied case 7: Checkout promotion code
The Italian checkout has a disclosure called ‘Add code’; when opened, it reveals a field but no clear action to apply the code. ANDI’s focusable-elements and structures views help inspect naming and state. A good repair makes the expanded state and newly available controls predictable. Enter a valid test code, then an invalid one, to check translated success and failure messages. Do not consider the feature complete until the displayed total changes correctly, the promotional terms remain understandable and error feedback reaches users without sight.
Applied case 8: Subscription comparison table
A French pricing table has plans across columns and features down rows. Visually, checkmarks look clear, but a screen reader reaches a cell containing only ‘yes’ without the feature and plan. Use tANDI to inspect cell-header associations one table at a time. Define headers with correct markup and localize descriptive labels where icon meaning would otherwise be lost. Recheck the row for automatic renewal, where a wrong association could mislead a purchaser. Record one example cell and its expected combined context as a reproducible acceptance test.
Applied case 9: Currency and decimal separator
A German price list displays ‘1.299,50 €’ while an accessible label reads ‘one thousand two hundred ninety-nine dollars’. A structural scanner may not know the currency is wrong; a reviewer must compare visible text and announcement. Use ANDI to identify which naming or description field is read aloud. Repair currency formatting and ensure the data layer transmits the correct amount. Retest including discounts and totals. Because this affects real money, require subject-matter verification and do not let a translator infer a conversion rate from punctuation alone.
Applied case 10: Heading hierarchy after translation
The Japanese help centre uses a visual heading font for the ‘Account recovery’ section but renders it as a styled paragraph. The structures module shows that the section is missing from heading navigation. Correct the semantic heading while keeping the approved wording. Check whether child topics use the next logical level; do not jump levels merely to obtain a desired visual size. A screen-reader reviewer should be able to reach the recovery section from a headings list and understand which instructions belong to it.
Applied case 11: Multiple navigation landmarks
A bilingual portal includes global navigation, course navigation and an in-page glossary. All three landmarks have the name ‘Navigation’. In sANDI, inspect each landmark’s identity and location. Give distinct descriptive names in the current language where that differentiation helps users choose. Preserve standard HTML structure and avoid creating ARIA landmarks for decorative wrappers. Verify that changing locale does not shift the main landmark into the sidebar. Test real navigation by landmarks, not just the number of landmarks displayed by the tool.
Applied case 12: Informative diagram
A translated onboarding flow includes a diagram showing ‘Request → Verify → Approve’. The Japanese diagram is visually localized but its alternative text is a file name. Use gANDI to investigate the image. Write a concise equivalent that communicates the process, and provide a longer adjacent explanation if the flow includes conditions or exceptions. Confirm that both forms of explanation match the current workflow release. Do not duplicate an entire nearby paragraph in the alternative text if it is already accessible and conveys the same sequence.
Applied case 13: Decorative image in a card
A Norwegian travel card includes a landscape photograph followed by a clear destination heading and description. The image’s alternative text redundantly repeats the destination, causing an awkward announcement for each card. Decide whether the photograph itself adds essential information or is decorative in this context. If decorative, an empty alt attribute can be appropriate for an ordinary image. Check that the enclosing link still has a meaningful name from the heading. An empty alternative is not permission to remove information from maps, route diagrams or photographs that communicate substantive choices.
Applied case 14: Hidden translated disclaimer
A German legal notice is contained in an accordion that is collapsed by default. The visible accordion label is translated, but the hidden panel contains old English contractual terms. Inspect the hidden content, open the disclosure, and read it through the keyboard and screen reader. Confirm that the expanded state is exposed and the content is the approved current translation. Save the content revision and document the legal owner who approved it. Accessibility testing must not accidentally transform the meaning of a contractual obligation during repair.
Applied case 15: Modal confirmation after deletion
An Arabic dashboard opens a deletion confirmation dialog. The visual layout is right to left, but the default focus lands on the destructive action, and the buttons’ accessible names do not match their labels. Inspect the dialog controls and focus sequence. Test Escape, Cancel and Confirm with safe sample data. Ensure the destructive choice is understandable and not disguised by unclear translation. After Cancel, the user should return to a logical location. Record actual focus movement and whether the data survived the cancellation.
Applied case 16: Embedded third-party payment frame
A Portuguese checkout embeds a payment frame with fields whose labels remain English. ANDI may inspect the outer frame differently from its inner document. Record both environments and avoid claiming the outer page passed an inaccessible inner journey. Coordinate with the payment provider or its localization settings. Test card-entry labels, validation and confirmation using test credentials only. If an English fallback is unavoidable, communicate it before users commit. An inaccessible mandatory third-party step remains a practical blocker for the entire checkout task.
Applied case 17: Cookie consent controls
A multilingual consent dialog uses an attractive visual toggle but an inaccessible name that always says ‘Accept all’. Inspect each action and check that the user can tell ‘Reject optional’, ‘Manage choices’ and ‘Save preferences’ apart. Test whether the dialog traps keyboard focus appropriately while open and returns it logically when dismissed. Translate category descriptions without disguising data practices. Do not regard an untranslated consent notice as only a cosmetic defect; it affects the user’s ability to make an informed decision.
Applied case 18: Live status after file upload
A Japanese upload form announces the button name correctly but provides no audible confirmation after a file is selected. ANDI can inspect visible status text and possible live-region markup, but the actual announcement requires a screen-reader session. Check progress, failure and completion states with an innocuous sample file. The success message should name the uploaded file or relevant result without exposing private path data. Record whether focus moves, what is announced and whether the user can continue to the next step without guessing.
Applied case 19: Mobile text enlargement
A Dutch service page passes a desktop check but breaks at 200% text enlargement: a long button wraps beneath the footer overlay. ANDI may help inspect the control, yet the primary defect is layout and visibility. Test the same locale at different viewport widths and browser text settings. Preserve natural reading order and avoid truncation as a workaround. Verify that keyboard focus can reach the complete label and that the control remains operable. Capture viewport dimensions, zoom settings and the exact translated phrase to make the report reproducible.
Applied case 20: Mixed-script contact number
A Hebrew contact page embeds a telephone number inside right-to-left prose. The digits display in a confusing order, while the phone link and accessible name differ. Use ANDI for the link identity, then inspect bidirectional rendering and the actual tel destination. Keep numeric strings correctly ordered and make the spoken label intelligible. Do not translate or reorder the underlying number as if it were a sentence. Test call activation on a suitable test device or approved fixture and confirm the intended country code.
Applied case 21: Error summary with duplicate links
An English and Hindi loan application displays an error summary containing five links all called ‘Fix error’. The links point to distinct fields but give no useful out-of-context meaning. Inspect the link names and targets; then move through the form with a keyboard. Use field-specific language such as ‘Correct income amount’ when warranted and preserve appropriate grouping. A review should confirm that activating each summary link places focus at the corresponding invalid field and that the detailed error describes the next action.
Applied case 22: Success state after saving preferences
The Chinese-language settings screen shows a toast saying ‘Saved’ after the user changes notification preferences. The toast disappears before a keyboard user reaches it, and its accessibility status is uncertain. Inspect the page state and compare the underlying preference value before and after refresh. Use appropriate status messaging so the result reaches users without stealing focus unnecessarily. Localize the confirmation precisely: ‘Notification preferences saved’ is more informative than a generic success phrase. Retest the journey with a real screen reader and check that the stored selection survives navigation.
How to record useful defects
A good issue begins with the consequence and ends with a testable repair. Include the page and locale, product build, browser and assistive technology where used, the component’s visible wording, the accessible output observed, the steps to reproduce, the expected meaning, the actual result and evidence that does not expose personal data. Assign ownership to content, engineering, design or a third-party vendor based on the actual cause.
Write an expected result in the language of user capability. ‘The Japanese search control announces an intelligible search action and opens a focused search field’ is stronger than ‘Pass ANDI’. State whether an alert is an automated observation, a manual structural finding, a linguistic defect or a verified user-task failure. This distinction prevents reports from overstating certainty.
Retest in the failing locale first. Then test a source-language baseline and one other high-risk locale to catch regressions from shared components. A patch to a component-level aria-label may fix one market but overwrite translations in another. Preserve before-and-after evidence and identify which combinations were examined rather than claiming universal coverage.
Common mistakes and practical troubleshooting
A bookmarklet that refuses to load may be blocked by policy; do not report that as a WCAG failure. A tool that is unable to inspect a shadow-root component has incomplete coverage; use a complementary method. A link with a correct name but an incorrect destination needs navigation and content review. A field with an accurate label but an erroneous value needs business-rule and localization review. Treat each as a separate type of defect.
Do not confuse the browser’s interface language with the web page’s declared language. Do not equate a page’s language with a user’s preferred country. Do not infer that keyboard focus order automatically follows visually mirrored direction. Avoid translating HTML attribute names, ARIA roles, program identifiers or URLs as ordinary prose; translate the human-facing strings and preserve valid technical identifiers.
An apparent false positive deserves evidence rather than dismissal. Reproduce the DOM state, check what ANDI detected, use another accessibility inspection method and document why the alert does or does not affect a real user. Where legal or procurement conformance is in question, use the relevant evaluation methodology and qualified reviewers; no tool’s logo substitutes for analysis.
Questions readers frequently ask
Is ANDI free?
Yes. The U.S. Social Security Administration provides ANDI as a free web accessibility testing tool. Use the official site for installation and support, and check the actual browser environment before relying on its results.
Does ANDI translate pages?
No. It helps inspect accessibility information in pages you are testing. Your translation process must supply the content, correct language metadata and suitable interface behavior. ANDI can expose mismatches; it does not generate approved translations.
Can ANDI certify that a website is WCAG compliant?
No. Conformance depends on applicable criteria across the defined scope and requires manual assessment, representative testing and appropriate expertise. A tool may find evidence of problems without proving every requirement has been satisfied.
What is the most important item in the ANDI output?
The meaning of the element in its real task is more important than a raw alert count. Check accessible name and description, how they are calculated, and whether keyboard and assistive technology users can understand and operate the element.
Should I scan every language?
For a high-risk product, test every supported language across critical journeys where feasible, using risk-based sampling for additional templates and states. A language switch can affect semantics, direction, layout and validation, even when the shared component code seems identical.
How do I handle a third-party widget?
Identify its owner and integration configuration, test the full user journey and file a separate vendor issue if necessary. Do not mark the complete transaction accessible because your own page’s outer shell passed inspection.
Official reading and connected guides
The authoritative starting points are the SSA ANDI installation page, ANDI user guide and ANDI module descriptions. For the wider context, consult the W3C Web Content Accessibility Guidelines and its explanations of accessibility principles. For complementary checks, see eduKate’s Firefox Accessibility Inspector guide and NVDA multilingual screen-reader guide.
The enduring lesson is simple: accessible translation is not a decorative second pass. It is the preservation of names, instructions, structure and predictable actions across languages and interaction modes. ANDI helps reveal what a browser exposes; a careful reviewer completes the work by checking whether a person can use it.