意外と簡単？ディレクター、デザイナー、コーダーみんなでやろう！お問い合わせフォームから始めるアクセシビリティ

制作
2018-12-15
更新日: 2023-2-9
makino

こんにちは！クリエイティブDiv.のmakinoです。

「アクセシビリティ」
この言葉に最近マサカリ（謎）的な怖さを覚える方も増えてきているような気がする今日この頃皆さまいかがお過ごしでしょうか

アクセシビリティ対応やってみたいんだけど大変そう
正直何から始めたらいいかわからない
結局やれって言われても色とか文字サイズとかマークアップとかの知見ばっかりであまり関係ないかも…

と思ってる方もそろそろ増えてきた頃ではないでしょうか

今回ご紹介するのはアクセシビリティの初級編としてディレクター、デザイナー、コーダーと全行程の職種が携われて
比較的参戦しやすく効果も見えやすい「お問い合わせフォームから始めるアクセシビリティ」をお伝えします

この記事はWebアクセシビリティ Advent Calendar 2018の15日目の記事です

1 まず大前提としてアクセシビリティって？
2 お問い合わせフォームって融通がきかない…？
3 一般的なお問い合わせフォームによくある項目をおさらいしてみよう
4 このフォームの問題点を洗い出してみよう
5 このフォームを改善してみよう
6 まとめ

まず大前提としてアクセシビリティって？

最近web界隈では視覚障害者向けの施策やノウハウが充実してきた印象を受けます
それはとても素晴らしく良いことです

ですが！
誤解していただきたくないのはアクセシビリティは視覚障害者や高齢者のためだけではないということです

例えば

手が震えてマウスがうまく扱えない人（健常者に当てはめると寒さや緊張で手が震えてしまう）
タッチデバイスの扱いが難しい人（健常者に当てはめると指が大きくて狙いを定めにくい）
小さい文字が読めないロービジョン（弱視）の人（健常者に当てはめると近視、遠視、乱視、老眼、メガネ忘れた、メガネ壊れた、コンタクト落とした）
画像の識別が難しい（今はだいぶ改善されましたがクローラーなどがそうですね）

このようにさまざまな状況におかれた様々な人たちにアクセスしやすくさせるのがアクセシビリティなのです

弊社ブログでも直接「アクセシビリティ」とは書いておりませんが
例えば

こういった施策も実はアクセシビリティに通じているのです

お問い合わせフォームって融通がきかない…？

お問い合わせフォーム
様々な媒体を使って実装してきましたがソースコードに関しては意外と融通がきかないことが多い印象です

既存システムに合わせなきゃならない
マークアップありきのデザインになりがち
吐き出されたソースコードが汚い

などなど…
融通がきかないのならアクセシビリティなんて対応できないんじゃないか？
と思いがちですが融通が利かなくてもできることはあります
ということで融通の利かないフォームでもできるアクセシビリティ対応をご紹介していきます

一般的なお問い合わせフォームによくある項目をおさらいしてみよう

下記はいわゆるよく見る項目です

お問い合わせ種別（チェック）
お名前
ふりがな
会社名
性別（ラジオ）
メールアドレス
電話番号
住所（郵便番号から自動入力）
お問い合わせ内容
送信ボタン

これをかるくコーディングしてみるとこんな感じ

See the Pen <a href='https://codepen.io/di_cr/pen/VqeJJw/'>VqeJJw</a> by di_cr (<a href='https://codepen.io/di_cr'>@di_cr</a>) on <a href='https://codepen.io'>CodePen</a>.

（当たり前ですがこのフォームはどこにも送信されませんのでご安心ください）
※ソースは実際のシステムから吐き出されたものを使用しており改変不可のものです

このフォームの問題点を洗い出してみよう

よく見るこのフォームにおいてアクセシビリティ上よろしくない事とはどんな事でしょうか

ラベル

カタカナで書かれた「フリガナ」
ひらがなで書かれた「ふりがな」

という表記
本当にやめましょう

なぜお問い合わせフォームでは

カタカナで書かれた「フリガナ」
ひらがなで書かれた「ふりがな」

