多様なユーザーニーズに応えるフロントエンドデザインパターン：入力フォーム編

Transcript

1. 多様なユーザーニーズに応える フロントエンドデザインパターン 〜入力フォーム編〜 伊原 力也 2018.03.15 1
2. 伊原 力也 2 • freee IA/UX • HCD-Net 評議委員 / 認定人間中心設計専門家 • ウェブアクセシビリティ基盤委員会 WG1委員 • 国際ユニヴァーサルデザイン協議会 移動空間研究部会 副主査
3. https://www.hcdnet.org 3
4. https://waic.jp 4
5. Amazonで「アクセシビリティ」と検索！ 5
6. 6 Amazonで「インクルーシブHTML」と検索！
7. 7 Amazonで「インクルーシブHTML」と検索！
8. この本は? 普及しているUIについて、アクセシブルなデザインパターンを提供 • 「やるな」ではなく「こう実装するとアクセシブル」という話 （とはいえ、これはやってはダメ、という話ももちろんある） • ブログ記事、ナビゲーション、メニューボタン、 商品リスト、フィルターウィジェット、登録フォームなど 8
9. 9 + Accessibility
10. 10
11. 11
12. 12 スライド 動画
13. 今日はフォームの アクセシビリティの話をします 13
14. webをインタラクティブにしているのは リンクとフォームだから 14
15. 15
16. フォームといえば • 入力欄とラベル • エラー表示 16
17. 入力欄とラベル 17
18. 入力欄とラベルのポイント 18 1. 入力項目とラベルを明示的に関連付ける 2. 見た目でも入力項目とラベルの対応を明確に 3. 何が起きるか明白なラベルにする 4. プレースホルダをラベル代わりにしない 5. 必須と任意を明示する 6. 入力条件は先に提示する
19. Point 1 入力項目とラベルを明示的に関連付ける <form id="register"> <label for="email">メールアドレス</label> <input type="text" id="email" name="email"> <label for="username">ユーザー名</label> <input type="text" id="username" name="username" placeholder="例:HotStuff666"> <label for="password">パスワード</label> <input type="password" id="password" name="password"> <button type="submit">登録する</button> </form> 19
20. Point 1 入力項目とラベルを明示的に関連付ける <form id="register"> <label for="email">メールアドレス</label> <input type="text" id="email" name="email"> <label for="username">ユーザー名</label> <input type="text" id="username" name="username" placeholder="例:HotStuff666"> <label for="password">パスワード</label> <input type="password" id="password" name="password"> <button type="submit">登録する</button> </form> 20
21. 明示的に関連付けると この例では、スクリーンリーダーユーザーが パスワードフィールドにフォーカスを合わせると、 「パスワード エディット、保護つき」などと読み上げられます。 21
22. 明示的に関連づけるべき理由 スクリーンリーダーユーザーがどのように フォーム内を移動するかを理解する必要があります。 散文的なコンテンツでは、ユーザーは下矢印キーを使って 要素間を順に移動しますが、フォームでは異なり、 あるフィールドから次のフィールドへ直接移動する操作が行われます。 このとき、ラベル要素は飛び越されてしまいます。 ラベル要素とインタラクティブ要素が明示的に関連づけられていない場合、 そのラベル要素は見逃されてしまうのです。 22
23. Point 2 見た目でも入力項目とラベルの対応を明確に 23
24. Point 2 見た目でも入力項目とラベルの対応を明確に 24
25. labelの応用例 25
26. 択一選択なのでラジオボタン＋labelに <input type="radio" name="sort-method" id="most-recent" checked /> <label for="most-recent">新着順</label> 26
27. 隣接セレクタでlabelにスタイルを付ける [type="radio"] + label { cursor: pointer; /* その他、基本のスタイル */ } [type="radio"]:focus + label { /* フォーカス時のスタイル */ } [type="radio"]:checked + label { /* 選択時のスタイル */ } 27
28. ラジオボタンを力強く隠す .sorter [type="radio"] { position: absolute !important; width: 1px !important; height: 1px !important; padding:0 !important; border:0 !important; overflow: hidden !important; clip: rect(1px, 1px, 1px, 1px); } 28
29. Point 3 何が起きるか明白なラベルにする 29
30. Point 3 何が起きるか明白なラベルにする 30
31. Point 3 何が起きるか明白なラベルにする 31
32. Point 4 プレースホルダをラベル代わりにしない 32
33. スペース節約とひきかえにユーザビリティが犠牲に 33
34. 代用すると何が起きるのか 34 • 文字を打ち始めた瞬間にラベルが消えてしまうため 何の項目か覚えておかねばならず認知負荷が高まる • placeholderをサポートしないスクリーンリーダーや ブラウザだと情報が失われて意味不明になる • ブラウザのオートコンプリート機能で複数のフィールドが 一気に埋められた際、適切に入ったか確認できない
35. 35 http://bradfrost.com/blog/post/float-label-pattern/
36. 本当にplaceholderである場合でも、文字色には注意 36
37. 文字色を濃くしつつ、スタイルを変える ::placeholder { color: #000; font-style: italic; } ::-webkit-input-placeholder { color: #000; font-style: italic; } ::-moz-placeholder { color: #000; font-style: italic; } ::-ms-input-placeholder { color: #000; font-style: italic; } 37
38. Point 5 必須と任意を明示する 38
39. Point 5 必須と任意を明示する 39
40. ありがちな対応 <label for="email">メールアドレス <strong class="red">*</strong></label> <input type="text" id="email" name="email"> 40
41. より正確を期するなら <label for="email">メールアドレス <strong class="red" aria-hidden="true">*</strong></label> <input type="text" id="email" name="email" aria-required="true"> 41
42. required属性というのもあるが… 望ましくない挙動になることもあります。 初期状態で空になっている必須フィールドをエラーとして扱ってしまう、 といった動作です。今回の用途としては、これはやや冗長で、 アグレッシブすぎます。 42
43. 43 Point 6 入力条件は先に提示する
44. Point 6 入力条件は先に提示する 44
45. ツールチップ的に出すやりかたも 45
46. スクリーンリーダーも読み上げる 46
47. 47 <form> <fieldset> <legend>ログインフォーム</legend> <div> <label for="username">ユーザー名</label> <input id="username" type="text" aria-describedby="username-hint"> <div role="tooltip" id="username-hint">ユーザー名には、あなたの Eメールアドレス を登録してください</div> </div> <div> <label for="password">パスワード</label> <input id="password" type="password" aria-describedby="password-hint"> <div role="tooltip" id="password-hint">メールでお送りしたパスワードを入れてくださ い</div> </div> </fieldset> <button type="submit">サイトに入る</button> </form>
48. [role="tooltip"] { background: orange; color: white; padding: 0.25em; display: none; } input:focus + [role="tooltip"] { display: block; } 48 フォーカス時にツールチップを出すCSS
49. 49 そうそう、もう1点
50. 50 http://www.outlinenone.com/
51. 入力欄とラベルのポイント：おさらい 51 1. 入力項目とラベルを明示的に関連付ける 2. 見た目でも入力項目とラベルの対応を明確に 3. 何が起きるか明白なラベルにする 4. プレースホルダをラベル代わりにしない 5. 必須と任意を明示する 6. 入力条件は先に提示する 7. フォーカスインジケーターは消さない
52. エラー表示 52
53. エラー表示のポイント 53 1. エラーはフォーム内に出す 2. エラー状態が伝わるようにする 3. エラー箇所を明確にする 4. エラーの修正を助けるメッセージを出す 5. リアルタイム検証は慎重に使う
54. 54 Point 1 エラーはフォーム内に出す
55. Point 2 エラー状態が伝わるようにする 55
56. Point 2 エラー状態が伝わるようにする 56 登録する
57. 送信を止め、送信ボタンの上にエラーを出す例 57 <div id="error" aria-live="assertive" role="alert"></div> <button type="submit">登録する</button> #error:empty {display: none;} var form = document.getElementById('register'); form.addEventListener('submit', function(event) { if (errors) { event.preventDefault(); // 送信させない document.getElementById('error').textContent = '登録情報が正しいことを 確認してください。' } });
58. アイコン画像とaria-labelでエラーをより明白に 58 <div id="error" aria-live="assertive" role="alert"> <p> <svg role="img" aria-label="エラー:"> <use xlink:href="#error"></use> </svg> 登録情報が正しいことを確認してください。 </p> </div>
59. ライブリージョンの良いところ ライブリージョンでエラーの存在を宣言することのメリットは、 ユーザーに移動してもらわなくてもエラー情報に注意を促せる点です。 エラーになっている入力欄にフォーカスを移すことで、 フォームエラーをユーザーに警告するという方法もよく見られます。 しかし、このお節介とも言える唐突なアプリケーション内での位置移動は、 ユーザーを混乱させる恐れがあります。 59
60. ありがちな「勝手にフォーカス移動」に注意 60
61. ありがちな「勝手にフォーカス移動」に注意 61
62. Point 3 エラー箇所を明確にする 62
63. Point 4 エラーの修正を助けるメッセージを出す 63
64. Point 3 Point 4 改善案 64
65. invalidを伝え、説明文を紐付ける／アイコンを出す 65 <label for="password">パスワード</label> <input type="password" id="password" aria-invalid="true" aria-describedby="password-hint"> <div id="password-hint">パスワードは6文字以上にしてください。</div> </label> [aria-invalid="true"] { border-color: red; background: url('images/warning-icon.svg') center right; }
66. 実際の例 66
67. Point 5 リアルタイム検証は慎重に使う しゃれたフォーム検証スクリプトの中には、テキストを入力している時に リアルタイムでフィードバックを提供し、入力している内容が有効かどうか、 入力している最中に知らせてくれるものもあります。 しかし、こうしたスクリプトは管理が非常に難しくなることがあります。 特定の文字数が必要なエントリーでは、最初の何回かの キーストロークの間は常に無効なエントリーと見なされてしまうからです。 67
68. 問題なし：入力中に残りの入力可能文字数を示す 68
69. 問題あり：入力中にメールアドレス妥当性チェック 69
70. 80年代のリミックスモード ライブリージョンのエラーメッセージが 繰り返し更新される実装になっている場合、スクリーンリーダーは 80年代のリミックスモードに入ります。 「パ、パス、パ、パスワード、パスワードは6文字以上にしてください」 などと読み上げられることになります。 70
71. 対応案 71 1. キーストロークがあいたら発動するよう制御する ◦ 打ち込むたびに検証するとライブリージョンが都度読まれてしまう 2. そもそもリアルタイム検証が必要か再考する ◦ onblur時に再検証してaria-invalidの値を変えれば十分では？ 3. 必要な場合でも送信時エラー後にリアルタイム検証を発動させる ◦ 初期入力時からリアルタイム検証する必要は薄いのでは？
72. エラー表示のポイント：おさらい 72 1. エラーはフォーム内に出す 2. エラー状態が伝わるようにする 3. エラー箇所を明確にする 4. エラーの修正を助けるメッセージを出す 5. リアルタイム検証は慎重に使う
73. フォームがアクセシブルになると 多くの人のユーザビリティも向上する 73
74. webをインタラクティブに 使える人が増える 74
75. ということで 75
76. Amazonで「アクセシビリティ」と検索！ 76
77. 77 Amazonで「インクルーシブHTML」と検索！
78. Amazonで「インクルーシブHTML」と検索！ 78
79. 今日からあなたも インクルーシブデザイナー！ 79
80. 80 エンジニア・UXデザイナー積極採用中！
81. ありがとうございました @magi1125 81