多言語サイトのアクセシビリティ実装ガイド｜言語切替、lang、RTL、フォーム設計

多言語サイトのアクセシビリティは、文言を翻訳するだけでは整いません。

ページの言語を機械にも伝え、文字の方向、氏名や住所の入力方法、画像や動画の代替情報、検索結果の並びまで、利用者の言語と文化に合わせて設計する必要があります。

この記事では、企画、デザイン、実装、翻訳、品質保証の担当者が同じ基準で確認できるように、優先順位と具体例を整理します。

多言語対応とアクセシビリティの関係

国際化（i18n）は、言語や地域が変わってもシステムを作り直さずに対応できる土台を設計することです。

ローカライゼーション（l10n）は、その土台を使い、文言、日付、数値、通貨、氏名や住所の扱いを特定の言語や地域に合わせる作業です。

Webアクセシビリティは、障害の有無や利用環境にかかわらず、より多くの人がWebの情報と機能を利用できる状態を目指す考え方です。

三つを別々に進めると、翻訳は読めても言語切替をキーボードで操作できない、正しい住所を入力してもエラーになる、といった障壁が残ります。

最初に押さえる六つの原則

• 言語切替は全ページの同じ位置に置き、現在の言語を明示する。
• ページ全体と部分的な言語の違いをlang属性で示す。
• 右から左へ読む文字体系ではdir属性と双方向テキストを設計する。
• 氏名、住所、日付、数値を一つの国の形式に固定しない。
• 画像の代替テキスト、字幕、エラー文も言語ごとに用意する。
• 自動検査だけで終えず、言語別の表示と支援技術による操作を確認する。

本稿はWeb Content Accessibility Guidelines（WCAG）2.2のレベルAAを実務上の参照点とします。

ただし、個々の例を採用するだけでサイト全体の適合を表明できるわけではありません。

対象範囲を定めて達成基準を一つずつ評価する必要があります。変更点を先に把握したい場合は、greeden blogのWCAG 2.2の追加達成基準を実務で読む解説も参照してください。

言語切替で迷わせない

言語切替は、利用者が内容を理解する前に通る入口です。

ヘッダーなど全ページで見つけやすい同じ位置に置き、国旗だけで表さず、「日本語」「English」「Français」のように各言語の名称を文字で示します。

国と使用言語は一対一ではないため、国旗だけでは選択肢の意味が決まりません。

同じ内容の別言語ページへつなぐ

切替先は、可能な限り現在表示しているページと同じ内容の翻訳版にします。

翻訳版がない場合は、無関係なページへ黙って移動させず、未翻訳であることと移動先を伝えます。

現在のページにはaria-current='page'を付け、見た目でも現在の言語が分かるようにします。

<nav aria-label="言語を選択">
  <ul>
    <li><a href="/ja/guide/" lang="ja" hreflang="ja" aria-current="page">日本語</a></li>
    <li><a href="/en/guide/" lang="en" hreflang="en">English</a></li>
    <li><a href="/fr/guide/" lang="fr" hreflang="fr">Français</a></li>
  </ul>
</nav>

この例では移動先がリンクなので、標準のリンクをそのまま使います。

リンクをrole='option'の中に置く独自リストボックスは避けます。W3CのListbox Patternでは、選択肢の中にリンクなどの操作要素を置く構造を支援技術が扱えないと説明しています。

リンクはTabキーで移動してEnterキーで開き、ボタンはEnterキーまたはSpaceキーで操作するという標準の挙動を保ちます。

フレームワークでのURL、翻訳ファイル、日付や通貨まで含めた実装は、Laravelの多言語化（i18n）実装ガイドで詳しく確認できます。

langとdirを分けて考える

langは文章の言語、dirは文字が進む基本方向を示します。

言語と文字方向は同じ情報ではありません。ページの言語だけから方向を推測せず、HTMLにそれぞれ指定します。

ページ全体と部分的な言語を指定する

ページの主要言語はhtml要素に指定します。

文中で別の言語に切り替わる箇所は、その範囲を囲む要素にlangを付けます。

<html lang="ja" dir="ltr">
<p>フランス語では<span lang="fr">accessibilité</span>と表記します。</p>

この指定により、ブラウザーや支援技術は言語に応じた処理を選びやすくなります。

ページの言語はWCAG 2.2の達成基準3.1.1（レベルA）、部分的な言語は達成基準3.1.2（レベルAA）に対応します。

ただし、固有名詞、技術用語、日本語に定着した外来語まで機械的に別言語として指定する必要はありません。

音声合成の発音は製品や設定でも変わるため、langを付けた後に実際のスクリーンリーダーで確認します。言語タグの選び方はW3CのHTMLで言語を宣言する方法が参考になります。

右から左へ読む文章と混在テキスト

アラビア語やヘブライ語などのページでは、文章を右揃えにするCSSだけでは文字方向を伝えられません。

ページ全体または対象の段落にdir='rtl'を指定します。

