Japanese Accessibility Localization:
Screen Readers, Alt Text, and ARIA Labels for SaaS Products

TL;DR

Key Takeaways

• Japan's 2024 law revision made reasonable accommodation on request mandatory for private companies — website accessibility (environment improvement, Article 5) remains an effort obligation, but it is the practical way to reduce individual requests.
• PC-Talker and NVDA Japanese are widely used in Japan — a testing strategy built only on JAWS assumptions can miss how Japanese screen reader users actually hear your UI.
• Japanese alt text is more concise than English equivalents — kanji density means shorter text serves the same informational purpose; lengthy alt text creates listening fatigue on Japanese screen readers.
• ARIA labels must be functional, not honorific — screen reader announcements are task-oriented; polite Japanese register in an aria-label is noise that slows navigation.
• JIS X 8341-3:2016 is identical in content to WCAG 2.0 — Japanese readings are covered by WCAG's own success criteria 3.1.3 Unusual Words and 3.1.6 Pronunciation (Level AAA), not by extra JIS requirements.

Japan's 2024 Disability Discrimination Act Revision: What Changed

Before April 2024, Japan's Act for Eliminating Discrimination against Persons with Disabilities (障害者差別解消法, Shougaisha Sabetsu Kaishou Hou) already required public bodies to provide reasonable accommodation, while private-sector businesses were under an effort obligation only. The 2024 revision closed this gap: since 1 April 2024, private-sector businesses, including software and online service providers, must provide reasonable accommodation when a person with a disability asks for it, unless the burden is excessive. The Cabinet Office separates this from environment improvement in advance (Article 5), such as making a website accessible, which remains an effort obligation.

For SaaS companies, the binding part is the response to individual requests. Website conformance is not itself a legal requirement for private companies, but it is the most practical way to reduce how often accommodation requests arise. Japanese public bodies are also asked by the Ministry of Internal Affairs and Communications to meet JIS X 8341-3:2016 Level AA on their own websites, so clients in the public sector and regulated industries may ask vendors about the same standard. Documenting your conformance level in advance is worth the effort.

What this means for localization is that Japanese accessibility work can no longer be treated as an enhancement applied after the product is launched. It needs to be built into the Japanese UI layer alongside translation — which means ARIA labels, alt text, form error announcements, and focus management all need Japanese-language content that was written for screen readers, not for sighted users reading a tooltip.

The Japanese Screen Reader Landscape

Accessibility testing for English-language products is typically built around JAWS (Job Access With Speech), which is widely used in North America and Europe. For Japan, relying on JAWS alone leads to testing strategies that miss screen readers widely used by Japanese users.

Two screen readers widely used in Japan are PC-Talker and NVDA with Japanese language packs. PC-Talker — developed by Kochi System Development, Inc. (株式会社高知システム開発) — is purpose-built for Japanese text and handles kanji reading order, pronunciation disambiguation (the same kanji can have multiple readings), and Japanese-specific punctuation natively. It is a common choice among Japanese users who rely on a screen reader as their main computer interface. NVDA with Japanese packs is the open-source alternative, widely used by technically oriented users and developers testing accessibility. Apple VoiceOver with Japanese language support is the relevant tool for iOS-adjacent workflows and macOS testing.

The behavioral differences between these tools and JAWS matter for localization. PC-Talker reads kanji using its built-in dictionary to resolve pronunciation; when a kanji compound is ambiguous (the same string could have different readings in different business contexts), the screen reader may choose the wrong reading. This is why it helps to provide readings (furigana or ruby text) for specialized terminology that may be misread — a practice covered by WCAG success criterion 3.1.6 Pronunciation (Level AAA), which JIS X 8341-3:2016 shares.

Alt Text in Japanese: Length, Kanji Strategy, and Reading Order

Japanese alt text is not English alt text translated into Japanese. The conventions differ enough that treating it as a translation task produces alt text that is either too long (creating listening fatigue), phonetically ambiguous (kanji that could be misread), or organized in the wrong order for the content being described.

Length: Japanese kanji packs significantly more information per character than English prose. A well-written Japanese alt text of 20-30 characters can convey what English requires 60-80 characters to say. This is not an argument for shorter Japanese alt text — it is a constraint that makes over-long Japanese alt text especially fatiguing to screen reader users. The convention is to describe the essential content and function of the image, without the English tendency toward comprehensive description.

Kanji reading strategy: When an image contains kanji text — a chart label, a product name, a document title — the alt text must handle the kanji reading explicitly. Simply repeating the kanji in the alt attribute leaves the screen reader to guess the pronunciation. For terms with unambiguous common readings, this works. For specialized business vocabulary (financial terms, legal terminology, product names with unusual readings), the alt text should provide the phonetic reading alongside or instead of the kanji alone.

