この記事は最終更新日から1年以上経過しています。
【導入手順③】ウェブアクセシビリティ方針の基づいたウェブコンテンツ制作
公開日:
更新日:
こんにちは!kanappleです。
ウェブアクセシビリティ導入の手順、前回の続きになります。
1. ウェブアクセシビリティ方針を決める
・目標する適合レベルを決める
・達成期限、担当部署を決める
2.ウェブアクセシビリティ方針を公開する
3.ウェブアクセシビリティ方針に基づいたウェブコンテンツ制作
・既存のサイトに導入する場合は現状を調査し対応していく
4.ウェブアクセシビリティの試験を行う
5.ウェブアクセシビリティ試験結果を公開する
今回の記事は「3.ウェブアクセシビリティ方針に基づいたウェブコンテンツ制作」です。
3.ウェブアクセシビリティ方針に基づいたウェブコンテンツ制作
既存のサイトにウェブアクセシビリティを導入する場合は現状の調査から行います。
最終的に目指すのはAAに準拠ですが、重要度の高い項目から改善していきましょう。
ウェブアクセシビリティには必ず達成しなければならない達成基準があります。
実現できていない場合、利用者がサイト内を移動できなかったり、コンテンツを理解することが難しくなることもあり、利用者を発作の危険性にさらしてしまう可能性もあります。
達成しないと利用者に重大な悪影響を及ぼすもの
達成しないと利用者に重大な悪影響を及ぼすものとして、非干渉という達成基準があります。
アクセシビリティに対応しているコンテンツと対応していないコンテンツが混在している場合、アクセシビリティに対応していないコンテンツの影響により対応しているコンテンツが利用できなくなる可能性があります。
これを干渉といい、それが発生していない状態が非干渉になります。
非干渉の達成基準は4つあります。
1.自動再生はさせない(達成基準:1.4.2|音声の制御)
音声を自動再生することや強制的に再生させることは避けましょう。
もし自動再生をする場合は3秒以内に収め、それより長く続く場合は利用者が止められるようにします。
改善方法:一時停止またはミュートボタンをつける
2.袋小路に陥らせない(達成基準:2.1.2|キーボードトラップなし)
キーボード操作だけで利用している際、一度フォーカスしたら抜け出せないコンテンツを作らないようにしましょう。
モーダルダイアログのようなフォーカスを制御するコンテンツで発生しやすいです。
改善方法:ダイアログ内にフォーカス可能な閉じるボタンを置き、キーボードで閉じられるようにする。
3.光の点滅は危険(達成基準:2.3.1|3回の閃光、又は閾値以下)
光の点滅を繰り返すと、光感受性発作等を誘発しやすくなります。
1秒に3回を超える点滅するコンテンツを作ってはいけません。
改善方法:アニメーションや映像などのコンテンツで、1秒に3回を超える点滅をさせない
4.自動でコンテンツを切り替えない(達成基準:2.2.2|一時停止、停止、非表示)
スライドショーや自動で切り替わるコンテンツなどがある場合は、一時停止、非表示、停止の機能を設置する必要があります。
画面上に動き続けるコンテンツがあると、他の箇所の操作や閲覧を妨げられる利用者がいるためです。
改善方法:自動で切り替わるカルーセルだが、一時停止できる
非干渉のこれらは全て達成基準Aにあたります。
必ず達成しなければならないもの
非干渉ほどではありませんが、満たしてないとコンテンツが十分に理解できない、あるいは操作が不完全にしかできない達成基準です。これらの達成基準は優先して対応します。
画像が指し示している情報を代替テキストとして付与する
画像には適切なaltを付けます。画像の代わりにその文字を置いてみても違和感がない内容にしましょう。
文字数に制限はありませんが、スクリーンリーダーの可読性を考慮して80字を目安にします。
・画像がリンクの場合はリンク先を示す内容にする
・グラフや図表はその要約を記述するが、隣接するテキストに何のグラフ・図表なのかが示されていればalt=""で良い
・文字やロゴマークの場合は、その画像と同じ文字を記述する
・装飾や意味の持たない画像はalt=""にする
・図に大量の文字が含まれている場合は、本文に書き起こすなど図自体を変更できないか検討する
キーボード操作だけですべての機能にアクセスができるようにする
・tabでフォーカスを移動できるようにする
・キーボード操作時にフォーカスインジケーター(選択中の要素を枠線等で囲うこと)が表示されるようにする
・キーボード操作時に、フォーカス・入力がキャンセルされたり、フォーカス・入力した瞬間に何かが勝手に動作することがないようにする
操作に制限時間を設けてはいけない
閲覧や入力の操作に制限時間を設けてはいけません。必要がある場合はいずれかの回避策をとりましょう。
・制限時間があること、それを延長・解除できることを利用者に事前通知する
・入力フォームのセッション時間を、利用者が延長か無制限にできる
・自動的に進むコンテンツを利用者が一時停止できる
赤字・太字・下線・拡大など単一の表現のみで情報を伝えてはいけない
・赤字など色の違いだけで情報を伝えない
・太字、「右の写真」「丸いボタン」など、位置や形の違いだけで情報を伝えない
スクリーンリーダーで順に読み上げたとき、意味が通じる順序になっている
スクリーンリーダーはHTMLソースに記載されている順に読み上げます。
視覚的には左上から右下に向かって読み上げるので、この順序を考慮して設計しましょう。
・文字間の余白調整に空白文字を使わない(1文字ずつと認識されて正常に読み上げられない)
・送信ボタンの後に同意事項など必要な説明を置かない
見出し要素だけでセッションやブロックに含まれる要素を表現する
・大見出し、中見出し、小見出し…となるように見出しレベルを適切に設定する
・見出し要素を空にしない
・強調や文字を大きくする為に見出し要素を使わない
・長い文章の途中には見出しを入れる
確認方法:
・NDVA(windows用のスクリーンリーダー)でF7キーを押して見出しリストを表示して、ページ中の見出しが過不足なく表示されていることを確認する
・Chromeの拡張機能「HTML5Outliner」を使ってHTMLのアウトラインを確認する
文字と背景の間に十分なコントラスト比を保つ
・文字色と背景の間に4.5:1以上のコントラスト比があるようにする(チェックツールを使い確認する)
・4.5:1以上のコントラスト比は、太字でないテキスト22ポイント(29px)未満、太字のテキストは18ポイント(24px)未満の場合の値
・大きいテキストでは3:1以上のコントラスト比である必要がある
テキストの拡大をしても情報が読み取れる
ブラウザの文字拡大機能だけで文字サイズを200%まで変更できるようにする
・文字サイズを固定にしない
・コンテンツを200%まで拡大したときに、文字が重なったり見切れたりすることがないようにする
文字や文字コード、フォントに関する注意
・文字コードはUTF-8うを使う
・webフォントでアイコン等を使っている場合、利用者がフォントの設定を変更をすると異なる文字で表示されるのでで注意して使う
・PDFから文字をコピーすると、見た目が似ている別の文字に置き換えられてしまう場合があるの為、スクリーンリーダーで読み上げ確認をする
・「*」「※」などの記号はスクリーンリーダーとその設定によっては読み上げられない為、確認して使う
・必須項目の印に記号を使っている場合は「必須」などと読み上げられる文字に変更することも検討する
ページ内容を示すタイトルを適切に表現する
・[ページのタイトル|サイト名]とすると判別しやすい
・複数のページでタイトルが重複しないようにする
・ページタイトルとそのページの大見出しを揃える
リンクを適切に表現する
・どこへのリンクか単体でわかるようにする。または前後の文脈から簡単に理解できるようにする
・リンク先がPDFなのか外部ウィンドウで開くのか事前に理解できるようにする
ナビゲーションに一貫性をもたせる
・ナビゲーション要素は、毎回同じ順序、表記で実装する
同じ機能には同じラベルや説明をつける
・同じ機能を複数のページで使う場合は、同じラベルや同じ説明をつける
・ボタンなどのコンポーネント、アイコン、リンクなどに一貫性を持たせる
その他にも、「状況に応じて確認すべきこと」や「導入に慎重な検討が必要なもの」など多数の基準があります。
達成基準については、JIS X 8341-3:2016 附属書JA.2「設計」、同 JA.3「制作・開発」を参照しますが、その際ウェブアクセシビリティ基盤委員会が日本語訳している「ウェブ・コンテンツ・アクセシビリティ・ガイドライン(WCAG)2.0」や「WCAG 2.0 解説書」、「WCAG 2.0 達成方法集」が参考になります。
・ウェブ・コンテンツ・アクセシビリティ・ガイドライン(WCAG)2.0
・WCAG 2.0 解説書
・WCAG 2.0 達成方法集
また、デジタル庁では、ウェブアクセシビリティ導入について、画像付きでわかりやすいガイドブックやチェック項目を公開しています。
・ウェブアクセシビリティ導入ガイドブックのwebサイト
JIS X 8341-3:2016の資料はこちらから購入します。
・JIS X 8341-3:2016資料購入サイト
まとめ
・既存サイトにウェブアクセシビリティを導入するには、現状の調査から行う
・達成しないと利用者に重大な悪影響を及ぼすものとして非干渉という達成基準がある
・ウェブアクセシビリティは重要度の高い項目から対応していく
・ウェブアクセシビリティ基盤委員会が日本語訳しているガイドラインが参考になる
次回は「4.ウェブアクセシビリティの試験を行う」についてです。
関連記事
この記事のハッシュタグ #Accessibility から関連する記事を表示しています。
タブのアクセシビリティ実装テクニック
タブはなぜ難しい?ウェブでよく使われるUIのひとつが「タブ」。見た目はシンプルですが、実際にアクセシビリティ対応を行うと「ロールや属性の付与」「選択状態の管理」「キーボード操作」など考えることが多く、実装難度は意外と高めです。タブをUIとして選択しないという手段もありますが、必要なケースもあります。よくある惜しい実装例キーボード操作できない現在地が伝わらないすべてtabindex="0"こうした実装を避けるため、ここでは APG(ARIA Authoring Practices Guide) をベースにしつつ、利用シーンに合わせて調整できる実装方法を紹介します。https://www.w3.org/WAI/ARIA/apg/patterns/1) ロールと要素を正しく関連付けるタブUIの基本は 「どことどこが結びついているか」を明示することです。tablist・tab・tabpanel のロールを付与し、aria-controls・aria-labelledby で相互参照を作ります。参照IDは一意であることが必須です。2) ロービングタブインデックスを理解Tabキーで移動したときに、選択中のタブだけがフォーカス可能にするのが「ロービングタブインデックス」です。aria-selected とセットで更新するのがポイントです。これにより、矢印キーやTabキーでの移動が直感的かつスムーズになります。3) キーボード操作(矢印+Home/End)タブは キーボード操作のしやすさが大事です。横型なら ←/→、縦型なら ↑/↓ を割り当て、Home/End で先頭・末尾に移動できるようにします。循環移動(最後の次は最初へ)も実装すると操作性が上がります。また、aria-orientationで 向きを明示することも大切です。これにより、縦型タブでもスクリーンリーダー・キーボード操作の両方に正しく伝わります。タブとスクリーンリーダー対応について主要な支援技術での挙動は以下の通りです。特に PC-Talker ユーザーにとっては「タブUIそのものが見えない」課題が残ります。NVDA(Windows):○ タブを認識するVoiceOver(iOS / Mac):○ タブを認識するTalkBack(Android):○ タブを認識するPC-Talker(Windows):△ タブを認識しないPC-Talker向け改善案他のスクリーンリーダーでは少し冗長になりますが、補助的にスクリーンリーダー用テキストなど用意することで改善できる場合があります。「現在は〇〇のタブを表示中です」といった短い一言を補足的に伝えるイメージです。プロジェクトの性質や利用者層に応じて、採用してみてください。まとめタブのアクセシビリティ実装は難しく見えますが、ポイントを押さえればシンプルです。ロールや要素で関係を作る選択中だけtabindex=0とaria-selected="true"矢印キー操作を入れる向きをaria-orientationで伝えるこの4つを押さえるだけで、支援技術ユーザーにとってぐっと快適になります。告知2025年10月3日(金)21:00 - 26:00 オンライン開催の「#朝までマークアップ 3(JS編)」に出演いたします。当日は、アクセシビリティを考慮したUIの話をします。この記事にご興味を持っていただけましたら、ぜひご参加ください!
スタッフブログ
動きのあるウェブアクセシビリティ対応はどうやって対応するの?
モーダルやタブ、アコーディオンなど「動き」のあるUIは、デザイン性や利便性を高める一方で、支援技術ユーザーにとっては操作や理解が難しくなることがあります。そのため、動きを伴うコンポーネントを実装する際は「アクセシビリティ対応」が欠かせません。参考ガイドラインW3C が公開している ARIA Authoring Practices Guide (APG) では、実際のUIパターンごとに「ロールや属性の付け方」「キーボード操作の仕様」などが整理されています。タブ、モーダル、ツリー、メニューなど、多くのケースで 実装コード例 が紹介されており、開発者が迷わず対応できるようになっています。ARIA Authoring Practices Guide (APG)このガイドを参考にすることで、動きのあるUIをアクセシブルに作るための基本を把握することができます。実際にどう活かすか実務では、APGが全て正解として見るだけでなく、実装しているUIが 想定された操作と一致しているかロービングタブインデックスやaria属性の相互参照が抜けていないかスクリーンリーダーで操作が伝わるかスクリーンリーダー読み上げに無理はないかキーボード操作で操作できるかといった観点でチェックするのも大事なポイントです。自社の取り組み:ハンドブックとブログ私たち、ましじめでも、社内外の方に役立つよう「ウェブアクセシビリティハンドブック」と「アクセシビリティ連載ブログ」を公開しています。日本語で考え方もまとめていますので、ぜひ参考にしてみてください。ウェブアクセシビリティハンドブックブログ:アクセシビリティ連載おわりに「動きのあるUI」をアクセシブルにすることは、単に基準に適合させるためだけではなく、誰にとっても「自然に使いやすい」体験につながります。APGを基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