利用者名や注文番号のように方向を予測できない文字列は、bdiで周囲から分離すると、句読点や数字の位置が崩れにくくなります。

<p lang="ar" dir="rtl">رقم الطلب: <bdi dir="auto">GRE-1042</bdi></p>

方向が違う文字を混在させる方法は、W3CのHTMLで右から左へ読む文章を扱う解説で確認できます。

住所で選んだ国を根拠にページ全体の方向を変える実装は避けます。文字方向は、表示している言語と文字体系に合わせて決めます。

レイアウトは左右ではなく論理方向で指定する

余白や配置には、leftとrightへ直接依存しないCSS論理プロパティを使うと、LTRとRTLで同じコンポーネントを保守しやすくなります。

.nav-item {
  margin-inline-end: 1rem;
  padding-inline: 0.75rem;
}

見た目の反転だけで完了とせず、読み順、Tab移動順、パンくず、方向を示す矢印、横スクロールも確認します。

画像、動画、読みの補助を翻訳する

代替テキストは画像の役割から書く

画像の代替テキストは、元の文を逐語訳するのではなく、そのページで画像が担う役割を同じ言語で伝えます。

• 装飾画像は空のalt属性にし、読み上げの対象から外す。
• リンクやボタンの画像は、見た目ではなく移動先や操作の目的を伝える。
• グラフは結論を短く代替テキストに置き、必要な数値や傾向を近くの本文や表で説明する。
• 画像内の文字も翻訳対象に含め、翻訳できない場合は本文で情報を補う。

字幕と音声解説を言語別に管理する

動画では、発話だけでなく話者や意味のある効果音を含む字幕を言語ごとに用意します。

映像だけで伝わる操作や場面が理解に必要なら、音声解説または同等の説明を提供します。

<video controls>
  <source src="guide.mp4" type="video/mp4">
  <track kind="captions" srclang="ja" src="captions.ja.vtt" label="日本語" default>
  <track kind="captions" srclang="en" src="captions.en.vtt" label="English">
</video>

字幕切替はマウスだけでなくキーボードでも操作し、選択中の言語が視覚と読み上げの両方で分かるかを確認します。

ルビと略語は見える説明を優先する

日本語や中国語の読みを補う場合は、必要な人名、地名、専門用語にrubyとrtを使えます。

<ruby>山科<rt>やましな</rt></ruby>駅

ルビを広い範囲へ一律に付けると、表示も読み上げも冗長になることがあるため、W3CのRuby Markupの解説を参照し、対象と実装を端末で確認します。

略語は最初の出現時に「Web Content Accessibility Guidelines（WCAG）」のように本文で正式名を示します。

abbr要素のtitle属性だけに説明を預ける方法は、キーボードやタッチ操作で情報を得られない場合があるため、見える説明の代わりにはしません。

氏名、住所、日付を文化差に合わせる

多言語フォームでは、利用者の書き方を誤入力として拒まない設計が必要です。

ラベル、説明、入力例、エラー、確認画面、通知メールまでを同じロケールで確認します。

氏名を「姓と名」に固定しない

人名の構成、順序、呼び方は地域や個人によって異なります。

業務上分割する必要がなければ、氏名を一つの欄で受け取る方法が扱いやすい場合があります。

分割が必要なら「名」「姓」ではなく、対象言語で意味が明確なラベルを使い、ミドルネームや一語の氏名を一律に拒まない検証規則を検討します。

並べ替えや呼びかけに別の情報が必要なら、氏名を推測で分解せず、用途を説明した別項目として尋ねます。背景と例はW3Cの世界の人名とフォーム設計にまとめられています。

<label for="full-name">氏名（公的書類の表記どおり）</label>
<input id="full-name" name="fullName" autocomplete="name">

住所は国ごとの構造と文字を受け入れる

都道府県、州、郵便番号の有無や並びは国によって異なります。

国の選択に応じてラベルと順序を変えつつ、建物名や地域固有の要素を入力できる余地を残します。

郵便番号を数字だけに限定すると文字を含む形式を受け付けられないため、対象国の仕様が決まっていない欄へinputmode='numeric'を一律に付けません。

入力目的と直し方をコードでも伝える

利用者本人の氏名、住所、電話番号、メールアドレスなどを集める欄には、用途に合うautocomplete値を設定します。

この値は表示言語に依存せず入力目的を示し、自動入力によって手入力の負担を減らせます。詳しい要件はWCAG 2.2の入力目的の特定で確認できます。

<label for="email">メールアドレス</label>
<input id="email" name="email" type="email" autocomplete="email" inputmode="email" aria-describedby="email-hint">
<p id="email-hint">例：name@example.com</p>

入力エラーは「どの項目で」「何が合わず」「どう直せるか」を同じ場所で具体的に伝えます。

実装とテストの詳細は、フォームのアクセシビリティ実装ガイドも参考になります。

