こんにちは。フロントエンドエンジニアの hikaru です。
最近フロントエンドエンジニアの採用面談に同席する機会が多く、
採用の要件ではないのですが、興味本位で「アクセシビリティ対応したことありますか?」と質問することがあります。
が、いまだにひとりも対応したことがある人に出会ったことがなく、言葉自体を知らない方も...
ということで、今回のブログでは、今日から簡単に実践できるWebアクセシビリティ対応をいくつかご紹介したいと思います。
そもそもWebアクセシビリティとは?
W3C では、
Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.
「Webサイト・ツール・技術などが、障害のある人にも使えるようにデザイン・開発されていること」と説明されています。
それだけではなく、障害を持たない人にも利便性をもたらすと説明が続きます。
Web accessibility also benefits people without disabilities, for example:
- people using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
- older people with changing abilities due to aging
- people with “temporary disabilities” such as a broken arm or lost glasses
- people with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
- people using a slow Internet connection, or who have limited or expensive bandwidth
この中にはさまざまなデバイスで使用できること、
まぶしい場所や音声再生ができない状況でも使用できること、
インターネット回線が遅い場合もコンテンツが閲覧できること、なども含まれています。
Webアクセシビリティ = 障害がある方への音声支援対応と思われていた方も多いのではないでしょうか?
実際にはそれだけではなく「ユーザーの能力、環境、状況に関わらず、利用できるコンテンツやサービスを実現すること」が求められます。
具体的になにをすればいいの?
アクセシビリティガイドラインには非常に多くの項目があります。
- Web Content Accessibility Guidelines (WCAG) 2.0
- 上記をもとに制定されたJIS規格(「JIS規格番号からJISを検索」から「X8341-3」と検索)
- JIS X 8341-3:2016 達成基準 早見表(レベルA & AA)
具体的な例をいくつか上げると、
- 画像・アイコン・色だけで情報を表していないか?適切な代替テキストが用意されているか?
- 文字色と背景色とのコントラスト比は読みやすく保たれているか?
- フォントサイズは読みやすく保たれているか?ブラウザのデフォルトフォントサイズを変更しても表示に耐えうるか?
- すべてのコンテンツ・機能がキーボードで操作可能か? (モーダルや全画面メニューを展開した場合のキーボードトラップを含む)
- ユーザーの予期せぬ動作をしないか?コントロールするオプションは提供されているか? (動画の自動再生など)
- エラーが起こった際に回避する方法は示されているか? (フォームの入力など)
などなど、デザイナーもエンジニアも気をつけることがたくさんあります。
全部対応しようとしたら本当に大変だし、十分な時間や予算や人員を確保することも難しい場合が多いのではないかと思います。
私は普段フロントエンドの業務をしていて、
- ここアクセシビリティ対応できてないけど要件じゃないから後回しにしよう
- 後回しにした結果、これ一生実装されないんじゃないかなー
と思うことがよくあります。
そのため、普段の業務の中でちょっと気をつければできることはできるだけ実装するようにしています。
細かいマークアップの仕方・スタイルの付け方、キーボード対応など色々あるんですが書き出すとキリがないので、
今日は私が実践しているものの中から、プラス工数かけることなくすぐに実践できるものを4つご紹介します 😊
1. リセットCSSにアニメーション抑制用スタイルを追加してみよう
@media(prefers-reduced-motion: reduce) { *, *::before, *::after { transition-duration: .01ms !important; animation-duration: .01ms !important; animation-iteration-count: 1 !important; scroll-behavior: auto !important; } }
よくあるパララックスエフェクトや、スクロールジャックなどのアニメーションですが、好まない人もいれば、体質的に酔ってしまう人もいます。
そのような場合に、各OSではアニメーションを抑制するオプションを提供しています。
このコードは、メディアクエリで設定を検知した場合、スタイルで指定したアニメーションを解除するというものです。
リセットCSSに追記するだけでOKなので、ぜひ使ってみてください。
2. スクリーンリーダー用クラスを使ってみよう
.visually-hidden { position: absolute !important; left: -10000px; // 1 width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); }
*1: clip-path
非対応ブラウザに必要です。
画面上の文字情報が十分ではなく、スクリーンリーダー向けに補足情報が必要なときに使用します。
.sr-only
という名前の場合もあります。Bootstrap などの CSSフレームワークにも多く組み込まれていますが、使ったことはありますか?
使用できる場面
- 段階フォームの上のステップインジケータに数字やアイコンしか表示がない場合
- ページネーションの「一番最初のページ/前のページ/次のページ/一番最後のページ」へのリンクがアイコンで表示されている場合
ステップインジケータだとこんなかんじですね。
ステップ番号だけだと何を指しているかわからないので、入力してほしい内容をテキストで補足し、スクリーンリーダーに読み上げられるようにしています。
See the Pen Accessible Step Indicator by QUICK Web Service Development (@quick-engineers) on CodePen.
マークアップしながら、画面が見えない人にはどう読み上げられたら分かるかな?と想像力をはたらかせることがだいじです。
マークアップをちょこっと追加するだけなので、気づいたときにすぐ使ってみましょう。
3. ブラウザのネイティブ属性をもっと使おう
.is-hidden
.is-disabled
なんてクラスを作っていませんか?
クラスはブラウザの音声支援技術には何も伝えてくれません。
HTMLのネイティブ属性を使えば、わざわざクラスを作る必要もなく音声対応を追加する必要もありません。
.is-hidden
→[hidden]
.is-disabled
→[disabled]
を使うようにしましょう。
私は以下の設定をこれまでご紹介したものと一緒にリセットCSSに含めて使っています。
[hidden] { display: none !important; } [disabled] { cursor: not-allowed !important; opacity: .4; }
アニメーションを設定する場合は display: none
だと実現できないため .is-hidden
のようなクラスが必要になることももちろんありますが、その場合は次に説明する WAI-ARIA属性を使用します。
4. WAI-ARIA 属性を使ってスタイリングしよう
これはちょっと応用編。だけど覚えてしまえばすごく簡単です。
WAI-ARIA とは?という方は MDN を参考にしてください。
よくあるハンバーガーメニュで説明します。
<nav> <button type="button" aria-controls="コントロール対象要素のID" aria-expanded="メニューが開いていれば true / 閉じていれば false" aria-label="メニューを開く / メニューを閉じる (スクリーンリーダーに読み上げさせたい文章)" >🍔</button> <ul id="ユニークなID" aria-hidden="メニューが開いていれば false / 閉じていれば true" > <li><a href="#">メニュー</a></li> <li><a href="#">メニュー</a></li> </ul> </nav>
- HTMLに WAI-ARIA 属性を追加、開閉状態によってJSで属性値を切り替えるように実装します。
- ボタンの
[aria-expanded="true/false"]
、メニューの[aria-hidden="true/false"]
をセレクタに指定しスタイルを当てることによって動きをつけます。
JSでメニューの展開時にクラスをトグルさせる処理を書くのと何も変わらないですよね?
WAI-ARIA属性を使用すれば、音声対応もスタイリングも同時にできて一石二鳥なので、
ハンバーガーメニュー、タブ、モーダルなどの一般的なUIはパターンを覚えてしまい WAI-ARIA 属性で動きをつけるようにしています。
他のコンポーネントにも興味がある方は A11Y Style Guide を参考にしてみてください。
※ nav
要素自体を非表示にしてしまうとユーザーが混乱してしまう恐れがあるので、内側の要素の表示/非表示を切り替えます。
※ WAI-ARIA 属性をつけた要素がブラウザにどのように解釈されるかは、Chrome の場合 Accessibility タブ から確認できます。
※ 実際にどのように読み上げられるかは、Mac なら VoiceOver、Windows ならナレーターというアプリを使用して確認することができます。
まとめ
簡単にできるWebアクセシビリティ対応をいくつかご紹介しました。
ブラウザの音声支援技術への対応などむずかしそうなイメージがありますが、
アクセシビリティ対応と身構えたり、プロジェクトとして走らせなくても、
普段マークアップやスタイルを書くときにちょっと気をつけるだけでできることもたくさんあります。
海外ではWebアクセシビリティに不備があるとして企業が訴えられることもあるそうです。 それに比べると日本はまだまだ遅れています。
この記事を読んで意外と簡単にできるんだと知っていただけたら嬉しいです。
今日できることから少しずつ始めていきましょう😊
\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //