実はできている!? webアクセシビリティ

207
実はできている!? Webアクセシビリティ

Upload: -

Post on 21-Apr-2017

880 views

Category:

Design


0 download

TRANSCRIPT

実はできている!?Webアクセシビリティ

注意事項

会場は禁煙です。

ハッシュタグは#a11ybooks となります。

イベントの模様は自由に撮影いただき、ブログやSNS等で拡散いただいて構いません(むしろお願いします)。主催者も、公式Facebookページ用に写真撮影をいたします(ご了承ください)

スライドの公開は主催者よりSNSなどでご案内します。

2

本日の流れ

自己紹介

アクセシビリティとは?

実はできている!?

アクセシビリティだと思っていたが……?

気づかないうちにアクセシビリティを確保していた!

3

自己紹介

4

BA

5

ウェブアクセシビリティ基盤委員会(WAIC)

6

デザイニングWebアクセシビリティ

7

アクセシビリティとは?

アクセシビリティとは

さまざまな利用者がさまざまな環境でアクセス可能であること 情報を認識して理解できる

さまざまな選択肢が提供されている

自分に合った形で利用できる

9

さまざまな環境

10

ビジュアルブラウザ (Firefox)

11

テキストブラウザ (w3m)

12

ダウンローダー (SiteSucker)

13

クローラー (Googlebot)

14

ハイコントラストモード

15

ハイコントラストモード

16

拡大ツール (Windows拡大鏡)

17

スクリーンリーダー (NVDA)

18

スクリーンリーダー (VoiceOver)

19

代替マウス

20

点字ディスプレイ

21

視線入力装置

22

障害者のウェブページ利用方法の紹介ビデオ

23

障害者のウェブページ利用方法の紹介ビデオ

実際に支援技術を使ってアクセスしている様子を見ることができる 視覚障害者(全盲)

視覚障害者(弱視)

肢体不自由者

http://www.soumu.go.jp/menu_news/s-news/2005/051215_1_wmv.html

24

アクセシビリティだと思っていたが……?

アクセシビリティに配慮

と言われたとき、何を思い浮かべますか?

アクセシビリティに配慮したサイトとは?

26

福岡県大野城市

27

福岡県大野城市

28

文字サイズ変更ボタン・色反転ボタン

29

東京都西東京市

30

東京都西東京市

31

「本文へ」リンク

32

東京オリンピック・パラリンピック競技大会組織委員会

33

東京オリンピック・パラリンピック競技大会組織委員会

34

カルーセル停止 / 再生ボタン

35

JISの文字サイズ変更の要件

1.4.4 テキストのサイズ変更の達成基準

キャプション及び文字画像を除き,テキストは,コンテンツ又は機能を損なうことなく,支援技術なしで200 %までサイズ変更できる(レベル AA)。

36

実際にはどうか?

37

サイズ: 小

38

サイズ: 中

39

サイズ: 大

40

文字サイズ変更機能の現実

中を100%としたとき、大は約133%

「大」を複数回押しても大きくならない

拡大される要素はテキストのみ ナビゲーションや見出しの文字は大きくならない

41

熊本県の例

42

熊本県の例

43

ところで……

44

総務省 みんなの公共サイト運用ガイドライン

45

2.1.4. ウェブアクセシビリティ対応に関する誤解

46

2.1.4. ウェブアクセシビリティ対応に関する誤解

注意点!

ホームページ等において、音声読み上げ、文字拡大、文字色変更等の支援機能を提供する事例がありますが、これだけでは、ウェブアクセシビリティに対応しているとは言えません。

47

Webアクセシビリティの確保は特別なことではない。障害者差別解消法の施行で考えるべき企業サイトの品質

48

植木さんのコメント

49

文字サイズ変更ボタンや音声読み上げ機能は

必要なのか?

よくある質問

50

JISに準拠していれば、どちらもいらない

植木さんの回答

51

植木さんのコメント続き

