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

TL;DR

Key Takeaways

• Japan's 2024 law revision made private-sector accessibility legally mandatory — enterprise SaaS procurement teams in Japan now include accessibility conformance questions in vendor assessments.
• PC-Talker and NVDA Japanese dominate — JAWS does not — testing strategy built on JAWS assumptions will miss the screen readers most Japanese users actually rely on.
• 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 aligns with WCAG 2.1 but adds Japanese-specific text handling requirements — phonetic annotation (furigana) guidance and reading order conventions that WCAG does not address.

Japan's 2024 Barrier-Free Act Revision: What Changed

Before April 2024, Japan's Act for Eliminating Discrimination against Persons with Disabilities (障害者差別解消法, Shougaisha Sabetsu Kaishou Hou) imposed legally binding non-discrimination requirements on public-sector organizations, while encouraging — but not requiring — private-sector companies to provide reasonable accommodation. The 2024 revision closed this gap. Private-sector businesses, including software and online service providers, are now legally obligated to provide reasonable accessibility accommodation. Failure to do so, when accommodation is feasible, constitutes prohibited discrimination under Japanese law.

The practical implications for SaaS companies are still developing through case law and guidance documents, but the procurement signal is already clear. Japanese enterprise clients — particularly those in the public sector, financial services, healthcare, and education — now routinely include accessibility conformance requirements in vendor assessments. A product that cannot demonstrate JIS X 8341-3 Level AA conformance (Japan's WCAG-equivalent standard) faces increasing disqualification risk in enterprise procurement, regardless of feature parity with competitors.

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 holds the largest market share in North America and Europe. For Japan, this assumption is incorrect and leads to testing strategies that miss the screen readers most Japanese users actually depend on.

The two screen readers that dominate Japanese accessibility use are PC-Talker and NVDA with Japanese language packs. PC-Talker — developed by High-Tech Laboratory Japan — 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 the primary choice for Japanese users who rely on screen readers 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 Japanese accessibility best practice recommends using furigana annotations (phonetic ruby text) for specialized terminology that may be misread — a practice WCAG does not address but JIS X 8341-3 does.

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 technically aligned with WCAG 2.1 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.

The differences that matter for Japanese SaaS localization are in the Japanese-specific annexes. JIS X 8341-3 includes guidance on phonetic annotation (furigana / ruby text) for kanji-heavy content, recommending that complex or specialized kanji include phonetic readings accessible to both sighted users and screen readers. It includes guidance on reading order in mixed vertical-horizontal text layouts, which affects products that use Japanese vertical writing (tategumi) in any part of the UI. And it addresses the use of kanji numerals versus Arabic numerals in accessible content — a distinction that matters for date formats, headings, and numbered lists in Japanese UI.

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

Frequently Asked Questions