多言語サイトでのアクセシビリティ対応、どこまで必要？
2025年12月 5日
多言語サイトを作る際、「アクセシビリティ対応は日本語版だけでいいのか？」「翻訳ページにも同じレベルの対応が必要なのか？」という質問をよく受けます。
結論として、多言語サイトのアクセシビリティは「すべての言語に完全対応する」必要はありません。しかし、最低限守るべきポイントがあり、ここを外すとユーザー体験が大きく損なわれます。
この記事では、RARE TEKTの上野が多言語サイトの改善支援で蓄積してきた“実務的に失敗しないライン”を整理します。
1. 多言語サイトでも「構造」のアクセシビリティは全言語で必要
アクセシビリティには大きく分けて2種類あります。
- 構造的アクセシビリティ（HTML構造、見出し階層、読み上げ順、ariaなど）
- 内容的アクセシビリティ（文章の明瞭さ、翻訳品質など）
多言語対応で必須なのは、構造的アクセシビリティを全言語で統一することです。
理由は明確で：
- HTML構造はどの言語でも共通だから
- スクリーンリーダーは言語に関係なくDOMを読むから
- ボタンやフォームなどの操作は言語に依存しないから
逆に言えば、日本語版だけ構造を整えても意味がありません。
各国でアクセシビリティが求められる背景（主要な法規と指針）
アクセシビリティが「義務」あるいは「事実上の必須要件」とされる背景には、各国で制定されている法律・ガイドラインの存在があります。国ごとに呼称は異なりますが、基本的にはWCAG（Web Content Accessibility Guidelines）を基準とする点は共通しています。
アメリカ：Section 508（リハビリテーション法508条）
米国連邦政府機関に向けて、Webサイト・ソフトウェア・電子文書などをアクセシブルにすることを義務付けた法律です。2017年の改訂以降、WCAG 2.0 AAが準拠基準となり、民間企業の調達要件にも影響しています。
EU：EN 301 549（ICTアクセシビリティ要件）
EU加盟国が公共調達するIT製品・サービスに適用する統一基準で、WCAG 2.1 AAに準拠しています。Webだけでなく、ソフトウェア・モバイルアプリ・ハードウェアまで対象範囲が広い点が特徴です。
カナダ：Accessible Canada Act（ACA）
2019年に施行され、公共機関および一部の大規模事業者にアクセシビリティ改善計画の公開を義務付けています。WebアクセシビリティにおいてはWCAG 2.1を参照することが推奨されています。
イギリス：Equality Act（平等法）
障害を理由とする差別を禁止し、Webサービスにも「合理的配慮」を求めています。公的機関はWCAG 2.1 AA準拠が義務です。
オーストラリア：Disability Discrimination Act（DDA）
障害を理由とする差別を禁止する法律で、Webにも適用されます。過去の裁判判例により、WCAG準拠は“実質的な義務”と捉えられています。
日本：障害者差別解消法 / JIS X 8341-3
行政機関にアクセシビリティ対応を義務付け、民間企業にも「合理的配慮」を求めています。Webアクセシビリティの国内基準はJIS X 8341-3（WCAGとほぼ同等）です。
これらの法規を見てもわかる通り、世界的に「アクセシビリティ＝遵守すべき基準」という流れは加速しています。そのため、グローバル展開企業やBtoB企業では、アクセシビリティの取り組み自体が“取引条件”になるケースも増えています。
2. 内容（テキスト）のアクセシビリティは“優先国のみ”で良い
文章の読みやすさ・表現の分かりやすさは、言語ごとに大きく異なります。
このため、全言語で最高品質を目指すのは現実的ではありません。
実務的には以下の優先順位で十分です。
- 主要ターゲット国（1〜2言語）を重点対応
- その他言語は構造のアクセシビリティを担保
- 翻訳の品質だけ最低限確認（機械翻訳の破綻チェック）
検索流入・CV・事業規模に応じて、文章改善に投資すればOKです。
3. 多言語サイトで絶対にやってはいけないアクセシビリティのミス
多言語サイトでは、特有の落とし穴があります。
① lang属性を指定しない
例：
<html lang="ja">
これはスクリーンリーダーが言語を誤判定する最大の原因です。
よくあるミス：
- 日本語ページなのに lang="en" のまま
- 多言語切替後も lang が変わらない
- ページ単位ではなくサイト全体が1つのlangで固定されている
読み上げが破綻し、ユーザーは即離脱します。
② 自動翻訳ツールのUIが操作しづらい
Google翻訳ウィジェットなどを実装した際によくあるのが、
- フォーカスが当たらない
- 操作ができない
- キーボードで選択できない
といった状態です。
自動翻訳の導入はOKですが、アクセシブルであるかは必ずチェックが必要です。
③ 画像のaltが全言語で未翻訳
alt属性は読み上げユーザーにとって“文章そのもの”です。
英文ページなのに alt が日本語のまま → 読めない
これはよくある失敗で、必ず翻訳対象に含める必要があります。
④ 多言語切替UIが分かりづらい
「国旗アイコンだけ」のUIは非常に誤解を生みやすいです。
- 国旗＝言語とは限らない（国と地域が異なる）
- 視覚的な識別が難しいユーザーが一定数いる
最も正確でアクセシブルなのは、次の形式です。
「Japanese」 / 「English」 / 「繁體中文」
4. 実務で多言語アクセシビリティを最適化するための指針
RARE TEKTの支援では、多言語アクセシビリティは次の3ステップで設計します。
ステップ1：構造のアクセシビリティを全言語で統一
- 見出し階層（h1〜h3）
- aria-label / aria-labelledby
- フォームのlabel構造
- 読み上げ順（DOM順）
- コントラスト比
これだけで8割は対応できます。
ステップ2：主要ターゲット言語だけ文章のアクセシビリティを改善
- 結論 → 理由 → 補足 の構造化
- 難易度の高い専門用語を控える
- 1文を短くする
全世界の言語にこれを行う必要はありません。
ステップ3：各言語のUXを「別プロダクト」として評価する
多言語サイトは、国によって検索行動・文化・習慣が全く異なります。
- EU圏は厳密なアクセシビリティ基準がある
- アジア圏はスマホ操作性の影響が大きい
- 中華圏は言語量が多いので行間の調整が重要
“翻訳ページ”ではなく“別UX”として扱うことが成功の鍵です。
5. 明日からできる実務アクション
- 全言語ページに正しい lang属性 を設定する
- 構造的アクセシビリティ（hタグ・aria・読み上げ順）を統一する
- 自動翻訳ウィジェットの操作性をチェックする
- alt属性を各言語で翻訳する
- 主要ターゲット国だけ文章改善を行う
多言語アクセシビリティは「全言語で完璧にする」必要はありません。最も大切なのは、構造的アクセシビリティを全体で統一し、主要言語のUXを重点改善することです。