2024年に改正された障害者差別解消法により、アクセシビリティはベストプラクティス上の推奨から、民間企業にとっての法令遵守要件へと移りました。日本市場に参入するSaaS製品にとって、これは日本語スクリーンリーダーの挙動、JIS X 8341-3への適合、代替テキストの書き方の慣行、ARIAラベルのローカライゼーションが、いまや調達レベルの関心事——リリース後に後追いで対処するものではない——になったことを意味します。
2024年4月より前、日本の障害者差別解消法（Shougaisha Sabetsu Kaishou Hou）は、公的機関に対して法的拘束力のある差別禁止の要件を課す一方、民間企業には合理的配慮の提供を奨励する——求めはするが義務化はしない——にとどまっていました。2024年の改正は、このギャップを埋めました。ソフトウェアやオンラインサービスの提供者を含む民間事業者は、いまや合理的なアクセシビリティ配慮を提供する法的義務を負います。配慮が実現可能であるにもかかわらずそれを怠ることは、日本の法律上、禁止される差別に該当します。
SaaS企業にとっての実務上の影響は、判例やガイダンス文書を通じてなお形成途上ですが、調達からのシグナルはすでに明確です。日本のエンタープライズ顧客——とりわけ公共部門、金融サービス、医療、教育の領域——は、いまやベンダー評価にアクセシビリティ適合性の要件を日常的に含めています。JIS X 8341-3のレベルAA適合（日本のWCAG相当規格）を示せない製品は、競合との機能の同等性にかかわらず、エンタープライズ調達で失格となるリスクが高まっています。
これがローカライゼーションにとって意味するのは、日本語のアクセシビリティ対応をもはや製品リリース後に施す追加機能として扱えない、ということです。それは翻訳と並んで日本語UI層に作り込む必要があります——つまり、ARIAラベル、代替テキスト、フォームのエラー読み上げ、フォーカス管理のすべてが、ツールチップを読む晴眼ユーザー向けではなく、スクリーンリーダー向けに書かれた日本語コンテンツを必要とするということです。
英語製品のアクセシビリティテストは、通常JAWS（Job Access With Speech）を中心に組まれます。北米とヨーロッパで最大のシェアを持つためです。日本については、この前提は誤りであり、日本のユーザーの多くが実際に頼っているスクリーンリーダーを見落とすテスト戦略につながります。
日本のアクセシビリティ利用で主流の2つは、PC-Talkerと日本語言語パックを入れたNVDAです。PC-Talker——高知システム開発によって開発——は日本語テキスト向けに専用設計されており、漢字の読み順、発音の判別（同じ漢字でも複数の読みがありうる）、日本語特有の句読点をネイティブに処理します。スクリーンリーダーをコンピューターの主要なインターフェースとして頼る日本のユーザーにとっての第一の選択肢です。日本語パック入りのNVDAは、オープンソースの代替で、技術志向のユーザーやアクセシビリティをテストする開発者の間で広く使われています。日本語対応のApple VoiceOverは、iOS関連のワークフローやmacOSでのテストに関わるツールです。
これらのツールとJAWSの挙動の違いは、ローカライゼーションにとって重要です。PC-Talkerは、組み込み辞書を使って発音を解決しながら漢字を読み上げます。漢字の熟語が曖昧なとき（同じ文字列が業務上の文脈によって異なる読みを持ちうるとき）、スクリーンリーダーは誤った読みを選ぶことがあります。これが、誤読されうる専門用語にはふりがな（ルビ）の注記を使うことを日本のアクセシビリティのベストプラクティスが推奨する理由です——WCAGが扱わず、JIS X 8341-3が扱う実務です。
| スクリーンリーダー | 市場での位置づけ（日本） | 主要な日本語対応能力 | テストの優先度 |
|---|---|---|---|
| PC-Talker | 主流・トップシェア | 日本語向けに開発。漢字の発音、読み順、日本語の句読点をネイティブに処理 | 高——日本市場の主要テスト対象 |
| NVDA＋日本語 | 第二・開発者が使用 | オープンソース。日本語言語パックで読み上げに対応するが、PC-Talkerより精度は劣る | 高——アクセシビリティQAのオープンソース基準 |
| VoiceOver（日本語） | Appleエコシステム | 日本語対応が強力。iOSのウェブアプリやmacOS向けSaaSに関係 | 中——モバイルやmacOSの利用者がいる製品では必須 |
| JAWS | 日本では小規模 | 日本語最適化が限定的。英語市場向けの製品 | 低——日本語の主要テストツールとしては使わない |
日本語の代替テキストは、英語の代替テキストを日本語に訳したものではありません。慣行の違いは十分に大きく、これを翻訳作業として扱うと、長すぎる（聴取の疲労を生む）、発音が曖昧（誤読されうる漢字）、あるいは説明対象の内容に対して順序が誤っている、いずれかの代替テキストが生まれます。
長さ：日本語の漢字は、英語の散文より1文字あたりの情報量が大幅に多くなります。よく書かれた20〜30文字の日本語の代替テキストは、英語なら60〜80文字を要することを伝えられます。これは「日本語の代替テキストは短くせよ」という主張ではありません——長すぎる日本語の代替テキストを、スクリーンリーダー利用者にとってとりわけ疲れるものにする制約なのです。慣行は、画像の本質的な内容と機能を、英語にありがちな網羅的な説明傾向を持ち込まずに記述することです。
漢字の読み戦略：画像に漢字テキスト——グラフのラベル、製品名、ドキュメントのタイトル——が含まれるとき、代替テキストは漢字の読みを明示的に扱わなければなりません。alt属性に漢字をただ繰り返すだけでは、発音の推測をスクリーンリーダーに委ねることになります。曖昧さのない一般的な読みを持つ用語ならこれで機能します。専門的な業務語彙（金融用語、法律用語、変わった読みを持つ製品名）については、代替テキストは漢字だけでなく、その音（読み）を併記、あるいは漢字に代えて提示すべきです。
装飾的な画像：ルールはWCAGと同じです——装飾的な画像は空のalt属性（alt=""）を使います。これは自動化ではなく能動的な判断を必要とします。なぜなら、日本語UIで何が装飾的とみなされるかは、英語ソースと異なりうるからです。英語デザインでは純粋に装飾だったアイコンが、テキストを凝縮した日本語UIでは意味的な重みを帯びることがあります。
日本語SaaS製品におけるARIAラベルは、予測可能な4つのパターンで失敗します。そしてその4つすべては、ARIAラベルのローカライゼーションを、機能的な読み上げの受け手に向けたコンテンツ作成作業ではなく、翻訳作業として扱うことから生じます。
パターン1：英語のARIAラベルが未翻訳のまま。これが最も多い失敗です。目に見えるUIテキストは日本語に翻訳されているのに、aria-label属性——晴眼ユーザーには見えない——が英語のまま残ります。完全に日本語化されたインターフェースをたどるスクリーンリーダー利用者は、対話的な要素について英語の読み上げに出くわします。これは不快な文脈の切り替えであり、アクセシビリティ層がローカライゼーションの範囲に含まれていなかったことを物語ります。
<button aria-label="Close dialog">×</button> <!-- スクリーンリーダーの読み上げ：「Close dialog, button」と英語で。 UIの他の部分は日本語なのに -->
<button aria-label="ダイアログを閉じる">×</button> <!-- スクリーンリーダーの読み上げ：「ダイアログを閉じる、ボタン」 全体を通じて一貫した日本語 -->
パターン2：ARIAラベルに敬語の語調。日本語には複数の丁寧度の語調があり、製品UI向けに日本語を書くときの直感は、丁寧語や敬語を使うことです。ARIAラベルは機能的な読み上げであって、社交的なコミュニケーションではありません。ツールバーをたどるスクリーンリーダー利用者は、すべてのボタンのaria-labelを順番に聞きます——敬語の付け足しは、情報を加えずに彼らを遅くします。日本語のARIAラベルに正しい語調は、常体の機能的な日本語です。要素が実行するアクションを、直接に述べることです。
パターン3：機能の説明ではなく見た目の説明。要素が何をするかではなく、どう見えるかを説明するaria-labelは、ユーザーがその要素を見られる場合にしか役立ちません。スクリーンリーダー利用者が知る必要があるのは、要素の機能です。「青いアイコン」はARIAラベルではありません。「通知を確認する」がARIAラベルです。
パターン4：ランドマークのラベルが欠落、または未翻訳。ARIAのランドマークロール（navigation、main、complementary、form、search）は、スクリーンリーダー利用者がセクション間を移動するのを助けます。日本語の製品は、読み上げが一貫するように、これらのランドマークを日本語でラベル付けすべきです。未翻訳のランドマークラベルは、未翻訳のボタンラベルと同じ文脈切り替えの問題を生みます。
<nav aria-label="メインナビゲーション">...</nav> <nav aria-label="パンくずリスト">...</nav> <section aria-label="関連記事">...</section> <!-- スクリーンリーダー：「メインナビゲーション、ナビゲーション」 日本語UIの途中で「Main navigation, navigation」とならずに -->
日本語フォームのアクセシビリティには、技術的なARIA仕様の既定値とも、英語市場の慣行とも異なる慣行があります。ローカライゼーション判断が最も多い3つの領域は、必須項目の表示、エラーの読み上げパターン、そしてフォーム項目とその説明とのラベルの関連付けです。
必須項目の表示：英語のフォームは、慣例的に必須項目をアスタリスク（*）と「*印の項目は必須です」という凡例で示します。日本語のフォームは別の慣行を使います。必須項目は、ラベルの必須（hissu — required）を、項目ラベルの隣の赤やオレンジのタグとして、見える形のバッジで示します。アスタリスクの慣行も日本のユーザーには理解されますが、外来のものとして読まれます。「必須」バッジの慣行はネイティブの標準であり、スクリーンリーダー対応のためにプログラム上のaria-required="true"と併せて使うべきです。
<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"> <!-- スクリーンリーダー：「会社名、必須、テキストフィールド、必須項目」 -->
エラーの読み上げパターン：日本語のフォーム送信がバリデーションに失敗したとき、エラーの読み上げは、日本語のスクリーンリーダー利用者が期待する4部構成のパターンに従う必要があります。(1) どの項目にエラーがあるかを特定する、(2) 入力の何が誤っていたかを述べる、(3) 正しい入力がどうあるべきかを述べる、(4) 再送信の前にその項目を修正する必要があることを示す。問題を指摘するだけで修正方法を述べない部分的なエラーメッセージは、晴眼者の助けなしにはユーザーが問題を直せない状態を残します。
<span role="alert" id="email-error"> メールアドレスが正しくありません。 </span> <!-- 欠落：この項目で正しいメールアドレスの形式は何なのか -->
<span role="alert" id="email-error"> メールアドレス欄にエラーがあります。 入力されたメールアドレスの形式が正しくありません。 半角英数字で「[email protected]」の形式で入力してください。 </span> <!-- 項目を特定 / 問題を提示 / 正しい形式を提示 / 行動を示唆 -->
日本語のモーダルダイアログにおけるフォーカス管理は、英語に直接の対応物がないローカライゼーション判断をもたらします——閉じるアクションの読み上げです。英語のアクセシビリティ慣行は、通常×ボタンに aria-label="Close dialog" や aria-label="Close" を使います。日本語の慣行には確立された言い回し——「×で閉じる」——があり、日本のUIドキュメントがそのアクションをどう説明するかを反映しています。より自然な日本語のaria-labelは、「ダイアログを閉じる」、あるいは特定のタイトルを持つモーダルなら「[モーダルのタイトル]を閉じる」です。
より深いフォーカス管理の論点は、モーダルダイアログのロールの読み上げです。日本語でモーダルダイアログが開くとき、スクリーンリーダーは汎用のロールだけでなく、ダイアログの目的を日本語で読み上げるべきです。日本語のタイトル要素を指すaria-labelledbyと、日本語の説明を指すaria-describedbyは、フォーカスがダイアログ内に移ったときに文脈が確立されることを保証します。
<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> <!-- フォーカス時：「削除の確認、ダイアログ、このファイルを削除してもよいですか…」 -->
JIS X 8341-3（正式名称：高齢者・障害者等配慮設計指針——情報通信における機器、ソフトウェア及びサービス——第3部：ウェブコンテンツ）は、同じ3つの適合レベル（A・AA・AAA）でWCAG 2.1と技術的に整合しています。ほとんどの技術要件——カラーコントラスト比、キーボード操作、時間依存メディアの字幕——については、WCAG 2.1 AAを満たすことは、JIS X 8341-3 AAを満たすことを意味します。
日本語SaaSのローカライゼーションにとって重要な違いは、日本語特有の附属書にあります。JIS X 8341-3は、漢字の多いコンテンツに対する音声表記（ふりがな／ルビ）のガイダンスを含み、複雑または専門的な漢字には、晴眼ユーザーとスクリーンリーダーの双方がアクセスできる音（読み）を付けることを推奨します。縦書きと横書きが混在するレイアウトでの読み順のガイダンスも含み、これはUIのどこかで日本語の縦組み（tategumi）を使う製品に影響します。そして、アクセシブルなコンテンツにおける漢数字とアラビア数字の使い分けも扱っており——これは日本語UIの日付形式、見出し、番号付きリストにとって重要な区別です。
カラーコントラストの要件はWCAG 2.1と同一です。レベルAAで、通常のテキストは4.5:1、大きなテキスト（18pt、または14ptの太字）は3:1。日本語実装で変わるのは、日本語の本文——同じフォントサイズで漢字・かな・ラテン文字が混在することが多い——が、実際のレンダリングの太さでこの比率を満たさなければならない点です。日本語フォントとラテン文字のフォールバックが異なる視覚的な太さでレンダリングされる場合、それはデザイン仕様と異なりうるからです。
ARIAラベルのローカライゼーション、代替テキストの漢字戦略、フォームのエラー読み上げ、JIS X 8341-3への適合は、いずれも英語のアクセシビリティ監査に合格する製品が日本語の監査で失敗する領域です。ミニ診断は、日本語のアクセシビリティ層を特に対象とします——技術的な適合ツールが捉えないコンテンツの判断です。
ミニ診断を依頼する2024年の日本のアクセシビリティ法改正で、SaaS企業にとって何が変わりましたか？
2024年の障害者差別解消法の改正により、合理的配慮の提供義務が、ソフトウェアやオンラインサービスの提供者を含む民間事業者にまで拡大されました。改正前、民間企業は配慮の提供を奨励される——求められるが義務ではない——にとどまっていました。2024年4月以降は、合理的なアクセシビリティ配慮を提供しないことが、日本の法律上、禁止される差別に該当します。日本で事業を行うSaaS企業にとって、これはアクセシビリティがもはやベストプラクティス上の差別化要素ではなく、法令遵守の要件であることを意味します。特に、調達チームがベンダー評価にアクセシビリティ適合性を日常的に含めるようになったエンタープライズ契約では顕著です。
SaaS製品はどの日本語スクリーンリーダーに対応する必要がありますか？
日本のアクセシビリティ利用で主流の2つは、PC-Talker（高知システム開発によって開発）と、日本語言語パックを入れたNVDAです。PC-Talkerは日本語テキスト向けに専用設計されており、漢字の読み順、発音の判別、日本語特有の句読点をネイティブに処理します。日本語パック入りのNVDAは、開発者や技術志向のユーザーが使うオープンソースの代替です。英語圏で主流のJAWSは日本でのシェアが小さく、日本市場向けSaaSの主要なテスト対象ではありません。日本語対応のApple VoiceOverも、iOS関連のワークフローでは関係します。
日本語の代替テキストは英語の代替テキストとどう書き分けるべきですか？
日本語の代替テキストは、英語との構造的な違いをいくつか考慮する必要があります。読み順の扱いが異なります——スクリーンリーダーは既定で横方向に左から右へ読むため、代替テキストはその順序で画像を説明すべきです。長さの慣行も異なります。漢字は1文字あたりの情報量が多いため、日本語の代替テキストは英語版より簡潔になるのが通例で、長すぎる代替テキストは聴取の疲労を生みます。スクリーンショットや画像内の漢字が多いテキストは、正確な用語の理解が文脈上必要なとき、代替テキストで音（読み）を明示する必要があります——「売上高」というグラフのラベルは、漢字を読みなしで残すのではなく「売上高（うりあげだか）」のように説明すべきです。装飾的な画像は、英語の慣行と同様に空のalt属性（alt=""）を使います。
日本語SaaSのローカライゼーションで最も多いARIAラベルの誤りは何ですか？
日本語SaaSで最も多いARIAラベルの誤りは4つです。(1) 他のUIテキストはすべて翻訳されているのに、英語のARIAラベルが未翻訳のまま残ること——スクリーンリーダーが、日本語のインターフェースの中で英語で読み上げてしまいます。(2) ARIAラベルに過剰に丁寧な敬語表現を使うこと——スクリーンリーダーの読み上げは機能的なものであって社交的なものではなく、丁寧な表現は聴取の疲労を加えます。(3) ARIAのロール名を、日本語のアクセシビリティツールが期待する標準的な日本語の用語ではなく、字義どおりに訳すこと。(4) 要素の機能ではなく見た目を説明するaria-labelテキストを書くこと——「青いアイコン」は役に立ちませんが、「通知を確認する」はボタンが何をするのかをユーザーに伝えます。
JIS X 8341-3とは何で、WCAGとどう関係しますか？
JIS X 8341-3は、ウェブアクセシビリティに関する日本産業規格で、正式名称は「高齢者・障害者等配慮設計指針——情報通信における機器、ソフトウェア及びサービス——第3部：ウェブコンテンツ」です。適合レベルA・AA・AAAにおいてWCAG 2.1と技術的に整合しています。日本の行政調達はJIS X 8341-3のレベルAA適合を要求しており、2024年の法改正以降、民間のエンタープライズ調達もこの要件を次第に踏襲しています。WCAG 2.1 AAを満たす製品はJIS X 8341-3 AA適合に構造的に近いものの、日本の規格には、日本語特有のテキスト処理、読み順、音声表記（ふりがな）に関する追加のガイダンスが含まれており、これはWCAGが扱っていない領域です。