実際に試すと、ほとんど文字の大きさが変わらない文字サイズ変更ボタンが少なくない

最近のWebブラウザであればズーム機能を標準で搭載している

意味のない文字サイズ変更ボタンはやっている感を出すための免罪符に近い

52

基準を満たす方法の例

53

ブラウザのズーム機能を利用する

ブラウザの機能で文字サイズを変えられるようにする

文字サイズ変更ボタンをつける

文字サイズを変えても重なったりはみ出したりしないようにする

54

JISの文字サイズ変更の要件

1.4.4 テキストのサイズ変更の達成基準

キャプション及び文字画像を除き,テキストは,コンテンツ又は機能を損なうことなく,支援技術なしで200 %までサイズ変更できる(レベル AA)。

55

これは何?

3つのレベル

レベル A : 支援技術を駆使すればアクセスできる

レベル AA : 支援技術がなくても多くの環境でアクセスできる

レベル AAA : 支援技術がなくても多くの環境でアクセスしやすい

発展的なもの、達成が難しいものを含む

56

文字サイズの変更はレベル「AA」

支援技術を使えば、以下のようなことが可能 サイト側の文字サイズの指定を無視して

ユーザーが好みのサイズに変更

テキストを音声で読み上げる

57

ここまでのまとめ

58

ここまでのまとめ

文字サイズ変更などの機能は目立つが、あまり役に立っていないこともある

文字サイズが変更できることは大切だが文字サイズ変更ボタンでなくてもよい

文字サイズ変更はレベルAAの達成基準

59

文字サイズ変更ボタンはなくてもいい!

もっと大切なことがある!

ひとことで言うと?

60

気づかないうちにアクセシビリティを確保していた!~実装・デザイン編~

アクセシビリティとは(おさらい)

さまざまな利用者がアクセス可能であること 情報を認識して理解できる

さまざまな選択肢が提供されている

自分に合った形で利用できる

62

2.1.4. ウェブアクセシビリティ対応に関する誤解

注意点!

ホームページ等において、音声読み上げ、文字拡大、文字色変更等の支援機能を提供する事例がありますが、これだけでは、ウェブアクセシビリティに対応しているとは言えません。

63

みんなの公共サイト運用ガイドライン (続き)

利用者は、多くの場合、音声読み上げソフトや文字拡大ソフトなど、自分がホームページ等を利用するために必要な支援機能を、自身のパソコン等にインストールし必要な設定を行った上で、その支援機能を活用して様々なホームページ等にアクセスしています。

64

ブラウザや支援技術でアクセスできることが

重要

つまり

65

重要なのは「マシンリーダビリティ」

アクセスできる! テキストが明確

ちゃんとマークアップされている

アクセスできない! テキストが存在しない、あいまい

ちゃんとマークアップされてない

66

実は大切なこと

1. ページタイトルをきちんとつける

2. 階層構造に沿った見出しをつける

3. 見た目に頼り切らない

4. 画像に頼り切らない

5. キーボードだけで操作できる

67

ページタイトルをきちんとつける

68

ページタイトルは重要な手がかり

ブラウザのタブ名

ブックマークのタイトル

表示履歴のタイトル

サーチエンジンやサイト内検索結果

外部からのリンク

69

OK: 内容が連想できるタイトルをつける

70

OK: ツールを使ってタイトルを確認する

71

NG: ページタイトルがない

72

NG: 他のページと区別できないタイトル

73

NG: 長すぎて肝心な部分が切られてしまう

74

階層構造に沿った見出しをつける

75

ユーザーは見出しに注目している

76

OK: レベルに沿った具体的な見出しをつける

77

OK: 見出しを見出しとしてマークアップ

78

NG: 見出しがない

79

NG: 見出しから内容を推測できない

80

NG: 見出しの階層が不適切

81

NG: 見出しがマークアップされていない

82

見た目に頼り切らない

83

視覚デザインは、見えないと伝わらない

配置

形・大きさ

