2024年4月施行の改正障害者差別解消法により、民間事業者にも、障害のある人から求めがあった場合の合理的配慮の提供が義務づけられました。ウェブサイト等の環境の整備は引き続き努力義務ですが、日本市場に参入するSaaS製品にとって、日本語スクリーンリーダーの挙動、JIS X 8341-3への適合、代替テキストの書き方、ARIAラベルのローカライゼーションは、リリース後に後追いで対処するのではなく、設計段階から考えておくべき事項です。
2024年4月より前、日本の障害者差別解消法（Shougaisha Sabetsu Kaishou Hou）は、行政機関等には合理的配慮の提供を義務づける一方、民間事業者には努力義務としていました。2024年4月1日施行の改正により、民間事業者にも合理的配慮の提供が義務化されました。ソフトウェアやオンラインサービスの提供者も対象です。ここでいう合理的配慮は、障害のある人から社会的障壁の除去を求められた場合に、負担が過重でない範囲で対応することを指します。一方、ウェブサイト等のアクセシビリティを事前に整える「環境の整備」（法第5条）は、改正後も努力義務のままです（内閣府「障害者差別解消法」解説ページ）。
SaaS企業にとっての実務上の影響は、個別の事例や行政のガイダンスを通じてなお形成途上です。ただ、ウェブサイトやサービスの環境の整備が進んでいれば、利用者から個別の求めがあったときにも対応しやすくなります。公共部門、金融、医療、教育などの顧客に提案する場合は、JIS X 8341-3の適合状況を説明できるようにしておくと、検討の場で答えに詰まらずに済みます。
ローカライゼーションの面では、日本語のアクセシビリティ対応を、製品のリリース後に足す追加機能として扱うことはもうできません。翻訳と並行して日本語UI層に作り込む必要があります。ARIAラベル、代替テキスト、フォームのエラー読み上げ、フォーカス管理のどれについても、ツールチップを読む晴眼ユーザー向けではなく、スクリーンリーダーで聞く人に向けて日本語を書かなければなりません。
英語製品のアクセシビリティテストは、通常JAWS（Job Access With Speech）を中心に組まれます。英語圏で広く使われているためです。日本向けの製品でこの前提をそのまま使うと、日本のユーザーが実際に使っているスクリーンリーダーでの読み上げを見落とすテスト戦略になりかねません。
日本で広く使われているのが、PC-Talkerと日本語で使えるNVDAです。PC-Talkerは株式会社高知システム開発が開発・販売する日本語のスクリーンリーダーで、漢字の読み（同じ漢字でも複数の読みがありうる）や日本語の句読点を扱えるよう作られています。NVDAはオープンソースで無償のため、アクセシビリティをテストする開発者にも使いやすい選択肢です。日本語対応のApple VoiceOverは、iOS関連のワークフローやmacOSでのテストに関わるツールです。
これらのツールとJAWSの挙動の違いは、ローカライゼーションに直接関わります。PC-Talkerは、組み込み辞書で発音を決めながら漢字を読み上げます。業務の文脈によって同じ文字列でも読みが変わる熟語では、スクリーンリーダーが誤った読みを選ぶことがあります。日本のアクセシビリティのベストプラクティスが、誤読されやすい専門用語にふりがな（ルビ）を付けるよう勧めているのはこのためです。WCAGの達成基準3.1.6 発音（レベルAAA）が扱う実務で、JIS X 8341-3:2016にも同じ基準があります。
| スクリーンリーダー | 市場での位置づけ（日本） | 主要な日本語対応能力 | テストの優先度 |
|---|---|---|---|
| PC-Talker | 日本で広く使われている | 日本語向けに開発。漢字の発音、読み順、日本語の句読点に標準で対応 | 高——日本市場の主要テスト対象 |
| NVDA＋日本語 | 第二・開発者が使用 | オープンソース。日本語の読み上げに対応し、無償で使える | 高——アクセシビリティQAのオープンソース基準 |
| VoiceOver（日本語） | Appleエコシステム | 日本語対応が強力。iOSのウェブアプリやmacOS向けSaaSに関係 | 中——モバイルやmacOSの利用者がいる製品では必須 |
| JAWS | 英語圏で広く使われる | 英語圏のテストで基準にされることが多い | 補助——日本語の読み上げ確認はPC-TalkerやNVDAと併用する |
日本語の代替テキストは、英語の代替テキストを日本語に訳したものではありません。書き方の慣行がかなり違うため、翻訳作業として扱うと、長すぎて聞き疲れする、漢字の読みが曖昧で誤読される、説明の順序が内容と合わない、のいずれかの問題を抱えた代替テキストができあがります。
長さ：日本語は漢字を使うため、英語の文章より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部：ウェブコンテンツ）の現行版JIS X 8341-3:2016は、国際規格ISO/IEC 40500:2012の一致規格で、規格本文はWCAG 2.0と同じ内容です（WAIC＝ウェブアクセシビリティ基盤委員会の解説による）。適合レベルもA・AA・AAAの3段階で共通しています。そのため、カラーコントラスト比、キーボード操作、時間依存メディアの字幕といった達成基準は、WCAG 2.0と同じものとして確認できます。WCAG 2.1以降で追加された達成基準はJIS X 8341-3:2016には含まれていません。
規格本文がWCAG 2.0と同じである以上、日本語だけに課される追加の要件があるわけではありません。日本語SaaSのローカライゼーションで差が出るのは、同じ達成基準を日本語の文字と読み上げに当てはめる段階です。たとえば漢字の読みの示し方は、WCAGの達成基準3.1.6 発音（レベルAAA）で扱われており、W3Cの実装方法H62はruby要素で読みを示す方法を挙げています（具体的な手順は後述の「日本語の読み上げ点検」で扱います）。
カラーコントラストの要件はWCAG 2.0と同一です（WCAG 2.1でも変わっていません）。レベルAAで、通常のテキストは4.5:1、大きなテキスト（18pt、または14ptの太字）は3:1。日本語で実装するときに注意したいのは、日本語の本文では同じフォントサイズの中に漢字・かな・ラテン文字が混在することが多く、実際にレンダリングされた太さでこの比率を満たす必要がある点です。日本語フォントとラテン文字のフォールバックフォントは太さが違って見えることがあり、デザイン仕様どおりにならない場合があるからです。
ARIAラベルのローカライゼーション、代替テキストでの漢字の扱い、フォームのエラー読み上げ、JIS X 8341-3への適合は、どれも英語のアクセシビリティ監査に通った製品が日本語の監査で引っかかる領域です。ミニ診断は、日本語のアクセシビリティ層に絞って点検します。技術的な適合チェックツールでは拾えない、コンテンツ面の判断です。
ミニ診断を依頼する日本語ページの読み上げ品質は、訳文が正しいかどうかとは別の問題です。支援技術に「この部分は何語か」「この漢字をどう読むか」「どこまでが1語か」を伝えられているかで決まります。WCAG 2.2では、この3点がそれぞれ別の達成基準に対応しています。
| 達成基準（レベル） | 要件の要旨 | 日本語版での実装 |
|---|---|---|
| 3.1.1 ページの言語（A） | 各ページの既定の言語をプログラムで判定できる | <html lang="ja">。英語版のテンプレートを複製して作ったページで lang="en" が残っていないかを確認する |
| 3.1.2 一部分の言語（AA） | 文章や語句ごとの言語を判定できる。ただし固有名詞、技術用語、言語が特定できない語、周囲の文章に定着した語は除く | 英語のまま残した一文や引用には <span lang="en"> を付ける。製品名や「API」のような技術用語は例外に当たるため、1語ずつ囲む必要はない |
| 3.1.6 発音（AAA） | 文脈の中で発音が分からないと意味が曖昧になる語について、発音を特定する仕組みがある | <ruby> で読みを示す。W3Cの解説書は、日本語のルビは「発音」より「読み」を示すものだと注記している |
W3Cの実装方法H62（ruby要素の使用）は、3.1.6を満たす方法として、各親文字に対応する読みが rt 要素に入っていること、簡易ルビでは rp 要素で括弧を補い、ルビ非対応の環境でも読みだと分かるようにすることを検証手順に挙げています。たとえば「重複」は「ちょうふく」とも「じゅうふく」とも読まれる語です。
<ruby>重複<rp>（</rp><rt>ちょうふく</rt><rp>）</rp></ruby>
見た目の組み方は、W3Cの「日本語組版処理の要件（JLREQ）」3.3節が整理しています。1字の親文字に付けるモノルビ、複数字にまとめて付けるグループルビ、熟語を構成する字に振り分ける熟語ルビの3種があり、ルビ文字は親文字のおおむね半分の大きさで組むのが一般的とされています。UIのラベルやボタンに多用すると行の高さが揃わなくなるため、ルビは本文や説明文の難読語に絞り、ボタンの文言は読み違えにくい語に言い換えるほうが実務的です。
見出しや表の見出しセルで「東 京」のように全角スペースを入れて字間を広げる書き方は、日本語サイトでよく見られます。W3Cは、単語の中の空白文字で間隔を調整することを達成基準1.3.2（意味のある順序）の不適合事例F32として挙げ、「東 京」が1語として認識されず、別の語として読まれてしまう例を示しています。縦書き風に1字ずつ改行した表の見出しも、同じ事例の中で不適合とされています。字間は letter-spacing などCSSで調整します。
html 要素が lang="ja" になっているか。英語の一文・引用に lang="en" が付いているか（3.1.1／3.1.2）。出典：W3C「Web Content Accessibility Guidelines (WCAG) 2.2」達成基準3.1.1・3.1.2・3.1.6の解説書（Understanding SC 3.1.2、Understanding SC 3.1.6）、実装方法H62、不適合事例F32、W3C「日本語組版処理の要件」（2020年8月11日版）3.3節。
2024年の日本のアクセシビリティ法改正で、SaaS企業にとって何が変わりましたか？
2024年4月1日施行の改正障害者差別解消法により、事業者による合理的配慮の提供が、努力義務から法的義務に変わりました。対象はソフトウェアやオンラインサービスの提供者を含む民間事業者全般です。ここでいう合理的配慮は、障害のある人から社会的障壁の除去を求められた場合に、負担が過重でない範囲で個別に対応することを指します。一方、ウェブサイト等のアクセシビリティを事前に整える環境の整備（法第5条）は、改正後も努力義務のままです。とはいえ、環境の整備が進んでいれば個別の求めにも応じやすくなるため、日本市場向けSaaSでも計画的に取り組む価値があります。
SaaS製品はどの日本語スクリーンリーダーに対応する必要がありますか？
日本で広く使われている日本語スクリーンリーダーには、株式会社高知システム開発のPC-Talkerと、日本語で使えるオープンソースのNVDAがあります。PC-Talkerは日本語の読み上げを前提に作られた製品で、漢字の読みや日本語の句読点を扱えるよう設計されています。NVDAは無償で入手でき、開発者のテスト環境としても使いやすい選択肢です。英語圏で広く使われるJAWSでの確認だけでは、日本語テキストの実際の読み上げを見落とすおそれがあるため、日本の利用者が使うツールでも確認することをおすすめします。iOSやmacOSでは、日本語のApple VoiceOverも確認対象になります。
日本語の代替テキストは英語の代替テキストとどう書き分けるべきですか？
日本語の代替テキストは、英語との構造的な違いをいくつか踏まえて書く必要があります。まず読み順です。スクリーンリーダーは既定で横書きを左から右へ読むので、代替テキストもその順で画像を説明します。次に長さです。漢字は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部：ウェブコンテンツ」です。現行のJIS X 8341-3:2016は国際規格ISO/IEC 40500:2012の一致規格で、規格本文はWCAG 2.0と同じ内容です。適合レベルもA・AA・AAAの3段階で共通しています。そのため、日本語だけに課される追加の要件があるわけではありません。差が出るのは、同じ達成基準を日本語の文字と読み上げに当てはめる段階です。たとえば漢字の読みの示し方は、WCAGの達成基準3.1.6 発音（レベルAAA）で扱われています。
2024年4月の法改正で、民間事業者にも合理的配慮の提供が義務化されました。ARIAラベル、代替テキストの書き方、フォームのエラーの出し方、JIS X 8341-3への適合は、どれも技術的には正しく作られた製品が日本語のアクセシビリティQAでつまずく領域です。ローカライズはしていても、アクセシビリティまではローカライズしていなかったからです。