NVDA, short for NonVisual Desktop Access, is a free and open-source screen reader for Microsoft Windows. It helps people navigate applications and websites through speech and Braille, and it offers a practical way for translation teams to test multilingual web content as users may experience it. If you need an NVDA screen reader tutorial for localization QA, begin with the important distinction between translated words and accessible interaction. A Spanish page can have excellent prose yet unlabeled form controls; an Arabic site can look correct while presenting links in a confusing sequence; an English-French course can mispronounce quotations because language changes are not marked in the markup.
For an initial test, install an official current NVDA release, start with a supported browser and a familiar public page, then learn browse mode and its heading, link, list and form-navigation behavior. In the official user guide, NVDA+space switches between browse and focus modes, and NVDA’s speech settings include automatic language switching when the synthesizer supports it. Use the Elements List, speech output and real keyboard tasks to investigate whether a translated page is navigable. The goal is not to memorize every command. It is to reproduce what happens when someone tries to find information, understand the text and complete an action without relying on the visual page.
This guide explains NVDA multilingual website testing, automatic language switching, screen-reader speech, HTML language tags, headings, semantic navigation, keyboard focus, forms, error messages, tables, right-to-left text, Speech Viewer, Braille considerations and quality assurance. It serves international web editors, app localizers, teachers, translators, accessibility testers and technical writers. The central discipline is to judge the complete user task in the target language, then locate whether a failure comes from content, markup, interaction, synthesizer settings or the browser environment.
At a glance
- Test on Windows with an officially supported NVDA build and record the browser and speech settings.
- Use keyboard navigation and browse mode to explore the page’s actual semantic structure.
- Verify language changes through HTML markup and suitable voices, not appearance alone.
- Check headings, links, forms, errors, tables, dialogs and right-to-left examples as tasks.
- Record reproducible failures, repair the source, and retest in the final localized build.
What NVDA can reveal about translated websites
A screen reader exposes structure and control information that a visual preview often hides. When a person sees a large blue heading, they may infer that it begins a new section. NVDA does not infer meaning from color alone; it depends on available accessibility information, including semantic HTML. Likewise, a visual button labeled only with an icon may be obvious to the designer but unclear when announced simply as ‘button’. In a translated site, these defects interact with language quality. A correctly marked heading whose label is mistranslated can still mislead the reader. An accurate translation of a form field may remain inaccessible if the field has no programmatic label. NVDA helps testers hear and navigate these relationships. The value is not that it replaces real users or proves compliance by itself. It is an observation tool for investigating what the browser and accessibility layer actually communicate. Use it with code inspection, keyboard testing and feedback from people who depend on assistive technology.
Choose a representative Windows test environment
NVDA is a Windows screen reader, not a universal cross-platform accessibility engine. As of November 2026, NV Access published NVDA 2026.3.1 as a stable patch release, including security fixes. Use current official downloads where organizational policy allows, and record the exact version rather than relying on an assumption that everyone is on the same build. Choose a browser supported by NVDA, such as a current edition of Firefox, Chrome or Edge, and note its version. If your target audience relies on a particular browser, include it in the test matrix. Keep extensions and add-ons controlled because they can alter behavior. Decide which speech synthesizer and voice will be used for each language. A defect reproduced only with one voice may require different investigation from a heading missing in every browser. Do not claim that one Windows configuration represents screen-reader users on macOS, iOS, Android or Linux. A sound QA plan combines a stable reproducible setup with additional testing where audience needs demand it.
Learn browse mode before judging a page
The official NVDA user guide describes browse mode as a way to navigate complex documents such as web pages using a virtual reading position. This is why pressing an arrow key in a browser may move through text instead of scrolling the page in the way a sighted mouse user expects. Browse mode is not a defect; it is part of the reading model. Practice on a known accessible page before testing your own site so you can recognize ordinary behavior. Follow text line by line, move through headings and links and observe how NVDA announces lists. Try reading the page from the top and then reaching a specific section without reading everything. When the test page contains a form, notice how interaction differs from reading ordinary prose. For a multilingual site, this exercise helps you distinguish a genuine content issue from unfamiliar keyboard behavior. A useful tester understands enough of the tool to say ‘the heading is missing from navigation’ rather than ‘the screen reader ignored the large text’.
Understand browse mode versus focus mode
NVDA distinguishes reading a complex document from interacting directly with controls that need keyboard input. The official guide documents NVDA+space as a way to toggle browse and focus modes, with automatic behavior for suitable controls and Escape commonly returning from automatic focus mode. This distinction matters when testing forms, search boxes and custom widgets. Suppose a translated course website contains a vocabulary quiz. The tester needs to navigate instructions as reading content, then type an answer into a text field. If the widget traps keys incorrectly or lacks a clear focus state, the person may struggle to understand what is happening. Reproduce the issue in the intended mode before making changes. Do not assume that every key must work identically in both modes. The design should support expected keyboard operation and meaningful announcements. A screen-reader usability problem can originate in JavaScript focus management, HTML structure, an inaccessible custom component or misleading translated instructions. Diagnose the specific layer rather than making arbitrary visual changes.
Test headings as a logical outline
Headings provide one of the fastest routes through a long webpage. In a tutorial, they let a reader skip directly to troubleshooting, exercises or the explanation they need. Examine the heading structure using NVDA’s navigation commands or Elements List. Ask whether the announced labels form a coherent outline in the target language. A translation may have changed ‘Admission requirements’ into a vague phrase meaning ‘Information’, which technically remains a heading but fails the reader’s search intent. A designer may have replaced an HTML heading with a bold paragraph because the translated title was too long, which removes the semantic route altogether. Another common error is using heading levels for visual size rather than document structure. Review the sequence and ensure that subsections belong to meaningful parents. Do not force every section to use one level if the content truly contains nested topics. When a page is very long, the headings list should function as a useful compressed map of the content, allowing someone to find the intended answer without hearing hundreds of unrelated sentences.
Links must have purpose outside visual context
Links are often encountered as a list, separately from the surrounding paragraph. A label such as ‘click here’ loses its meaning when isolated. Test translated link text by opening NVDA’s Elements List or moving through links by keyboard. Can a user tell where each one leads? Does the target-language label accurately identify the destination? A university application page might contain multiple links labeled ‘Apply’, some for scholarships and others for courses. Without distinct accessible names, the user may choose the wrong process. Translators should review visible link labels and any programmatic names supplied by the interface. Developers should confirm that the actual link target and accessible name agree. Avoid using the same link label for different actions unless the context makes the relationship genuinely clear. A translated URL is not always necessary or desirable; many endpoints and identifiers are stable. The important qualities are accurate expectations and a predictable destination. Test external links, downloads, new windows and return navigation where these behaviors materially affect the user’s task.
Language tags are instructions to assistive tools
A multilingual page needs correct language identification in the document and relevant passages. HTML language attributes help assistive technologies choose appropriate pronunciation rules or voices where the synthesizer supports that behavior. A page that is visually French but declares English may be read with inappropriate sounds. A bilingual exercise could contain English examples inside an Arabic explanation, each requiring suitable identification. NVDA provides automatic language switching controls, but those controls cannot guarantee a suitable voice exists for every language. The QA method is therefore to examine both source markup and actual speech output. Compare a main paragraph, a short embedded quotation, a page title, form labels and error messages. If the main page language is correct but an inline passage is not marked, the problem may occur only briefly and escape casual listening. Do not label a phrase with the language of the speaker’s nationality rather than the language of the words. Appropriate language metadata should match the text, and testing should reflect the languages the product truly serves.
Automatic language and dialect switching settings
NVDA’s speech settings include automatic language switching and separate controls related to dialects and reporting language changes. The exact outcome depends on the selected synthesizer’s support. Before blaming a localized site for strange pronunciation, check whether the tester enabled relevant settings and whether the required voices are available. Then inspect the actual HTML language tags. Run a simple controlled experiment: place a clearly identified Spanish sentence inside an English paragraph on a test page with correct markup. Listen to whether NVDA changes pronunciation and note any limitations. Repeat with the application under review. If the controlled page succeeds but the product page fails, the markup or application behavior deserves inspection. If neither succeeds, the voice environment may be the main constraint. Avoid altering perfectly correct source translations to satisfy one unsuitable voice. A quality report should state what was heard and under what settings, not claim that a language tag automatically guarantees spoken proficiency. This is especially important for world-facing products serving languages with uneven voice availability.
Speech Viewer helps sighted collaborators
NVDA includes Speech Viewer, a tool described in the official user guide that displays the text currently being spoken. It can help a sighted developer or translator follow announcements while learning the software. Use it to capture the accessible name of a control, the order of announcements or a surprising label. However, displayed text is not a complete representation of the reading experience. Timing, language pronunciation, prosody, interruption and Braille output can differ from the written words shown in the viewer. A translator reviewing Speech Viewer alone could miss that an English word is pronounced in the wrong language. Combine visual inspection of announcements with actual listening and task completion. Protect privacy when recording test sessions: a screen reader may speak information from documents, accounts or notifications that should not enter a public bug report. Use demonstration data wherever possible. Speech Viewer is most valuable as a shared diagnostic aid between people with different expertise, not as evidence that a page works for every blind reader.
Lists, instructions and numbered procedures
A list is not merely a block of lines with decorative bullets. It conveys grouping and often order. NVDA can announce list-related structure when markup is provided appropriately. Test whether a translated sequence of safety instructions remains a real ordered list, whether items are announced separately and whether the distinction between required steps and optional examples survives. If a translator pasted the text into a styled paragraph and manually typed numbers, the visual result may appear acceptable while list navigation becomes less useful. Also check instructions that refer to numbers by name: after localization, ‘complete step four’ must still refer to the same action. In a classroom or workplace training site, list structure can carry safety implications. Avoid creating one giant list when the content contains multiple subsections that should have their own labels. Conversely, do not flatten meaningful groups solely because the translated sentences became longer. A user should be able to understand both the individual commands and their relationship to the surrounding task.
Forms: labels before visual elegance
Form controls are among the most consequential accessibility features because they require action. Test a localized registration or feedback form using keyboard and NVDA. Identify each input by its announced name, required status, instructions and current value. Does the control have a proper label, or does it depend only on placeholder text that disappears when typing? Are radio buttons and checkboxes grouped with meaningful questions? Does a translated country selector announce what it is selecting? The visual layout may make relationships clear to a sighted reviewer, but a screen-reader user needs those relationships programmatically exposed. Translate error messages and help text in the context of the action. For example, ‘invalid input’ may not help a user who needs to know whether a date, email or confirmation code is incorrect. When reviewing forms, never assume that correct text alone fixes a missing label association. Translation and technical accessibility must be evaluated together on the working control. The right test is whether a person can complete the form and recover from mistakes without outside assistance.
Error messages and recovery journeys
A good form must do more than announce its labels. It must tell the user what happened after submission, where an error occurred and what to do next. A translated website may display a red warning visually but fail to communicate it in a way a screen reader notices. Test by deliberately submitting an incomplete form with harmless sample data. Listen for a useful error summary, navigate to the field that needs correction and try again. If the page updates dynamically, inspect whether focus and live announcements help the user understand the change. Do not inject long alerts for every keystroke; excessive speech can be as disruptive as silence. The translation itself should be precise. ‘Your account was suspended’ is not equivalent to ‘Your application is pending’; a vague localized message could trigger an unnecessary response. Record the success confirmation as well as failure behavior. The user needs to know when the action has actually completed. Accessibility includes the entire journey from initial instructions to recovery and final confirmation, not just the first screen.
Dialogs, menus and custom components
Modern websites often use custom dropdowns, modal dialogs and expandable panels. These controls can be difficult to test if they imitate native behavior visually but do not expose equivalent semantics or keyboard interactions. With NVDA, open a dialog and observe whether its purpose is announced, whether focus moves into it appropriately, whether navigation remains predictable and whether the user can close it. After closing, check that focus returns to a sensible place. For translated menus, confirm that the accessible name reflects the current language and that changing the locale does not leave hidden labels in English. Do not fix an inaccessible custom control by simply adding more visible explanation paragraphs if the underlying interaction is still broken. Sometimes using a native HTML element is the simpler and more reliable design. When custom behavior is necessary, developers should follow the relevant accessibility patterns and test them in actual environments. The practical goal is that a user understands what control is open, which choices are available and what happens when a choice is made.
Tables and data relationships
Tables are especially important in international educational and government content. NVDA can help a tester explore row and column relationships when a table is properly structured. Select a table that contains meaningful data, not merely a layout grid. Navigate through its cells and ask whether headers are announced in a way that explains each value. A translated financial table may have longer headings, and an overly aggressive layout change might remove header associations while keeping the visible alignment. Test numeric punctuation, dates, currency symbols and measurement units in the target language. Do not treat the speech engine’s interpretation of a number as proof that the underlying value was translated correctly. If the source says 1.5 and the target locale uses 1,5, the formatting policy must preserve the actual quantity. Review whether complex tables need a caption or an alternative summary that explains trends. For tables whose relationships cannot be conveyed well in one representation, consider a thoughtfully authored alternative. A successful data test establishes comprehension, not merely the presence of rows and cells.
Images and descriptions in the target language
Images often carry information that a screen-reader user needs but cannot obtain visually. NVDA testing reveals whether an image has an accessible description and what that description says, but only a human familiar with the content can judge its quality. Translate alternative text according to purpose, not by mechanically listing visible objects. A chart in a climate article may require information about axes, trend and comparison. A decorative logo repeated beside every paragraph may need less verbose treatment than a unique informative illustration. If an image contains untranslated text, the description alone may not be enough; the publisher should assess whether the visual asset needs localization. Confirm that captions and nearby descriptions agree with the translated explanation. Do not invent data to make the alternative text sound helpful. The words should reflect what the source genuinely shows and what the surrounding argument requires. Inspect the screen-reader reading order: an excellent description announced too far from the relevant paragraph can still confuse the reader. Accessibility editing is inseparable from sound educational writing.
Right-to-left content and mixed-language identifiers
Arabic and Hebrew interfaces may include left-to-right product codes, English quotations, phone numbers, dates and addresses. Test those strings with NVDA and also inspect what happens when they are copied and pasted. A screenshot can hide an incorrect underlying character sequence, especially when directional controls have been inserted carelessly. Confirm language and direction information separately. The main page may be Arabic, while a code fragment or brand name remains in Latin script. The reader should receive the intended sequence without having executable identifiers changed by translation. Check navigation labels, form values, error messages and tables, since mixed-direction behavior can vary by context. If speech order seems unexpected, compare the source text characters with the browser’s accessibility output and the actual voice behavior. Avoid guessing which layer is responsible. A robust test uses meaningful sample content such as a registration number or example command rather than a sentence with only ordinary letters. International QA must preserve exact identifiers as well as natural-language meaning.
Unicode, punctuation and special symbols
Translation workflows can introduce character-level problems that become obvious during speech or Braille use. Curly quotes, apostrophes, minus signs, dashes, non-breaking spaces, combining marks and lookalike letters may have different purposes. NVDA’s pronunciation of punctuation depends partly on its settings and synthesizer, so an unusual announcement does not automatically prove the source character is wrong. Inspect the actual Unicode text and its semantic role. For example, the mathematical minus sign should not be substituted casually with a hyphen in a technical lesson. A decimal separator should match the intended numerical value and locale. If a word is decomposed into combining sequences, verify that the displayed and spoken result is still correct and stable. Do not normalize text blindly when exact code points matter, such as identifiers, usernames or programming examples. A good localized interface is both linguistically readable and computationally reliable. Test representative symbols with the same reading configuration that a user would employ, then record source-level corrections rather than relying on one speech quirk.
Reading mathematics and technical content
NVDA supports mathematical content to varying degrees depending on the format, browser, installed components and how the expression is authored. The official guide includes a section on mathematical reading, but a translated equation still requires subject expertise. A physics page containing exponents, vectors and fractions may be visually clear yet difficult to interpret in linear speech. Test whether the authoring method exposes structural information rather than rendering a formula only as an image. Ask a learner to identify which quantity is being squared, which terms belong in a denominator and whether units were preserved. For code snippets, protect literal syntax from casual translation and check how symbols are announced. A programming exercise that changes a function name or punctuation can become unusable even if the explanatory prose is excellent. Record the exact statement or expression when a problem occurs, with a link to the page and a description of the expected mathematical meaning. Never treat a voice’s pronunciation as the sole authority for a technical formula.
Braille is related but not identical to speech
NVDA supports refreshable Braille displays as well as speech. A passage that sounds acceptable through one voice may be confusing in Braille if language-specific translation tables, contractions or formatting are inappropriate. The official NVDA settings include Braille output and input options, but the results depend on connected hardware, selected tables and user preferences. Test with qualified Braille users when the publication’s audience relies on Braille, particularly for educational material with complex notation. Distinguish between the website’s underlying text and the Braille representation generated by the user’s setup. A wrong Braille code setting should not be attributed automatically to a translation defect, yet missing semantic headings or misleading text remain authoring issues across both modes. Keep a careful record of display model, table, language and task when investigating. Do not use the apparent completeness of spoken output as permission to skip tactile review for a Braille-dependent learning resource. Accessible communication should respect the actual modes its readers use.
Distinguish browser defects from content defects
A localization issue report should specify where the unexpected behavior occurs. If NVDA reads a heading incorrectly in one browser, test the same page in another supported browser and inspect the HTML. If the semantic heading is missing from source markup, the defect is probably not browser-specific. If the markup is correct but one combination behaves differently, investigate compatibility and versions. Keep browser extensions out of the baseline unless your audience requires them. Test a known-good reference page under the same settings to see whether a voice or navigation behavior is general. This prevents teams from rewriting content in response to an environmental problem. However, do not dismiss a reproducible barrier merely because another browser works. Real users depend on their own combinations of technology. The release decision should acknowledge which combinations are affected and whether a practical solution exists. An issue’s severity depends on the reading task it blocks, not only on the number of devices where it appears.
Worked example: multilingual college admissions
Imagine a university admissions page available in English, Arabic and Spanish. The translation itself is accurate, but an NVDA test reveals that the Arabic application button still announces an English accessible name. The team inspects the markup and finds an untranslated attribute inherited from the source component. After correcting it, they test the entire application route. The form contains a date field, a country selector and a confirmation checkbox; each must be announced with a meaningful target-language label. A deliberate submission error exposes another problem: the red warning is visible but not announced at a useful time. Developers repair the error association and focus behavior, then ask a bilingual tester to complete the task with keyboard and speech. The Spanish page presents a different issue: a scholarship link is labeled simply ‘More’, which is impossible to distinguish in the links list. Editors write a specific label and verify the target. The finished page is tested as a journey, not as isolated sentences. It must allow a prospective student to apply without guessing.
Worked example: a science learning portal
A publisher localizes a science lesson into French and Japanese. The French version includes English equipment names and formulas, while the Japanese version uses ruby annotations and some vertical-script examples. In NVDA on Windows, the tester first confirms the main language and tries to navigate the lesson by headings. The French headings work but the figure description merely says ‘diagram’, providing no information about the experiment. A subject expert rewrites the description to convey the relationship between temperature and pressure. The Japanese examples reveal unusual pronunciation of an embedded English term. The team checks language tags and synthesizer support rather than changing the term’s spelling. Then they test a data table, its column headers and an exercise form with a feedback message. An engineer validates the markup and a language reviewer evaluates the actual meaning. The combination of semantic inspection, listening and task testing produces a more dependable result than checking translation strings alone. No single tool can judge every aspect.
Worked example: right-to-left public information
A public information site provides emergency instructions in Arabic and Hebrew, including telephone numbers, map references and English technical identifiers. A visual review suggested that each page was ready. NVDA navigation reveals that the emergency heading has been implemented as a styled paragraph, so users navigating by headings may skip the most important instruction. The page also contains an unlabeled language selector and a table of contact numbers whose headers are not properly associated with values. These are corrected at the source. A target-language tester then listens to the instructions, follows the emergency contact link and confirms that the number is represented accurately. The team checks mixed-direction text without changing literal phone digits or identifiers. Because emergency information has consequences beyond convenience, they prioritize clear language, discoverability and task completion. The audit record names the tested browser, voice, page revision and remaining limitations. That is a defensible quality process even without pretending that any automated or manual test guarantees all possible experiences.
Troubleshooting an unexpected announcement
When NVDA announces something surprising, begin by reproducing the exact behavior. Note the page, control or phrase, how focus reached it, which mode was active and what was expected. Check whether the issue is consistent or intermittent. Inspect the source HTML and available accessibility information. If a button speaks a placeholder rather than a meaningful label, look for conflicting or missing naming mechanisms. If a bilingual passage uses the wrong voice, inspect language attributes and the synthesizer configuration. If a custom widget seems to trap navigation, compare its keyboard behavior with a native control performing the same task. Use Speech Viewer to help collaborators capture wording, but listen to the audio as well. Avoid speculative fixes such as inserting hidden text everywhere or adding ARIA attributes without understanding their effects. A narrowly diagnosed cause is easier to correct and less likely to break another access mode. Re-run the original steps after the fix instead of assuming a code change has solved the reader’s difficulty.
Prioritize issues by reader consequence
An audit produces many observations, but not all are equally urgent. Prioritize barriers that prevent users from understanding critical content, completing a form, finding a destination or recovering from an error. A missing accessible name on the payment-confirmation button may be more serious than a minor pronunciation oddity in decorative text. Incorrect emergency instructions or financial values deserve immediate attention because their meaning is consequential. Consider frequency and scope: a broken language selector affects every multilingual user who needs to change languages, whereas a formatting issue in an optional appendix affects fewer tasks. Do not discard low-priority defects; record them for improvement. The objective is to support informed release decisions, not to chase an unexplained count of warnings. Include users and language specialists in severity judgments where possible. A sighted developer may consider an issue cosmetic while a blind student finds it a complete blocker. Listen to the people who perform the actual tasks.
Build an accessible localization test matrix
A practical matrix crosses language, page type, interaction and assistive configuration. For each target language, test a representative long article, navigation menu, form, data table, error state and document download. Include real script examples rather than placeholder English. Record Windows version, NVDA version, browser, voice, language-switching settings and any relevant Braille equipment. A small disciplined matrix is better than a huge checklist nobody follows. Begin with the most important tasks and expand when evidence shows gaps. Keep a reference page with known-correct headings, lists, links and language switches so new testers can learn expected behavior. For each failure, log the source revision and exact reproduction steps. After developers repair the markup or editors correct labels, verify the final localized build. If a fix touches shared components, retest other languages to detect regressions. This is where translation QA meets software quality assurance: a local repair can accidentally alter every locale, so shared components require a wider check than one isolated paragraph.
A four-week team learning plan
In week one, install NVDA from the official source, read the relevant guide sections and learn basic web navigation on a known accessible page. Practice headings, links, browse mode, focus mode and reading a form. In week two, test one translated page with a clear task and reproduce at least one meaningful finding. Have the translator and developer examine the same issue, each from their expertise. In week three, add a second language and a more complex interaction such as a form submission or data table. Test language switching, labels, validation and recovery; invite an experienced screen-reader user to review the findings. In week four, create a short release checklist and issue template. Record what counts as a blocker, which teams approve fixes and which browser/voice combinations are supported. Do not aim to turn every translator into an expert assistive-technology user in a month. Aim to establish a shared vocabulary for accessible communication and a dependable escalation route when a reading task fails.
Frequently asked questions
Is NVDA a machine translation tool?
No. NVDA is a screen reader. It communicates interface and document information through speech or Braille. It can help test how translated content is exposed to assistive technology, but it does not translate a website between natural languages.
Does NVDA work on macOS or iOS?
NVDA is designed for Microsoft Windows. Other platforms have different screen readers, such as VoiceOver. A Windows NVDA test provides evidence for its tested environment, not a blanket claim for every operating system or device.
Why is my French passage pronounced in an English voice?
Check the document or passage language markup, the NVDA automatic language switching setting and the selected synthesizer’s support. A language code cannot guarantee that a suitable voice is installed. Diagnose source and environment separately before changing the translation.
Does Speech Viewer prove the page is accessible?
No. Speech Viewer helps display announced text for inspection. It does not fully represent speech pronunciation, timing, Braille output or the user’s ability to complete a task. Use it as one diagnostic aid alongside listening, keyboard use and semantic review.
What are browse mode and focus mode?
Browse mode helps navigate web content as a readable document. Focus mode passes keyboard interaction to controls that need it. NVDA provides switching behavior and documented controls. Learn both before judging a form or custom interface.
Can a page pass an automated audit and still fail an NVDA test?
Yes. Automated tools detect many technical patterns, but users may encounter unclear labels, confusing workflows, misleading translations or compatibility limitations. Manual task-based testing complements technical checks and is essential for real-world usability.
What evidence should accompany an accessibility bug report?
Identify the exact localized page, revision, task, steps to reproduce, expected and actual behavior, NVDA and browser versions, voice settings and impact on the reader. Link to a non-confidential example if possible. Specific reports make meaningful repairs much easier.
Further reading and official documentation
- NV Access official NVDA site
- NVDA current user guide
- NVDA 2026.3.1 release notes, November 9, 2026
- W3C Web Accessibility Initiative
- Thorium Reader Desktop multilingual reading QA
- Ace by DAISY EPUB accessibility audits
Closing perspective
A good localized website lets people do something meaningful, not merely hear a string of translated words. NVDA helps editors and developers discover when semantic structure, keyboard behavior, language identification or spoken explanations fail to support that goal. Use it carefully, test authentic tasks, distinguish environmental limitations from source defects and invite experienced assistive-technology users into the review process. When the final multilingual page can be understood and operated without guesswork, translation and accessibility have begun to work as one service to the reader.