- 制作
- 更新日:
こんにちは！クリエイティブDiv.のmakinoです。
「アクセシビリティ」
この言葉に最近マサカリ（謎）的な怖さを覚える方も増えてきているような気がする今日この頃皆さまいかがお過ごしでしょうか
- アクセシビリティ対応やってみたいんだけど大変そう
- 正直何から始めたらいいかわからない
- 結局やれって言われても色とか文字サイズとかマークアップとかの知見ばっかりであまり関係ないかも…
と思ってる方もそろそろ増えてきた頃ではないでしょうか
今回ご紹介するのはアクセシビリティの初級編としてディレクター、デザイナー、コーダーと全行程の職種が携われて
比較的参戦しやすく効果も見えやすい「お問い合わせフォームから始めるアクセシビリティ」をお伝えします
この記事はWebアクセシビリティ Advent Calendar 2018の15日目の記事です
目次
まず大前提としてアクセシビリティって？
最近web界隈では視覚障害者向けの施策やノウハウが充実してきた印象を受けます
それはとても素晴らしく良いことです
ですが！
誤解していただきたくないのはアクセシビリティは視覚障害者や高齢者のためだけではないということです
例えば
- 手が震えてマウスがうまく扱えない人（健常者に当てはめると寒さや緊張で手が震えてしまう）
- タッチデバイスの扱いが難しい人（健常者に当てはめると指が大きくて狙いを定めにくい）
- 小さい文字が読めないロービジョン（弱視）の人（健常者に当てはめると近視、遠視、乱視、老眼、メガネ忘れた、メガネ壊れた、コンタクト落とした）
- 画像の識別が難しい（今はだいぶ改善されましたがクローラーなどがそうですね）
このようにさまざまな状況におかれた様々な人たちにアクセスしやすくさせるのがアクセシビリティなのです
弊社ブログでも直接「アクセシビリティ」とは書いておりませんが
例えば
こういった施策も実はアクセシビリティに通じているのです
お問い合わせフォームって融通がきかない…？
お問い合わせフォーム
様々な媒体を使って実装してきましたがソースコードに関しては意外と融通がきかないことが多い印象です
- 既存システムに合わせなきゃならない
- マークアップありきのデザインになりがち
- 吐き出されたソースコードが汚い
などなど…
融通がきかないのならアクセシビリティなんて対応できないんじゃないか？
と思いがちですが融通が利かなくてもできることはあります
ということで融通の利かないフォームでもできるアクセシビリティ対応をご紹介していきます
一般的なお問い合わせフォームによくある項目をおさらいしてみよう
下記はいわゆるよく見る項目です
- お問い合わせ種別（チェック）
- お名前
- ふりがな
- 会社名
- 性別（ラジオ）
- メールアドレス
- 電話番号
- 住所（郵便番号から自動入力）
- お問い合わせ内容
- 送信ボタン
これをかるくコーディングしてみるとこんな感じ
（当たり前ですがこのフォームはどこにも送信されませんのでご安心ください）
※ソースは実際のシステムから吐き出されたものを使用しており改変不可のものです
このフォームの問題点を洗い出してみよう
よく見るこのフォームにおいてアクセシビリティ上よろしくない事とはどんな事でしょうか
ラベル
- カタカナで書かれた「フリガナ」
- ひらがなで書かれた「ふりがな」
という表記
本当にやめましょう
なぜお問い合わせフォームでは
- カタカナで書かれた「フリガナ」
- ひらがなで書かれた「ふりがな」
を多用されてしまうのでしょうか？
理由として考えられるのは
- 「制作者が視覚に依存している」
- 「真似することを求めている」
- 「公共の用紙にそう書かれてある」
からではないかと予測しています
ここで問題が生じるのは「視覚障害者」が使用している支援ツールです
- カタカナで書かれた「フリガナ」
- ひらがなで書かれた「ふりがな」
どんな文字種で入力すればいいのかは支援ツールを使用している方はわかりません
ではどのように文字種を確認するかというと
- 一文字ずつラベルに書かれた文字種を確認する
- とりあえずひらがなやカタカナで入力して返ってくるエラーに合わせて修正する
といった手間をかけている方もいらっしゃいます
そういった不毛な作業をユーザにさせないおもてなしをしてあげるとアクセシブルですね
プレースホルダー
まず大前提としてラベル代わりにプレースホルダーを使用してはいけません
プレースホルダーは「仮」の情報なので文字を入力しようとしてフォーカスが当たった瞬間にプレースホルダーに書かれた内容は見えなくなります
プレースホルダーをラベルの変わりに用いることはユーザの短期記憶に負担をかけ入力エラーを誘発してしまいます
縦幅を削減しようとするあまりにラベルの代わりをプレースホルダーに担わせる手法を見ますがユーザビリティテストでは全てのユーザに様々な問題があることがわかっています
さらに入力エリアに表示されているテキストを「すでに入力済である」と誤解する可能性もあります
入力済であると誤解させないよう文字色を薄くする手法もよく見ますが今度はコントラスト比が保たれていない場合が多く
WCAG2.0 コントラスト (最低限) :達成基準 1.4.3 を理解する
を満たさない場合が多くなります
参考：入力フォームのプレースホルダを使ってはいけない
（4年前の記事ですが本質は変わりません）
入力エリア
問題点は3つです
- パーキンソン症候群のように震えの症状のある方は入力エリアがゆったりしていないのでマウスを使っているユーザはカーソルを入力エリアに合わせることが難しくなります
- スマホで閲覧している方は入力エリアの文字サイズが16px以下だと入力エリアにタップしただけで拡大表示されてしまい使い勝手が非常に悪くなります
- 注意欠陥障害のような方は入力中の場所を見失う可能性があるので色を変えて現在どこにいるかをわかるようにしましょう
ラジオボタンとチェックボックス
タップエリアがフォームパーツからテキスト部分までしかないので小さな場所にカーソルを持っていったりタップするのは非常に大変です
さらにフォーカス（アウトライン）も消されているのでキーボードで操作しても今どこにフォーカスが当たっているのかまったくわかりません
住所自動入力のある場合
郵便番号を入力したら自動的に入力されるフォーム最近良く見ますよね
とてもありがたい半面勝手に入力されてしまうとユーザは戸惑ってしまいますので自動入力される場合は必ず一言添えるようにしてください
さらに自動入力された後フォーカスを勝手に飛ばさないことです
一見便利に見えますがユーザは意図していない動きに大混乱してしまいますしフォーカスを見失ってしまいます
フォーカスは勝手に飛ばさないようにしてください
確認ページへ飛ぶボタン？送信するボタン？
「送信する」と書いてあるのに押したら確認ページへ飛んだ
というフォームもありますが次に起こる事象をユーザに適切に伝えるようにしなければなりません
確認画面がない場合は
「確認画面は表示されない」旨を必ず書きましょう
ボタンからかなり離れた場所に書く方もいらっしゃいますがユーザはこれから送信しようとしているので離れた場所に書かれている言葉は視界に入りませんし最初に説明を書いたところで短期記憶から抜け落ちている可能性が高いです
このフォームを改善してみよう
実際に改善してみたフォームが下記です
最初のものに比べてデザインの幅も広がり操作性も向上したのではないでしょうか
（当たり前ですがこのフォームはどこにも送信されませんのでご安心ください）
※ソースは実際のシステムから吐き出されたものを使用しており改変不可のものです
ラベル
誰が見てもわかりやすい日本語にしましょう
ひらがなで入力する箇所にカタカナで入力された場合（逆も然り）はシステム側で変換を行ってあげましょう
プレースホルダー
基本的にプレースホルダーをラベルの代わりに使わないことです
入力例であればある程度許容できるかもしれませんが
入力エリアにすでに情報が入っていることで逆にその項目を飛ばしてしまう可能性もあります
プレースホルダーの扱いは現時点ではとても難しいので申し訳ないのですがここで言及することはできません……
プレースホルダーは「仮」の情報であることを念頭に置いて
- 「（例）」「例）」「例：」等と先頭に書いておく
- 斜体にして明らかに仮の情報だとわかりやすくする
- フォントカラーを変える ただしコントラスト比は確保しておく
のような工夫をしてみるとよいでしょう
どうしてもプレースホルダーをラベルの代わりに使用したいのであれば
- フローティングラベル
という手法もあるようですがここは素直にラベルを使用するべきでしょう
入力エリア
余白を設けてゆったりとさせることでカーソルを合わせやすくしました
最小フォントサイズを16px以上に設定しているのでスマホで閲覧してもフォームが拡大表示されることはありません
数字入力箇所に半角入力全角入力を求めず変換はシステム側で行いましょう（エラーを返すのはもっての外です）
ラジオボタンとチェックボックス
タップエリアを広く設けましょう
キーボードで操作をしても既存の操作性は損なわずにデザインが再現できます
フォーカス（アウトライン）もしっかりデザインします
住所自動入力のある場合
郵便番号を入力するとどうなるのか予めはっきりと明言しておきます
ボタンを押すと自動入力される場合はそのように記載します
自動で入力される場合はどこまで自動入力されるのか記載しておきましょう
フォーカスは勝手に飛ばしてはいけません
確認ページへ飛ぶボタン？送信するボタン？
次に起こる動作を明記するようにします
確認画面を介さない場合はその旨をきちんとボタンの近くもしくはボタンに直接記載しましょう
まとめ
（中途半端な状態での公開で大変申し訳無いのですが）
融通の利かないフォームでHTMLに制限がある中でも意外とデザインできることや
アクセシビリティを改善するとユーザビリティも高まることがおわかりいただけると思います
（デザイン素人が作ったデザインなのでデザイナーさんはもっとうまく作ってくださいｗ）
実際にこの改善策を見ても
「大したことないじゃん」
と思われたかもしれません
「たったこれだけ」でもフォームのアクセシビリティやユーザビリティは高まるのに
「たったこれだけ」をやらない理由はないですよね？
さらに応用編として「ARIA属性」というものを入れるとよりアクセシブルになりますが
このあたりはより詳しい方に丸投げしつつ各々で調べて奥深き世界を堪能するのも楽しいですよ！
（ソースいじれない場合は難しいですが…）
ARIA属性の世界を覗いてみる
そして！
アクセシビリティに携わっている有識者がまとめている資料が「無料」で公開されていますのでこちらもぜひ参考にして下さい！
Webアクセシビリティ関連の資料まとめ
アクセシビリティは
「できることから少しずつ」
がとても大切です！
だからこそ
- 敷居を低く
- 難しい言葉は使わない
をモットーに今後も伝えていけたらなと思っています！
明日はcaztchaさんです
お楽しみに！
DIではアクセシビリティやEFOを始め、CVへの誘導を意識した設計・デザインのコンサルティングをご提供しています。
webサイトのコンバージョン率を改善したい方、動線に改善余地が無いか気になる方、お気兼ねなくお問い合わせください！
自社サイトのウェブアクセシビリティ状況、診断してみませんか？
株式会社デジタルアイデンティティでは、ウェブアクセシビリティ診断サービスを提供しています。
2024年4月、障害者差別解消法の改正施行に伴い、2024年6月から一般企業にも「合理的配慮」が義務化されています。
これに伴い、努力義務である「環境の整備」に含まれるウェブアクセシビリティについても、対応を進める企業が増えています。
こんなお悩みはありませんか？
- どこからウェブアクセシビリティ対応に手をつければ良いかわからない…
- 今のサイトで問題のあるページを一覧化して欲しい…
- ウェブアクセシビリティの具体的な改善方法を知りたい…
WCAG2.2に準拠した診断項目・達成基準で、問題のあるページをリスト化してページ単位で問題点をリストアップ。
課題点が明確になるので、具体的な改善アクションに繋げることができます。
また、診断後の改善作業を弊社にワンストップでご依頼いただくことも可能です！
ぜひお気軽にご相談ください！
![[無料] webサイトに関するお悩みを解決! webサイト診断【期間限定】「UI/UX分析」「EFO診断」「ページ表示高速化診断」詳しくはこちら](https://digitalidentity.co.jp/blog/wp/wp-content/themes/gorgeous_tcd013-child/img/common/bnr/sidebar-website-sindan.jpg)
