Webアクセシビリティのアドベントカレンダー 5日目の記事です。
概要
突然ですが、皆さんはガラホを使ったことはありますか？
https://k-tai.sharp.co.jp/support/changeguide/guide5/p01.html
ガラケーのハードウェアの中身をスマートフォンのOSにした端末のことで「進化型ケータイ」と呼ばれることもあるそうです。 今回、こういった端末に向けての開発をやる機会があったので、そのまとめも兼ねて振り返ってみることにします。
ガラホの操作感について
ガラホは通常のスマートフォンと比べて操作感が大きく違います。基本的な操作はボタンでおこない、ボタン部分についているセンサーでポインターを操作してのブラウジングも出来たりします。固有名詞も多いので、興味のある方はSoftbankの紹介ページを見てみるのがお薦めです。
普段から慣れ親しんでいるスマートフォンのタッチ操作を比較すると勝手が色々と違うので、僕はここで画面操作のアクセシビリティを考え直すきっかけを得ました。
開発中にハマったこと
モダンブラウザ前提のデザインが崩れる、というような話もありました。ですが、何よりも苦戦したのはラジオボタンやチェックボックスといったフォーム要素がボタンで操作できなかったことでした。
ここでやらかしてしまっていたのは、アクセシビリティ的によろしくない見た目のカスタマイズでした。ガラホ操作だけでなく、キーボード操作も出来ない箇所もありました。
キーボード操作でもガラホでもきちんと使える状態になったサンプルを先に挙げておき、その後に良くなかったポイントに触れていきます。きちんと動いてるサンプルはこちらです。
良くなかったポイント
幾つかあったので、1つ1ついきます。
1. input要素をdisplay:noneにしてしまうパターン
Webアクセシビリティを学んでいる方にとっては当たり前の話かもしれませんが、今回はこれを踏み抜いてしまいました。
実装サンプルを用意したので、キーボードで操作が出来るかどうか見てみてください。見た目は先程のサンプルと変わりませんが、キーボードでinput要素にフォーカスをあてることが出来ない筈です。
見た目は問題なさそうで、マウスやタッチパネル操作だと問題なく使えてしまうのが落とし穴ですね。
2. input要素をz-indexで隠してしまうパターン
元々のinput要素が見えないようにするため、カスタムした要素の後ろに隠して見た目を担保するアプローチですね。
これまで同様、実装サンプルを用意しました。この実装であればキーボード操作は出来るのでOKかと思っていたのですが、冒頭で触れたガラホのボタンではフォーカスが当たらず、操作が出来ませんでした。
解決のアプローチ
結論から言うと、position: absoluteで位置取りして、opacity: 0で見えなくするのが今回はベストでした。キーボード操作、ガラホ操作共に問題ない実装ではその方法をとっています。
ついでに意識しておくと良いこと
見た目をカスタマイズしたチェックボックスやラジオボタンの見た目についてです。:checked時の見た目を気にしない人はいないと思いますが、:focus時の見た目を見落とすことはありがちかもしれません。僕自身も、つい最近まで意識出来ていませんでした。
「見た目は変わってないけど、実はフォーカスが当たってる」という状態にならないよう、outlineなどで装飾することを忘れないようにしておきましょう。
まとめ
今回、普段使っているスマートフォンとは違うガラホという環境を知ったことで、アクセシビリティについて様々な気づきを得ました。マウスであれば楽にスクロール出来るのに、地道にボタン押下でスクロールしていかなければいけなかったり。スマートフォンなら指で画面を押せばいいだけなのに、ボタン操作でフォーカスを当ててから押さなければいけなかったり。
普段のマウス操作やタッチパネル操作がいかに楽かを実感しました。
アクセシビリティを全く意識してこなかったわけではないですが、色のコントラスト比やタイポグラフィにしか目が向いていなかったのは事実です。今回の反省を活かし、使いやすいWebページを作ることをこれからも頑張ってやっていこうと思います。