を多用されてしまうのでしょうか？

理由として考えられるのは

「制作者が視覚に依存している」
「真似することを求めている」
「公共の用紙にそう書かれてある」

からではないかと予測しています

ここで問題が生じるのは「視覚障害者」が使用している支援ツールです

カタカナで書かれた「フリガナ」
ひらがなで書かれた「ふりがな」

どんな文字種で入力すればいいのかは支援ツールを使用している方はわかりません
ではどのように文字種を確認するかというと

一文字ずつラベルに書かれた文字種を確認する
とりあえずひらがなやカタカナで入力して返ってくるエラーに合わせて修正する

といった手間をかけている方もいらっしゃいます
そういった不毛な作業をユーザにさせないおもてなしをしてあげるとアクセシブルですね

プレースホルダー

まず大前提としてラベル代わりにプレースホルダーを使用してはいけません
プレースホルダーは「仮」の情報なので文字を入力しようとしてフォーカスが当たった瞬間にプレースホルダーに書かれた内容は見えなくなります
プレースホルダーをラベルの変わりに用いることはユーザの短期記憶に負担をかけ入力エラーを誘発してしまいます

縦幅を削減しようとするあまりにラベルの代わりをプレースホルダーに担わせる手法を見ますがユーザビリティテストでは全てのユーザに様々な問題があることがわかっています

さらに入力エリアに表示されているテキストを「すでに入力済である」と誤解する可能性もあります
入力済であると誤解させないよう文字色を薄くする手法もよく見ますが今度はコントラスト比が保たれていない場合が多く
WCAG2.0 コントラスト (最低限) :達成基準 1.4.3 を理解する
を満たさない場合が多くなります

参考：入力フォームのプレースホルダを使ってはいけない
（4年前の記事ですが本質は変わりません）

入力エリア

問題点は3つです

パーキンソン症候群のように震えの症状のある方は入力エリアがゆったりしていないのでマウスを使っているユーザはカーソルを入力エリアに合わせることが難しくなります
スマホで閲覧している方は入力エリアの文字サイズが16px以下だと入力エリアにタップしただけで拡大表示されてしまい使い勝手が非常に悪くなります
注意欠陥障害のような方は入力中の場所を見失う可能性があるので色を変えて現在どこにいるかをわかるようにしましょう

ラジオボタンとチェックボックス

タップエリアがフォームパーツからテキスト部分までしかないので小さな場所にカーソルを持っていったりタップするのは非常に大変です
さらにフォーカス（アウトライン）も消されているのでキーボードで操作しても今どこにフォーカスが当たっているのかまったくわかりません

住所自動入力のある場合

郵便番号を入力したら自動的に入力されるフォーム最近良く見ますよね
とてもありがたい半面勝手に入力されてしまうとユーザは戸惑ってしまいますので自動入力される場合は必ず一言添えるようにしてください

さらに自動入力された後フォーカスを勝手に飛ばさないことです
一見便利に見えますがユーザは意図していない動きに大混乱してしまいますしフォーカスを見失ってしまいます
フォーカスは勝手に飛ばさないようにしてください

確認ページへ飛ぶボタン？送信するボタン？

「送信する」と書いてあるのに押したら確認ページへ飛んだ
というフォームもありますが次に起こる事象をユーザに適切に伝えるようにしなければなりません

確認画面がない場合は
「確認画面は表示されない」旨を必ず書きましょう
ボタンからかなり離れた場所に書く方もいらっしゃいますがユーザはこれから送信しようとしているので離れた場所に書かれている言葉は視界に入りませんし最初に説明を書いたところで短期記憶から抜け落ちている可能性が高いです

このフォームを改善してみよう

実際に改善してみたフォームが下記です
最初のものに比べてデザインの幅も広がり操作性も向上したのではないでしょうか

See the Pen <a href='https://codepen.io/di_cr/pen/bOpbKy/'>bOpbKy</a> by di_cr (<a href='https://codepen.io/di_cr'>@di_cr</a>) on <a href='https://codepen.io'>CodePen</a>.