文字の装飾

84

OK: 色だけでなくラベルに変化をつける

85

OK: 見た目の特徴だけでなくラベルで指示

86

NG: 色に頼った表現

87

NG: 色に頼った表現

88

NG: 配置に頼った表現

89

画像に頼り切らない

90

画像は利用できないことがある

画像が利用できない状況 画像が読み込めない

画像を表示できないブラウザを使っている

スクリーンリーダーを使っている

91

OK: 本文やキャプションで説明する

92

NG: 画像だけで情報が提供されている

93

代替テキストとは?

画像の代替となるテキスト 画像が表示できないとき、代わりに使われる

HTMLでは img 要素の alt 属性で指定

例: <img src=”foo.png” alt=”代替テキスト” />

94

文脈に沿った代替テキストとは

画像の「補足や説明」ではなく「代わり」 画像だけに着目すると失敗しやすい

前後の文や、ページのテーマを含めて考える

「alt属性値」が必ず必要なわけではない 必須なのは「alt属性」

本文がきちんとしていれば「カラ(alt=“”) 」「写真」「図」などが最適なケースも多い

95

OK: 装飾画像の代替テキストは空にする

96

OK: キャプションつきの写真に適切な代替を

97

NG: 装飾画像に説明文が指定されている

98

NG: 代替テキストとキャプションがかぶっている

99

NG: 画像の代替テキストが不適切

100

背景画像は伝わらないことがある

HTMLのimg要素は「内容」 代替テキストが設定できる

スクリーンリーダーやクローラーにも伝わる

CSSの背景画像は「装飾」 ハイコントラストモードや印刷プレビューで消える

スクリーンリーダーやクローラーには伝わらない

101

OK: 意味のある画像は前景に置く

102

NG: 意味を持つ画像を背景画像として実装

103

NG: ロゴやナビゲーションを画像置換で実装

104

Web Developer によるチェック

105

キーボードだけで操作できる

106

さまざまな入力

マウス、トラックパッド、トラックボール、マウスキー、代替マウス、タッチデバイス、キーボード、ソフトウェアキーボード、走査スイッチ、視線入力、音声操作、点字キーボード… …

107

OK: キーボードでも操作可能にする

108

OK: 切り替えボタンを明示する

109

OK: フォーカス表示をブラウザ標準にまかせる

110

NG: マウスクリックでしか操作できない

111

NG: マウスオーバーでしか操作できない

112

NG: スワイプでしか操作できない

113

NG: フォーカス表示が見えない

114

気づかないうちにアクセシビリティを確保していた!~設計編~

「適切なテキスト」のための設計

1. 内容を推測できるカテゴリ名にする

2. わかりやすい現在地表示をつける

3. リンク先がわかるようにする

4. フォームのラベルを明確にする

5. フォームのエラーを明確にする

116

内容を推測できるカテゴリ名にする

117

OK: 内容を推測できるカテゴリ名にする

118

OK: ルールと仕組みで一貫性を保つ

119

NG: カテゴリ名がわかりにくい

120

NG: ラベルがバラバラ

121

わかりやすい現在地表示をつける

122

OK: 一般的なわかりやすい現在地表示をつける

123

OK: 一般的なわかりやすい現在地表示をつける

124

NG: 現在地を把握する手段がない

125

NG: 現在地の表示と間違えそうな表現がある

126

注: コンテンツを邪魔しては意味がない

127

リンク先がわかるようにする

128

ユーザーはリンクに注目している

129

OK:リンクにリンク先のタイトルを加える

130

OK: 文中リンクを外に出して独立させる

131

NG: ラベルがないリンク

132

NG:「こちら」リンク

133

NG: 「もっと読む」「詳細」リンク

134

フォームのラベルを明確にする

135

OK: 具体的で明確なラベルをつける

136

OK: 必須項目を明確にする

137

OK: 必要に応じて説明をつける

138

OK: プレースホルダをラベル代わりにしない

