この記事は アソビュー! Advent Calendar 2019 - Qiita 18日目の記事です。
アソビュー株式会社でプロダクトのデザイナーをやっている山中と申します。よろしくおねがいします。
今回は、アクセシビリティに関して個人的に思う部分を書いてみます。
はじめに
アクセシビリティに関することは、以前からとある層で意見交換されていて、
ここ最近は記事も多くなりUI実装する際にも考慮したりしている企業も増えてきている。と感じています。
規格や基準、ガイドラインもあります。
アクセシビリティをかんたんに言ってしまうと、『使えない(アクセスできない)をなくしていく』
ことです。
決して「一部の人向け」ではありません。だれが、いつ、どこで、どのように使うかは様々です。
なので、webサービスを開発している我々にとっては、『UIの品質に関わること』
と捉えていく方が自然だと感じていて、日頃行っているコードレビューやQAテストにこれらのチェック項目や思想を導入してしまうのが継続的で良いと考えます。
もったいないと感じるUI
span でくくる button
キーボードでフォーカス、選択ができない
<span onClick={hogehoge}>これはボタンです</span>
span でくくる a
URLが確認できなくて怖い
<span onClick={gotoHoge}>ここはリンクです</span>
こちら、のリンク
なにがこちら?怖すぎる
<a href="gotoHoge">こちら</a>
hoverメニュー
キーボード、タッチデバイスでアクセスできそうもない
<style>.mainMenu:hover > div{display:block;}</style>
<span class="mainMenu">
<div>ここはメニューです</div>
</span>
これらの部分を良くするだけでも、アクセスできる人は増えるはずです。
どうやったら社内に広まるか
- 関心を持ってもらうための勉強会の実施
- 世界の動きを知ってもらう(例:2000年シドニーオリンピックの公式サイトから情報を取得できない申し立て)
- 画面を見ずに操作してみる(音声とキーボードのみで操作できるか否か)
- つかえないものを作りたくないよね、と無言の圧力をかける
- テスト項目にいれてしまう
などを行うと、意識してもらえるようになるはずです。
どのように継続していくか
各種ブラウザやデバイスの対応ができるんだから可能!
- コードレビューにアクセシビリティ観点を導入
- 徐々に基準をつくっていく(一気に作ってもたいへんなだけ)
さいごに
よし!アクセシビリティ対応やろう!と力んでもできるものでもないし継続しないので、
現状をしっかりと把握して、ちゃんとやればUIを作っている人たちも使ってくれる人たちもハッピーになるはずです。
「使えない」を減らすために知識を学ぶ努力は必要ですが、一人ではないのでできると思います。
ありがとうございました。
過去に書いたアクセシビリティ関連の記事
書いたの、3年前(2016年)前なのか...。
(記事を書くのが億劫で途中でやめてしまったんですねw)