Decorative images: The rule is identical to WCAG — decorative images use empty alt attributes (alt=""). This requires active judgment, not automation, because what counts as decorative in a Japanese UI may differ from the English source: an icon that was purely decorative in the English design may carry semantic weight in the Japanese UI where text has been condensed.

ARIA Label Conventions in Japanese

ARIA labels in Japanese SaaS products fail in four predictable patterns, and all four come from treating ARIA label localization as a translation task rather than a content-writing task for a functional announcement audience.

Pattern 1: English ARIA labels left untranslated. This is the most common failure. The visible UI text is translated into Japanese, but the aria-label attributes — invisible to sighted users — remain in English. A screen reader user navigating a fully Japanese interface will encounter English announcements for interactive elements. This is a jarring context switch that signals the accessibility layer was not included in the localization scope.

<button aria-label="Close dialog">×</button>
<!-- Screen reader announces: "Close dialog, button" in English
     while the rest of the UI is Japanese -->

<button aria-label="ダイアログを閉じる">×</button>
<!-- Screen reader announces: "ダイアログを閉じる、ボタン"
     Consistent Japanese throughout -->

Pattern 2: Honorific register in ARIA labels. Japanese has multiple politeness registers, and the instinct when writing Japanese for a product UI is to use polite or honorific language. ARIA labels are functional announcements, not social communications. A screen reader user navigating a toolbar hears every button's aria-label in sequence — honorific padding slows them down without adding information. The correct register for Japanese ARIA labels is plain-form functional Japanese: the action the element performs, stated directly.

Pattern 3: Visual description instead of function description. An aria-label that describes what an element looks like — rather than what it does — is useful only if the user can see the element. Screen reader users need to know the element's function. "青いアイコン" (blue icon) is not an ARIA label. "通知を確認する" (check notifications) is.

Pattern 4: Landmark labels missing or untranslated. ARIA landmark roles (navigation, main, complementary, form, search) help screen reader users jump between sections. Japanese-language products should label these landmarks in Japanese so announcements are consistent. An untranslated landmark label creates the same context-switch problem as an untranslated button label.

<nav aria-label="メインナビゲーション">...</nav>
<nav aria-label="パンくずリスト">...</nav>
<section aria-label="関連記事">...</section>
<!-- Screen reader: "メインナビゲーション、ナビゲーション"
     rather than "Main navigation, navigation" mid-Japanese-UI -->

Japanese Form Accessibility: Labels, Errors, and Required Fields

Japanese form accessibility has conventions that differ from both the technical ARIA specification defaults and English-market practice. The three areas with the most localization decisions are: required field marking, error announcement patterns, and the label association between form fields and their instructions.

Required field marking: English forms conventionally mark required fields with an asterisk (*) and a legend noting "Fields marked with * are required." Japanese forms use a separate convention: required fields are marked with the label 必須 (hissu — required) as a visible badge, typically in a red or orange tag next to the field label. The asterisk convention is understood by Japanese users but reads as foreign. The 必須 badge convention is the native standard and should be used alongside the programmatic aria-required="true" for screen reader support.

<label for="company-name">
  会社名 <span class="required-badge" aria-label="必須">必須</span>
</label>
<input type="text" id="company-name"
       aria-required="true"
       aria-describedby="company-name-error">
<!-- Screen reader: "会社名、必須、テキストフィールド、必須項目" -->

Error announcement patterns: When a Japanese form submission fails validation, the error announcement must follow a four-part pattern that Japanese screen reader users expect: (1) identify which field has the error, (2) state what was wrong with the input, (3) state what the correct input should be, and (4) indicate that the field needs to be corrected before resubmitting. Partial error messages — which name the problem without stating the correction — leave users unable to fix the issue without sighted assistance.

<span role="alert" id="email-error">
  メールアドレスが正しくありません。
</span>
<!-- Missing: what IS a correct email address format for this field -->

<span role="alert" id="email-error">
  メールアドレス欄にエラーがあります。
  入力されたメールアドレスの形式が正しくありません。
  半角英数字で「[email protected]」の形式で入力してください。
</span>
<!-- Field identified / problem stated / correct format shown / action implied -->

Focus Management in Japanese Modal Dialogs

Focus management in Japanese modal dialogs introduces a localization decision that has no direct English equivalent: the announcement of the close action. English-language accessibility practice typically uses aria-label="Close dialog" or aria-label="Close" on the × button. Japanese practice has an established convention — 「×で閉じる」 (close with ×) — that reflects how Japanese UI documentation describes the action. The more natural Japanese aria-label is 「ダイアログを閉じる」 (close the dialog) or, for a modal with a specific title, 「[modal title]を閉じる」.

