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