139

NG: ラベルや説明があいまいで混乱する

140

NG: 必須か任意かがわからない

141

NG: 必要な説明がなく、入力の条件がわからない

142

NG: ラベルがなく、入力欄が何なのかわからない

143

フォームのエラーを明確にする

144

OK: エラー箇所を明確に示す

145

OK: エラー表示と修正フォームをセットにする

146

OK: エラー理由と修正方法を明示する

147

NG: エラー箇所がわからず修正できない

148

NG: エラー表示画面と入力画面がわかれている

149

NG: エラーメッセージが理解できず修正できない

150

気づかないうちにアクセシビリティを確保していた!~企画・要件編~

プロジェクトの最初から「アクセシビリティを

どうするか?」を決めておくべし

ちゃんとやるには「アクセシビリティ方針」

152

方針がないと……

153

方針がないとどうなる?

配慮が全く行われない 公開に実は必要だったとなっても後の祭り

適切な判断ができない 判断がぶれる、人によって判断が異なる

合意形成ができない、覆る プロジェクト内、あるいはクライアントとの衝突

154

まずは最低限の方針を立てよう

155

Webアクセシビリティ方針とは?

156

JIS X 8341-3:2016 附属書JA

JA.1 企画

企画段階においてウェブページ一式の責任者は,ウェブアクセシビリティ方針を策定する。策定したウェブアクセシビリティ方針は,ウェブサイトではサイト上,ウェブアプリケーションではマニュアルなどで公開するとよい。

157

方針策定ガイドライン

158

難しそう!159

定めるべきことは意外に少ない

必須項目 対象の範囲 (サイトのURLなど)

適合レベル及び対応度 (レベルAA準拠、など)

その他、定めると良い項目 達成までの期限、例外事項、追加の達成基準、

担当部署、現時点での問題点への対応など

160

実はやっていた!

161

アクセシビリティについては

「JIS X 8341-3:2010」に準拠すること。

達成等級は以下の通り:

達成等級AA 準拠

162

実例

方針策定のコツ

163

無理のない範囲で

164

明確に定める

ガイドラインに沿って目標とするレベルを決める 特にアクセシビリティが重要ならレベルAA

適用範囲、期限などをはっきりさせる 基本的にはサイト全体、公開時に対応でよい

例外ができてしまう場合は明確にする

165

各種ガイドラインを参考に

制作プロセスに関するガイドライン ウェブアクセシビリティ方針策定ガイドライン

JIS X 8341-3:2016 対応発注ガイドライン

JIS X 8341-3:2016 試験実施ガイドライン

※「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン」は「準拠」の表記に関するもので、これら全てに関連する

166

方針があればそれでいいのか?

方針があっても、適切でないものだと効果を発揮しない あいまいな方針を立ててしまう

誤解に基づいて方針を立ててしまう

手段が目的になってしまう

167

実際にあったこんな要件

168

あまり良くない例

あいまいな方針を立ててしまうケース

169

170

セキュリティ、Web標準、

アクセシビリティに配慮し

制作すること。

実例

勢いはあるが……

具体的に何をどうすれば良いのかからない 「配慮する」といっても人によって基準がまちまち

171

172

アクセシビリティについては

「JIS X 8341-3:2010」に

準拠すること。

実例

JISに沿うことはわかるが……

目標とするレベルが不明 たとえばAAの達成基準を

満たすべきなのかどうかわからない

173

誤解に基づいて方針を立ててしまうケース

174

175

文字拡大機能

ブラウザの機能ではなく、

ページ上のボタンをクリックすることで

CSS を切り替え処理等により容易に

文字サイズを変更できるようにすること。

サイズについては3サイズ程度

選択できるようにすること。

実例

その結果

176

手段が目的になってしまうケース

177

178

以下ランキング同業種内1位評価獲得

• 全上場企業ホームページ充実度ランキング調査

• IRサイト総合ランキング

• 主要企業Webユーザビリティランキング

