診断会社の指摘から学ぶ:Webサイトのアクセシビリティ対応具体例

当社が実際にアクセシビリティの診断会社から指摘を受けて対応したwebサイトの修正ポイントの一部を抜粋してご紹介します。
近年、Webサイトにおけるアクセシビリティ対応の重要性はますます高まっています。誰もがWebサイトにアクセスし、情報を得られるようにすることは、当たり前の時代です。
当社も、実際の案件で外部のアクセシビリティ専門の診断会社による手動診断を受ける機会が増えました。また、その指摘に基づいてデザインやコーディングの調整を行っています。
世の中には、ツールでの自動診断は事例が多く紹介されていますが、「人が手動で診断して指摘した細かいポイント」の具体的な事例はほとんど見かけません。
この記事では、「これから社内でアクセシビリティ対応を進めたいけれど、何から手をつければ良いか分からない」とお考えの方に向けて、当社が実際に指摘を受けて対応した修正ポイントの一部を抜粋してご紹介します。
※アクセシビリティ診断の内容は診断会社や担当者により異なる場合があります。本記事では、当社が実際に受けた指摘事例の一部を紹介し、その対応例をお伝えします。
具体例1:読み上げに適さない単語への対応(アルファベット・数字・単位)
指摘内容
「1/4(よんぶんのいち)」や「kV(キロボルト)」のようにアルファベット、数字、単位などが機械的に不自然に読み上げられてしまい(例:「いちスラッシュよん」と読まれるなど)、利用者に意味が正しく伝わらない可能性がある。
なぜ必要?
スクリーンリーダーが文字通りに読み上げてしまうと、意図した情報が伝わらず、とくに専門的な内容や数値データの場合、誤解が生じる可能性があります。音声で情報を得ているユーザーにとって、自然な言葉で内容を理解できることが重要です。
対応方法
対象のテキストをウェブアクセシビリティのための特別な属性であるaria-label
で適切に「読み上げ用のテキスト」として補足しました。また、必要に応じてaria-hidden
とcss(例:.visually-hidden)を組み合わせ、見た目には表示せず、スクリーンリーダーにだけ読み上げさせるテキストを設定しました。
HTML例
<span aria-hidden="true">1/4</span><span class="visually-hidden">よんぶんのいち</span>
<span aria-hidden="true">kV</span><span class="visually-hidden">キロボルト</span>
CSS例
.visually-hidden {
position: absolute; /* 絶対配置にして通常のドキュメントフローから取り除く */
width: 1px; /* 幅を最小限に */
height: 1px; /* 高さを最小限に */
margin: -1px; /* 他の要素に影響を与えないようにネガティブマージン */
padding: 0; /* パディングをなしに */
overflow: hidden; /* 内容がはみ出しても表示しない */
clip: rect(0, 0, 0, 0); /* 要素の表示領域を0にする (古いブラウザ対応) */
clip-path: inset(50%); /* 要素の表示領域を0にする (新しいブラウザ対応) */
white-space: nowrap; /* テキストの折り返しを防ぐ */
border: 0; /* 境界線をなしに */
}
具体例2:特殊文字(康煕部首)の修正
指摘内容
サイト内に特殊な漢字(康煕部首など)が含まれており、ブラウザやスクリーンリーダーで正しく表示・読み上げされない可能性がある。
なぜ必要?
一部の環境では文字化けして見えなかったり、スクリーンリーダーが意味不明な読み方をしてしまったりすると、情報が正しく伝わらず、ユーザーを混乱させてしまいます。とくに固有名詞や重要な単語の場合、情報伝達の大きな妨げとなります。
対応方法
該当の特殊文字を、一般的に広く使われている表記の漢字に置き換えました。修正後は、すべてのページで、置き換え後の表示とスクリーンリーダーでの読み上げテストを実施し、情報が正確に伝わるように改善されていることを確認しました。
関連する基準
康煕部首(こうきぶしゅ)とは?
Unicode(文字コードの国際規格)において、通常の漢字とは異なるコードポイントに割り当てられている「部首専用の文字」のことです。例えば、漢字の「人」と、部首としての「人偏(にんべん)」(⺅)は、見た目は似ていてもUnicode上では別の文字として扱われます。
古いデータの移行や、PDFからテキストをコピー&ペーストした際に、元のPDFが康煕部首で扱われていたことで、そのまま混入してしまうケースがよくあります。メイリオなどフォントによっては見た目で判断しにくい場合も多いため、変換サイトなどで確認・置換するのが安全です。
💻 参考サイト
- 康煕部首→CJK漢字コンバータ
- テキストを入れると、康煕部首を通常のCJK統合漢字に変換できます(ブラウザ上で動作します)。
- TextSS
- 「康煕部首→通常字形」およびその逆の相互変換が可能な、Windows対応の一括置換ツールです(ダウンロードして使用します)。
具体例3:スライドの自動再生に一時停止ボタンを追加
指摘内容
自動で切り替わるスライド(カルーセル)は、ユーザーが自分のペースで内容を確認できないため、再生を制御できる機能(一時停止など)が必要。
なぜ必要?
スライドの自動再生は、情報を追うのが難しいユーザー(高齢者や、認知に特性のある方、動きに敏感な方など)にとって大きな負担になります。急いで情報が切り替わるため、内容を読み切れなかったり、集中が途切れてしまったりする恐れがあるため、自分のペースで停止したり、再生したりできることが重要です。
対応方法
一時停止/再生ボタンを新たに設置し、キーボード操作(マウスを使わず、Tabキーなどで操作すること)にも対応する形でJavaScriptを調整しました。これにより、利用者が自由にスライドの表示をコントロールできるようになりました。
関連する基準
ここにも注意!
スライドの自動再生を含むカルーセルは、プラグインの種類によっては「ページ送りの矢印」や「インジケーター」がキーボード操作に対応していない場合があります。
アクセシビリティ対応を進める際は、最初から操作性に配慮されたプラグインを選ぶとスムーズです。
💻 推奨プラグイン
- Splide
- キーボード操作やARIA属性対応が充実した、軽量で柔軟なスライダーです。
具体例4:テーブル構造:見出しとセルの関連付け
指摘内容
表組みの中で、見出し(<th>
)とセル(<td>
)の関連付けが不十分で、スクリーンリーダーで正しく情報が伝わらない箇所がある。
なぜ必要?
視覚的に表を見ている人には、どのデータがどの見出しに対応しているか一目で分かります。しかし、スクリーンリーダーで表の情報を取得する人にとっては、見出しとデータが明確に関連付けられていないと、「何のデータなのか」を理解するのが非常に難しくなります。例えば、たくさんの数値が読み上げられても、それが「何の項目」の「誰の」データなのかが分からなくなる、といった混乱を防ぐためです。
対応方法
<th>
要素(見出しセル)の中にscope="col"
(列の見出しを示す)またはscope="row"
(行の見出しを示す)属性を追記し、その見出しが「縦方向」のデータに対する見出しなのか、「横方向」のデータに対する見出しなのかを明確にしました。
複雑なテーブル(入れ子になっている表や、セル結合がある表など)の場合は、デザインから見直し、コーディングを一部作り直すことで、シンプルで分かりやすい構造に改善しました。これにより、スクリーンリーダーのユーザーも、ストレスなく表の内容を理解できるようになりました。
関連する基準
具体例5:リンクに補足テキストを追加
指摘内容
リンクテキストだけでは、リンク先がPDFファイルであることや、新しいタブ・ウィンドウで開くかどうかといった情報が不足しており、スクリーンリーダー利用者が想定外の挙動に遭遇する恐れがある。
なぜ必要?
リンクをクリックした結果、突然PDFファイルが開いたり今見ているページが閉じて新しいタブに切り替わったりすると、ユーザーは混乱し元のページに戻れなくなる可能性があります。とくに視覚に障がいのある方にとっては、予期せぬ挙動は大きなストレスになります。リンクをクリックする前に、その「結果」が予測できることが、安心してWebサイトを利用するために必要です。
対応方法
リンクテキストに「(PDF)」や「(別ウィンドウで開きます)」などの補足テキストを追加し、ファイル形式やリンクをクリックした後の挙動を明確に示しました。これにより、ユーザーはリンクをクリックする前に内容や遷移先を予測できるようになり、安心して操作を進められます。
また、読み上げ用のテキストは「別ウインドウ」「PDFファイル」などではなく「別ウインドウで開きます」「PDFファイルが開きます」など、具体的な文言がいいようです。
NG例
<a href="document.pdf">資料ダウンロード</a>
↓
OK例
<a href="document.pdf">資料ダウンロード<span class="visually-hidden">(PDFファイルが開きます)</span></a>
※上記コード例のように、見た目には表示せずスクリーンリーダーにだけ読み上げさせることも可能です。(.visually-hiddenは具体例3に記載したcssを参照)
まとめ
今回の診断では、ツールだけでは気づきにくい細かな指摘が多く、人の目による手動確認の重要性を改めて実感しました。
本記事でご紹介した内容は、あくまで一例にすぎませんが、これから社内でアクセシビリティ対応を進める方にとって、リアルな修正ポイントの参考になれば幸いです。
アクセシビリティ対応は一度で完了するものではなく、運用の中で継続的に改善していくことが大切です。
今後も私たちは、外部診断の結果を活かしながら、誰もが使いやすいWebサイトを目指して取り組んでいきます。
Webサイトの構築や運用など、なんでもご相談ください!
Share

✏️ Remedia Blog 編集部
株式会社リメディアのコンテンツ編集部です。Web制作やマーケティングなど、Webに関する情報を発信しています。