The deeper focus management question is modal dialog role announcement. When a modal dialog opens in Japanese, the screen reader should announce the dialog's purpose in Japanese, not just the generic role. An aria-labelledby pointing to a Japanese title element, and an aria-describedby pointing to a Japanese description, ensures the context is established when focus moves into the dialog.

<div role="dialog"
     aria-labelledby="modal-title"
     aria-describedby="modal-desc"
     aria-modal="true">
  <h2 id="modal-title">削除の確認</h2>
  <p id="modal-desc">このファイルを削除してもよいですか？この操作は取り消せません。</p>
  <button>削除する</button>
  <button aria-label="削除の確認を閉じる">×</button>
</div>
<!-- On focus: "削除の確認、ダイアログ、このファイルを削除してもよいですか…" -->

JIS X 8341-3 and Color Contrast

JIS X 8341-3 (formally: Guidelines for older persons and persons with disabilities — Information and communications equipment, software and services — Part 3: Web content) is identical in content to WCAG 2.0 (via ISO/IEC 40500:2012) at the same three conformance levels (A, AA, AAA). For most technical requirements — color contrast ratios, keyboard navigation, time-based media captions — meeting WCAG 2.1 AA means meeting JIS X 8341-3 AA.

JIS X 8341-3:2016 does not add Japanese-only success criteria; its JIS-specific items sit in informative annexes. Japanese readings are handled by WCAG itself: success criterion 3.1.3 Unusual Words asks for a mechanism to identify definitions of words used in an unusual or restricted way, and 3.1.6 Pronunciation asks for a mechanism to identify pronunciation where meaning is ambiguous without it. Both are Level AAA, beyond the usual AA target, but for kanji-heavy business terminology they are worth applying selectively. Reading order in mixed vertical-horizontal layouts (tategumi) and the choice between kanji and Arabic numerals in dates, headings, and numbered lists are practical localization decisions rather than JIS requirements.

The color contrast requirement is identical to WCAG 2.1: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold), at Level AA. What changes in a Japanese-language implementation is that Japanese body text — which often mixes kanji, kana, and Latin characters at the same font size — must meet this ratio at the actual rendering weight, which can differ from the design specification if the Japanese font and the Latin fallback render at different visual weights.

Japanese Accessibility Localization Checklist

Reading the Law and the Standard Together: A Five-Step Check for Your Japanese Site

Three Japanese documents come up when a Japanese customer asks about accessibility, and they do different jobs. The Cabinet Office's own explanation of the revised Act for Eliminating Discrimination against Persons with Disabilities (Act No. 65 of 2013, amended by Act No. 56 of 2021, in force from 1 April 2024) separates two duties. Providing reasonable accommodation (合理的配慮の提供) in response to an individual request is now a legal obligation for private businesses, as it already was for public bodies. Improving the environment in advance (環境の整備, Article 5), which is where accessible websites and information access sit, remains an effort obligation (努力義務) for both. In other words, the Act does not by itself make a non-conforming website unlawful; how it applies to a specific product or request is a question for Japanese counsel.

1. Map your audit to WCAG 2.0 numbering. JIS X 8341-3:2016 is WCAG 2.0, so a WCAG 2.1 AA report already covers its success criteria. Watch one gap: WCAG 2.2 marks 4.1.1 Parsing as obsolete, so a 2.2-only report may say nothing about a criterion that a JIS-based checklist still lists.
2. Test the Japanese build, not the English one. Run the checks on the rendered Japanese pages: lang="ja" on the document, Japanese alt text and labels, and error text as a screen reader announces it.
3. Publish a Japanese accessibility policy page. Japanese public bodies publish a ウェブアクセシビリティ方針 that names the standard, the target level, the scope, and test results. The Cabinet Office's own page follows this pattern and was last revised in March 2025. Japanese customers recognise the format.
4. Open a request channel in Japanese. This is the legally binding part. Provide a contact route for accommodation requests, decide in advance which alternatives you can offer (another format, another channel, assisted completion of a form), and keep a record of each request and response.
5. Cite documents with their year. In vendor questionnaires write "JIS X 8341-3:2016" and "WCAG 2.0 / 2.1 AA", not just "JIS compliant". Japanese reviewers check the edition.

Sources: Cabinet Office, 障害者差別解消法; Digital Agency, ウェブアクセシビリティ導入ガイドブック; Web Accessibility Infrastructure Committee (WAIC), JIS X 8341-3:2016 Q&A; Cabinet Office, web accessibility policy.

Frequently Asked Questions