• インターネットIR表彰

実例

ランキング対策の「アクセシビリティ対応」

179

実際にあったこんな要件

180

なかなか良いと思える例

アクセシビリティについては

「JIS X 8341-3:2010」に準拠すること。

達成等級は以下の通り:

達成等級AA 準拠

181

実例

表記ウェブアクセシビリティ方針の提示又は公開

目標とする適合レベルの達成基準の試験結果

追加表記事項

準拠 必須試験を実施し、達成基準を全て満たしていることを確認

なし

一部準拠 必須試験を実施し、達成基準の一部を満たしていることを確認

今後の対応方針部分適合に関する記述(適用する場合)

配慮 必須 試験の実施の有無、結果は問わない

目標とした適合レベル又は参照した達成基準一覧

ただし…… 「準拠」の意味、分かっていますか?

182

アクセシビリティ、

ユーザビリティについて、

弊社のレベルを考慮いただき

準拠基準をご提案ください。

183

実例

「 JIS X 8341-3:2010」 の「等級A」への

準拠を検討しているが、本方針は

要件定義工程でのWEBサイト検討状況を

踏まえ決定する想定です。

アクセシビリティ方針の検討方法についても

ご提案ください。

184

実例

制作と合わせて方針の提案も求められるケース

185

ウェブアクセシビリティ方針策定ガイドライン

JIS X 8341-3:2016 対応発注ガイドライン

提案書作成

RFP作成

制作と合わせて方針の提案も求められるケース

方針や策定プロセスも一緒に考えればよい あいまいに書くよりも、ずっと良いアプローチ

受注側の力の見せどころ

186

目的もドキュメント化しよう

187

ヤフー株式会社 ウェブアクセシビリティ方針

188

目的もドキュメント化しよう

なぜアクセシビリティに取り組むかを明文化 何のためのアクセシビリティなのかを押さえる

公開されている他社の方針を参考にするのも良い

ただし、意味も分からずにコピペはNG

目的が明確になると、手段と目的の混同を避けられる 「基準を満たすこと」は最終目的ではないはず

189

「基準を満たすこと」が目的になると……

190

注意を要する要件

191

注意を要する要件

アクセシビリティ方針が明確にできても、その方針を守ることができるかは別の話

サイトに求められる要件の中には、注意が必要なものもある アクセシビリティが確保できないもの

アクセシビリティ確保のためにコストがかかるもの

192

CAPTCHA

193

ブラウザやOSの機能への干渉

194

動画

195

紙媒体用のコンテンツ

196

方針があると?

方針を前提にすることで、要件の可否を判断することができる アクセスできなくなるような要件を入れない

コストがかかりそうな要件があるときはコストを見積もっておくことができるようになる

これらは後からの対応ではどうにもならない

197

まとめ

文字サイズ変更ボタンはなくてもいい!

さらにもっと大切なことがある!

もう一度

199

実装で重要なのは「マシンリーダビリティ」

アクセスできる! テキストが明確

ちゃんとマークアップされている

アクセスできない! テキストが存在しない、あいまい

ちゃんとマークアップされてない

200

設計や企画時の配慮も重要

わかりやすいテキストを設計しよう わかりやすいラベルは誰にとっても有用

ナビゲーションやリンクやフォームの設計時に少し気をつけるだけでグッと良くなる

方針を立ててみよう 何のために、何を、どこまでやるのか?

製作の前(発注前、提案時、受注後)に考えよう

201

どのプロセスにもポイントがある

実は「設計」が重要 テキストが存在しなければマークアップできない

さらに「戦略」「要件」も重要

最初から考えないと、あとで大変になる

202

Webに関わるどんな人にもできることがある

Webに関わる全ての人に関係がある

203

何かを付け足すのではなく当たり前のことを

真っ当にやることが重要

実は特別なことではない

204

さあ、はじめよう!

205

デザイニングWebアクセシビリティ

206

ありがとうございました