日付、時刻、数値、通貨の表示と保存を分ける

日付を2026-09-05と書くか、2026年9月5日と書くかは、言語と地域によって変わります。

保存用の値を一定の形式にそろえても、画面では利用者のロケールに合う表示へ変換します。

input type='date'の見た目はブラウザーや環境で異なるため、画面上の表示が常にISO形式になるとは限りません。

自由入力を併用する場合は、欄の近くに期待する形式と例を表示し、エラー時にも同じ書き方を案内します。

金額は通貨コードまたは通貨名を明示し、桁区切りと小数点の違いを考慮します。

入力時の表記ゆれを受け入れて内部で正規化する場合も、元の入力を勝手に別の金額へ解釈しないよう確認画面で示します。

検索、並べ替え、文字表示をロケールで検証する

検索用の正規化と原文の保存を分ける

全角と半角、ひらがなとカタカナ、アクセント記号の扱いをそろえると、表記が少し違う検索語でも候補を見つけやすくなります。

ただし、違いに意味がある文字まで同一視すると誤った結果を返します。

検索用の索引だけを目的に合わせて正規化し、利用者が入力した氏名や本文の原文は保持します。

並べ替えは単純な文字コード順にしない

一覧の並びは、言語ごとの照合規則を使います。

JavaScriptではIntl.Collatorを利用できますが、読み仮名がなければ日本語の人名を期待どおりの読み順に並べられない場合があります。

const collator = new Intl.Collator('ja', {
  sensitivity: 'base',
  numeric: true
});
items.sort((a, b) => collator.compare(a.label, b.label));

検索語の強調は色だけに頼らず、前後の文脈や選択状態をテキストでも分かるようにします。

翻訳後の長さとフォントを実画面で見る

翻訳すると、ボタン、見出し、表のセル、エラーメッセージの長さが変わります。

固定幅や一行固定を前提にせず、拡大、折り返し、縦書き、RTL、長い単語、複合文字を含む表示を確認します。

Webフォントを絞り込む場合は、必要な文字が欠けたときの代替フォントを設定し、太字、ルビ、記号を含む画面で文字化けやレイアウトのずれがないかを確認します。

翻訳の欠落を利用不能につなげない

翻訳キーが見つからないときに[MISSING_KEY]のような内部情報を表示すると、操作の意味が分からなくなります。

表示する代替言語、利用者への知らせ方、翻訳担当へ通知する方法を先に決めます。

• 購入、予約、送信など主要な操作は、翻訳がそろうまで公開を止める。
• 補助的な説明で代替言語を表示する場合は、言語が変わったことを明示する。
• 文を単語の断片で連結せず、文全体を翻訳単位にする。
• 同じ操作に「保存」と「保存する」を混在させず、用語集で統一する。
• 代替テキスト、字幕、確認メール、エラー文も翻訳状況の管理対象に含める。

設計から運用までの確認手順

多言語アクセシビリティは、公開直前のチェックだけでは抜けが生じます。

企画時に対象言語と利用場面を決め、コンポーネント仕様、翻訳、実装、品質保証へ同じ要件を渡します。

短時間で行う手動チェック

1. Tabキーだけで言語切替へ移動し、現在の言語を確認する。
2. 別言語へ切り替え、同じ内容のページに移動するかを確認する。
3. ページと部分的な別言語に正しいlangが付いているかを見る。
4. RTL表示で読み順、Tab移動順、矢印、数字と句読点を確認する。
5. 氏名、住所、日付、通貨へ対象地域の実例を入力する。
6. 誤入力を行い、エラーの場所、原因、直し方が分かるかを見る。
7. 字幕、代替テキスト、確認メールまで選択した言語になっているかを確認する。
8. 200％以上の拡大と狭い画面で、文字や操作部品が欠けないかを見る。

この確認は初期不具合を見つけるための短い手順です。

公開判定では、自動検査に加えて、対象言語の話者、キーボード、複数のスクリーンリーダーとブラウザーの組み合わせで主要タスクを試します。

公開前チェックリスト

• WordPressのタイトルをH1とし、本文はH2から始まっている。
• 言語名が文字で表示され、国旗だけに依存していない。
• 現在の言語と、切替先の言語がコードと見た目の両方で分かる。
• ページ全体と別言語部分のlangが正しい。
• RTLの文章と混在文字列に適切なdirまたはbdiがある。
• 画像、字幕、音声解説がページの言語に対応している。
• 氏名、住所、日付、通貨を特定の国の形式だけに固定していない。
• 検索と並べ替えを対象言語の実データで確認した。
• 未翻訳時の表示と公開判断が決まっている。
• キーボード、拡大表示、読み上げで主要な操作を完了できる。

多言語サイトでは、翻訳、画面設計、HTML、入力規則、運用を一つの利用体験として扱う必要があります。

まず言語切替、lang、主要フォームの三点を実際のページで確認し、見つかった障壁をコンポーネントと運用ルールへ戻してください。