A single untranslated dropdown option can send a completed application into the wrong queue, while a translated label with an unchanged tooltip can leave screen-reader users without the same instructions as everyone else. Translating a fillable PDF form means checking the words people see and the field behavior behind them.
What a field-by-field translation involves¶
A fillable PDF form is a document with visible content and interactive controls. The visible page might show a label and an empty box, but the PDF also contains field information and appearance instructions that determine how that control behaves.
The PDF 1.7 specification describes interactive form fields as field dictionaries. Those fields can be arranged hierarchically and can have widget annotations that define their appearance on the page. The specification is an edition dated 2008, so treat it as a technical description of that PDF version, not as a current legal rule: ISO 32000-1:2008, PDF 1.7.
A translation project needs to account for both the document’s language and the behavior of its controls. A translator who receives only extracted text may see “Date of birth” and “Submit,” but not know whether the form includes a date field, a required-field setting, an associated tooltip, or a submission value that a downstream system expects.
A field-by-field review usually covers:
- Visible labels beside text boxes, checkboxes, radio buttons, and dropdowns.
- General instructions, help text, and notes that explain what a person should enter.
- Tooltips, which provide a contextual description associated with a field.
- Option labels inside dropdowns and radio groups.
- Required-field indicators and the wording that explains them.
- Error messages and validation instructions, where the form includes them.
- Accessibility structure, including tags, reading order, and document language.
- Internal field names and export values, which may affect how responses are processed.
The list isn’t a demand to translate every string in every file. Some entries are intended for users; others are identifiers used by form authors or receiving software. The task is to classify each element before deciding what to translate.
A visible label and an internal field name aren’t interchangeable. The Massachusetts accessibility guide explains that an Acrobat field name helps the form creator but isn’t conveyed to screen readers. The tooltip provides the user-facing contextual description read for the field. See the Massachusetts PDF forms guide.
“For a PDF form to be accessible, it must be a properly tagged PDF containing interactive form fields and associated tooltips.”
That statement describes the guide’s accessibility recommendations. It doesn’t mean translation alone makes a form accessible, or that the guide establishes a universal legal requirement for every PDF in every jurisdiction.
A useful working model is to treat the project as three connected layers:
| Layer | Examples | Main question |
|---|---|---|
| Visible content | Labels, instructions, option text | Does the person filling in the form understand what to do? |
| Interactive behavior | Field type, required setting, dropdown choices | Does each control still accept and represent the intended answer? |
| Accessibility and structure | Tags, tooltips, reading order, language | Can people navigate and understand the form with different tools? |
For example, a health intake form might include the visible label “Current medication,” a text field with a creator-facing name, and a tooltip that clarifies whether the person should list dosage. The visible label, tooltip, and any instructions need to agree. Translating only the label could leave a person with an incomplete or contradictory prompt.
A form’s purpose also affects the translation choices. A customer feedback form, a benefits application, and an internal equipment request may use similar controls but ask for different levels of detail. Before translating, identify who fills in the form, who reads the responses, and whether software uses any field values to route or validate submissions.
Which parts should be translated, and which need a separate decision?¶
The most reliable way to avoid accidental changes is to create a field inventory before editing the form. Include each user-facing string, its location, its field type, and any known connection to a data system. That inventory becomes the handoff between the form owner, translator, reviewer, and person who tests the finished PDF.
| Form element | Translate? | What to check |
|---|---|---|
| Visible label | Yes, if the form is for users of the target language | Keep the label specific enough to identify the requested information |
| General instructions | Yes | Place instructions where users encounter them before they need to act |
| Tooltip | Yes, when it provides user-facing guidance | Make the tooltip match the translated label and explain the control’s purpose |
| Dropdown option text | Yes, when users choose among visible options | Preserve meaning and distinguish similar choices |
| Checkbox or radio-button text | Yes | Confirm that every option still makes sense as a choice |
| Required-field wording | Yes, if shown to users | Match the control’s required setting with clear translated wording |
| Internal field name | Review before changing | Ask whether a database, script, or export process depends on the existing name |
| Export value | Review before changing | Confirm how the receiving system interprets the value |
| Decorative or hidden text | Depends on purpose | Check whether it conveys meaning or is part of the accessibility structure |
The Massachusetts guide recommends placing general instructions before the first form field. Its reason is practical: screen-reader forms mode may skip visible prose and read field tooltips and links while navigating controls. The guide also recommends visible labels and space for fields in the source document, and cautions against using tables purely for layout or to indicate form fields. Read the advice in its full context at Digital Accessibility at the Commonwealth.
A translation team should therefore treat the introductory instructions as content, not as optional decoration. If a form asks applicants to gather information before starting, that instruction can prevent incomplete entries. If the translated introduction is moved below the fields or left in the original language, users may miss the preparation step.
Field labels and tooltips need to work together¶
A label tells users what a field is for. A tooltip can add context that the visible label doesn’t have room to carry. The two shouldn’t contradict each other, and the tooltip shouldn’t simply repeat a vague label if a short explanation would make the task clearer.
Consider a field labeled “Address.” A tooltip could clarify which address is requested, such as a mailing address or a current residential address, if the form owner has specified that distinction. Don’t invent the distinction during translation; ask the form owner if the source is unclear. A translator shouldn’t infer a data policy from a short label.
The Massachusetts guide says the text field’s name and tooltip are required information for its accessible setup in the workflow it describes. For required fields, the guide recommends setting the field’s required property and including the word “required” in its tooltip. Those recommendations are scoped to the guide; check the PDF’s purpose and applicable accessibility requirements rather than treating them as a universal legal rule.
The W3C’s PDF technique pages provide additional technical references for labels on interactive controls and name, role, and value information for fields. A technique page explains an approach; it doesn’t replace review of the applicable accessibility standard or the needs of the actual form.
Field names and export values need an owner¶
Field names can look like ordinary text in a PDF editor, but they may be identifiers that connect a form to a database or an automated workflow. Export values can also differ from the words displayed to users. A checkbox could display a translated option while submitting a stable value expected by another system.
Don’t rename internal identifiers just to make them look translated. First ask the form owner or system administrator whether the receiving system depends on the current value. If a translated form feeds an existing database, the safest choice may be to translate the visible option while retaining its original export value. If the form is being rebuilt for a new language-specific process, the owner may choose a new field naming convention.
Record the decision in the handoff, including who approved it. A translator can identify strings and flag ambiguity, but shouldn’t silently change how responses are stored or routed.
Dropdowns, checkboxes, and radio buttons need a complete pass¶
Option text is easy to miss because it might not appear until someone opens a dropdown or clicks a control. Review every option, including “Other,” “Not applicable,” and any blank or default entry. If the option is tied to a stored value, distinguish the translated display text from the value sent to the receiving system.
Checkboxes and radio buttons also differ in behavior. A checkbox can allow multiple selections; a radio group usually presents mutually exclusive choices. Translation shouldn’t make the choices sound as if they have a different relationship. Test the controls after editing rather than relying on the wording alone.
The Massachusetts guide says the field should be placed near its visible label. That placement helps connect the words on the page to the control and supports a clearer navigation experience. A translated label that expands can make a previously close pairing harder to recognize, so layout review matters alongside wording.
Why PDF translation can disturb a form¶
A PDF’s page may look like a conventional document, but its content isn’t necessarily stored as paragraphs and tables. The PDF 1.7 specification describes the structure of form fields and widget annotations; appearance and interactive data are connected but distinct parts of the file. That distinction explains why replacing visible wording doesn’t guarantee that a working form remains working.
A label may be one text object positioned at page coordinates. A field may have its own dictionary and an annotation that controls how it appears. If the translated label grows, the new wording can overlap a control or force a layout change. If an editor rebuilds the page, the visible appearance can change while the underlying field remains elsewhere or becomes unusable.
A source Word or InDesign file can make the work easier to control. The Massachusetts guide recommends improving accessibility in the source document before exporting to PDF, because fixing the source can simplify later PDF remediation. The same source-first approach helps teams manage longer translated labels, leave room for fields, and keep instructions near the controls they describe.
The guide also advises treating the PDF as a publishing output rather than making content edits in Acrobat after accessibility remediation. Changing text may require repeating remediation steps. That doesn’t forbid all PDF editing; it means a late copy change can have structural consequences. If a reviewer changes wording after remediation, send the file back through the relevant accessibility and form checks.
A sample before-and-after review can make the mechanism easier to see:
| Source page | Translated page | What needs checking |
|---|---|---|
| Short label fits beside a field | Longer label wraps to another line | Does the field remain visibly associated with the label? |
| Tooltip matches the source label | Tooltip remains in the source language | Does the user-facing description now conflict with the translated page? |
| Dropdown shows source-language options | Translated options appear | Do the options retain the right order and stored values? |
| Field works in the original PDF | Exported translation is a document file | Are the interactive controls still present and usable? |
A text-based PDF and a scanned form present different translation challenges. A text-based PDF may contain text that can be extracted, but its layout and field behavior still need checking. A scan is an image of a page, so the words first need to be recognized before translation and reconstruction. A signature, stamp, handwriting, or degraded print can make recognition less dependable than clear printed text.
For more on the scan problem, see what AI-OCR can and can’t do with PDFs and scans. Readers working with scan-based translation workflows can also compare PDF support in OmegaT, MateCat, and Wordfast.
“Form fields are added to the PDF after the document itself has been made accessible.”
The order matters: first establish and check the document’s accessible structure, then add or review the interactive controls. A translation project that changes the content after that work should include a check of the affected structure rather than assuming nothing else changed.
Choosing a workflow: bureau, freelance translator, or document tool¶
The right workflow depends on the form’s risk, complexity, source files, and how the output will be used. A simple internal form with clear labels is different from a public application that feeds a database or a form that must meet a specific accessibility process. The comparison below is a planning aid, not a claim that one option suits every project.
| Option | Fits when | Strengths | Trade-offs |
|---|---|---|---|
| Translation bureau | The form needs coordinated translation, review, and production support | One supplier can coordinate roles and delivery requirements | Confirm who handles PDF mechanics, accessibility, field testing, and data-system decisions |
| Freelance translator | The text is the main task and the form owner can manage technical checks | Direct communication with the person translating the wording | The client may need to coordinate form editing, accessibility remediation, and QA separately |
| Document-translation tool | The team wants a translated document draft that it can review and post-edit | Can help retain document layout and support bilingual review | A translated document isn’t proof that the PDF’s interactive fields and accessibility are intact |
A bureau can be useful when several specialists need to coordinate: a translator, a desktop-publishing professional, a form developer, and an accessibility reviewer. Before agreeing on scope, ask whether the bureau will return a working fillable PDF or only translated text or a reformatted document. Ask who checks the tooltips, field settings, tab order, and submission behavior.
A freelance translator can handle language decisions directly with the form owner. The arrangement works best when someone on the client’s side can answer questions about field purpose, field names, export values, and the final PDF. The translator should receive the source file or a clear export of all user-facing strings, not just a screenshot of the first page.
A document-translation tool can help with a document-level first draft, especially when the form includes repeated text or a substantial amount of explanatory content. How it works in ChatsControl: you upload a PDF or DOCX, receive a translated Word document with the layout retained, and review the result before deciding how to produce the final PDF. ChatsControl also provides a bilingual side-by-side review view, which helps a reviewer compare source and translation while checking labels and instructions.
That workflow has a clear boundary. ChatsControl translates documents; the returned Word file isn’t, by itself, a verified interactive PDF form. The team still needs to check or rebuild the PDF fields, tooltips, tab order, and accessibility structure. ChatsControl’s free tier includes 6,000 characters per month; pay-as-you-go pricing is $1.50 per 1,000 characters, with scans charged at the same rate and a minimum of 1,000 characters per page. See the product pricing details for the current figures. Those are product prices, not a quote for PDF field remediation or form testing.
| Project need | Bureau | Freelancer | Document tool |
|---|---|---|---|
| Translate labels and instructions | Can coordinate translation and review | Can translate with direct client input | Can produce a draft for human review |
| Preserve document layout | Confirm the scope and delivery format | Depends on whether layout work is included | ChatsControl returns a translated Word file with document formatting kept in place |
| Preserve interactive fields | Confirm who edits and tests the PDF controls | Usually requires a separate PDF editor or form specialist | The translated Word output needs a separate form-production step |
| Resolve internal field naming | Can coordinate with the form owner | Needs access to the relevant system knowledge | Doesn’t replace a decision by the system owner |
| Validate accessibility | Confirm that this task is explicitly included | Arrange a qualified accessibility review where needed | A translated file isn’t an accessibility audit |
The key comparison isn’t simply “human versus software.” It’s whether the full job includes language, layout, interactive behavior, and accessibility checks, and whether a named person owns each part. A written scope helps prevent the familiar handoff gap in which everyone assumes someone else will test the finished PDF.
A practical field-by-field workflow¶
A reliable workflow keeps the original file, translation decisions, and testing results connected. The steps below work as a project checklist for a form owner, translator, and production reviewer.
-
Collect the source files and define the output. Ask for the original PDF and, if available, the Word or InDesign source. Confirm whether the deliverable must be an editable source, a fillable PDF, or both. Ask who will use the form and what system receives completed responses.
-
Inventory the fields and user-facing text. List each visible label, instruction, tooltip, dropdown option, checkbox, radio option, and error message. Record the field type and location. Mark internal names and export values separately so they don’t get changed as ordinary prose.
-
Resolve ambiguities with the form owner. Identify short or unclear labels, unexplained abbreviations, and instructions that depend on a policy. Ask what each field collects and whether it is required. Keep the answers with the translation brief so the same decision can be applied consistently.
-
Translate and review the content. Translate the visible wording, tooltips, and instructions as a connected set. Check terminology consistency across repeated fields and pages. Keep interface wording concise enough to fit without hiding the meaning. A translator should flag a space problem rather than silently shorten an instruction that changes what the user must do.
-
Rebuild or update the form. Use the source document when it exists, and place visible labels near the controls they describe. Add or retain the fields, then connect each field to the right label and tooltip. Keep identifiers stable unless the form owner confirms that a system change is intended.
-
Check accessibility structure and field settings. Review document language, tags, logical reading order, tooltips, required-field settings, keyboard access, and tab order. Check that the general instructions appear before the first field if users need them before starting. The Massachusetts guide recommends testing manually as well as with automated checks.
-
Test the actual exported PDF. Open the final PDF, fill in each control, move between fields with the keyboard, inspect dropdown choices, and verify that entered values remain visible. Review the form with the intended reader tools where the project requires that testing. Don’t infer success from a screenshot of the page.
-
Record approvals and freeze the tested output. Keep a copy of the source, approved translated wording, and test notes. If a later edit changes labels, tooltips, or page layout, recheck the affected fields and accessibility structure before distribution.
“For this reason, any instructions for the form should be placed before any form fields in your document.”
The quote refers to the guide’s explanation of screen-reader navigation. It gives the form owner a concrete production check: don’t rely on a person encountering an instruction only after they have already moved into the controls.
A sample inventory can make the handoff easier to use:
| Page or section | Visible label | Tooltip or instruction | Field type | Internal name or export value | Owner decision |
|---|---|---|---|---|---|
| Applicant details | Full name | Enter the name shown on the relevant record | Text field | Confirm with system owner | Translate label and tooltip |
| Contact details | Preferred contact method | Choose one option | Dropdown | Confirm stored values | Translate display choices; preserve approved values |
| Declaration | I confirm the information is accurate | Select to confirm | Checkbox | Confirm whether a stored value is required | Keep wording aligned with the checkbox state |
The examples are templates, not claims about a particular form. Replace the sample wording with the form owner’s approved meaning. In particular, don’t add a document requirement or legal declaration that isn’t present in the source.
For projects involving invoices or shipment paperwork, the same discipline applies to labels and data that connect to other records. The article on commercial invoices and packing lists for customs covers those document-specific details.
Common failure points and how to prevent them¶
Automatic field detection is a helpful starting point, not a completed review. The Massachusetts guide says Acrobat’s Prepare Form tool attempts to detect fields and tooltips automatically, but the suggested fields may be inaccurate or incomplete. The guide also says fields should be checked individually before the form is finalized.
An automatic tool might miss a small control, mistake a printed line for an entry field, or suggest an incomplete tooltip. Don’t assume that a field is correct just because it appears in an editor. Compare it with the page, check the field properties, and enter a test response.
| Failure point | Why it causes trouble | Practical check |
|---|---|---|
| Visible label translated, tooltip left in the source language | Users relying on the tooltip receive different information from users reading the page | Compare every tooltip with the final visible label and instructions |
| Internal names translated without approval | A receiving system may depend on the previous identifier | Ask the system owner before changing names or export values |
| Dropdown display text translated but choices not tested | The visible choices can be right while the submitted values are wrong | Select each option and inspect the resulting value or workflow |
| Text changed after remediation | A content edit can affect accessibility work and structure | Recheck the relevant tags, labels, and fields after every late change |
| General instructions placed after the controls | Users navigating in forms mode may reach fields without first encountering the instructions | Place essential instructions before the first field |
| Long translation overlaps the control | The label can become hard to associate with its field | Review the rendered PDF at normal viewing size and adjust the source layout |
| Automated checker used as the only test | A machine check may not catch a confusing label or awkward keyboard route | Combine automated and manual review |
The accessibility guide says PDF tags identify content structure, the purpose of non-text content, and the order in which content is read by screen-reader users. That means a visually convincing page can still have a reading order that doesn’t match the intended sequence. Check structure, not only appearance, with the guide’s PDF forms accessibility advice.
A form’s visible order and its keyboard tab order can also diverge. A user may see the first field at the top of the page but reach a different control first when moving by keyboard. Test the order using the actual controls, then compare it with the form’s intended sequence. The Massachusetts guide includes logical reading order and logical tab order in its checklist.
Translation can also make a form less usable when the translated text is shortened too aggressively. A compact label may fit but lose a distinction that matters. If the source wording doesn’t fit, ask whether the layout can give the label more room or move the instruction into a tooltip without removing essential information from the page.
For a scan-only source, reviewers need to compare the reconstructed text with the image. Optical character recognition can misread a mark, seal, handwritten note, or low-quality print. A scan workflow should identify uncertain text for human verification instead of treating every recognized character as reliable. See the related guide on translating scanned PDFs in Trados Studio.
Regional and organizational requirements¶
Translation requirements and accessibility expectations depend on the form’s purpose, audience, and organization. The sources here explain technical and accessibility practices; they don’t establish a single rule for all countries, agencies, or private companies. Ask the organization receiving the form which language versions it accepts and whether it requires a particular format or certification.
The Massachusetts guide is government accessibility guidance, and its statements should be read in that scope. The guide itself recommends considering whether a web-based form may be more suitable. It says web forms can support collection and analysis because entries typically go directly to a central database or spreadsheet. That is a workflow consideration, not a claim that a web form is always the right substitute.
A web form may suit a process where data needs to feed a system directly. A PDF may remain appropriate when users need a document they can download, save, print, or complete offline. The form owner should decide based on the users’ access needs, the receiving process, and the way responses are handled.
The Australian Government’s Language Services Guidelines provide another official reference for planning language services. Use the guidance relevant to the organization and audience rather than assuming that a translated PDF satisfies every local or institutional requirement.
The PDF specification source is a technical reference, not a country’s submission policy. The PDF Specification Archive can help locate specification materials, while the ISO 32000-1:2008 authorized PDF 1.7 copy describes the format edition cited in this article. Neither source tells a particular agency what language or certification it accepts.
Before production, ask the receiving organization:
- Does it accept a translated fillable PDF, or does it require a different submission format?
- Does it provide an approved translation or glossary for recurring terms?
- Does it require an accessible PDF, and which accessibility standard or testing method applies?
- Does the form connect to an existing database that depends on current field names or export values?
- Does the organization require a certified translation, or is an ordinary translated form sufficient?
- Who approves changes to declarations, required fields, and data collection instructions?
A clear answer can prevent a technically correct translation from being delivered in a format the receiving process can’t use. If the organization requires an officially certified translation of supporting documents, that is a separate service from localizing a fillable form. ChatsControl’s certified translation route involves a human translator; it isn’t an automatic step in document translation.
FAQ¶
How do you translate a fillable PDF without losing its fields?¶
Keep the original PDF and its interactive structure available, translate the visible labels and user-facing descriptions, then check the exported PDF field by field. A translated Word document or page image isn’t proof that interactive behavior survived; test the final PDF itself.
Which parts of a fillable PDF form should be translated?¶
Translate the user-facing labels, instructions, tooltips, dropdown choices, and relevant error messages. Review accessibility text as well. Decide separately whether internal field names and export values should stay unchanged, because connected systems may depend on them.
Should PDF form field names and export values be translated?¶
Not automatically. Field names and export values can be used by a database or another process, so ask the form or system owner before changing them. Translate the wording people see while keeping machine-facing identifiers stable when the existing workflow depends on them.
How do you test a translated PDF form for accessibility and usability?¶
Review each field manually, then check the document language, tags, reading order, visible labels, matching tooltips, keyboard access, and tab order. Use automated checks as one part of testing, not as the only validation.
Can an automatically detected PDF form be translated without review?¶
No. Acrobat’s Prepare Form tool can suggest fields and tooltips, but the Massachusetts guide says those suggestions can be inaccurate or incomplete. Check the fields individually before finalizing the form.
Will translating a PDF form make it accessible?¶
No. Translation doesn’t create accessibility by itself. The Massachusetts guide describes accessible forms as tagged PDFs with interactive fields and associated tooltips, and its checklist also includes reading order, document language, keyboard access, and logical tab order.
Can I change translated wording in Acrobat after accessibility remediation?¶
A text change can affect remediation, so the Massachusetts guide advises treating the PDF as a publishing output and making content edits in the source document before exporting. Recheck the affected accessibility work after a late change rather than assuming the PDF remains valid.
Should I use a PDF or a web form?¶
Choose based on how people need to complete the form and how the organization processes responses. The Massachusetts guide recommends considering a web form and notes that entries can go directly to a central database or spreadsheet, but that doesn’t make a web form the right choice for every process.