「公的機関ウェブ担当者のためのアクセシビリティセミナー」で基本をおさらい

2020年6月4日 21:06

公的機関のウェブ担当なんてやったこともやる予定もないけど、基準の一つではあるかな、ってことで「公的機関ウェブ担当者のためのアクセシビリティセミナー」を受講してみました。

セッション1は2020年4月28日に開催されたセミナーの「これでわかる！ウェブアクセシビリティって？ JIS-X:8341-3って？」の動画視聴。

そもそもウェブアクセシビリティとは？最近のアクセシビリティ事情とは？ウェブアクセシビリティの規格である JIS X 8341-3:2016 の概要やその進め方など、基本知識をまるっとおさらいです。

ウェブアクセシビリティって？

ウェブページにある情報や機能の利用しやすさ。
さまざまな利用者がさまざまなデバイスを使ってウェブを使う時、そのさまざまな状況に対応できているということが、ウェブコンテンツの品質には必要不可欠である。

HTMLが適切にマークアップされていれば、みることができなくても正しく利用することができる
・文章構造が正しい：見出しなど
・画像の代替テキストが適切である：画像の内容を過不足なくを説明する
・リンクテキストが適切である：指示語ではなく具体的である
・キーボード操作ができる：キーボード操作を阻害しない

見えにくい
・色のコントラスト
・動きのあるコンテンツ
・変化するコンテンツ
・表示サイズの可変
・制限時間／タイミング
→　拡大していると見えない、気がつかない
→　拡大すると表示が崩れる

聴こえない／聴こえづらい
・音声付き動画／コンテンツ
→　キャプションなど、代替テキストを用意する

動かせない
・マウスでしか操作できない
・hoverで変化する
→　代替する操作を用意する
→　フォーカス順序が正しい
→　フォーカスインジケータが非表示
→　入力の制限時間
→　ボタンやリンクのサイズ

アクセシビリティを提供する＝「できない」をカバーするだけではなく、選択肢が多いことで利用者の状況にあった利用ができるようになる。
障害の有無にかかわらず、老化や怪我、環境などによって「つかいにくい」状況はありうる。

利用者体験の土台になるものベースが「アクセシビリティ」

「できない」「しづらい」状況だと・・・

・必要な人に情報を届けられず、サービスを平等に届けられない
・法的責任を果たせない
・ブランド価値を損ねる
・顧客満足度が下がる

ウェブアクセシビリティの誤解

・障害者のためだけに特別なことをする
　→　特定ユーザーのための特別な対応ではない
・ターゲットユーザーに高齢者や障害者がいないので必要ない
　→　一時的なもので「使いにくい」状況が生まれることはある
　→　使われ方は千差万別である
・いろいろなボタン／機能を提供しなければならない
　・文字サイズ変更ボタン
　・文字色／背景変更ボタン
　・音声読み上げ機能
　→　ボタンや機能は必須ではない
　→　利用者が自分で対応できることを阻害しないことが重要
・デザインの見た目がつまらなくなる
　→　コントラスト比などの対応を考慮すると制限はある
　→　「見やすさ」を犠牲にしなければならない意義があるかどうか
・膨大なコストと時間がかかる
　→　タイミングややり方によってはコストを抑えられる
　→　できることからでも始めることが大事

何をどこまでやればいいのか？

ガイドラインを目安にする
・諸外国では「WCAG2.0 」を技術基準として採用
・「WCAG2.0」はISO/IEC規格として2012年に承認
・2016年、JIS規格はISO/IECと一致した内容に改訂

WCAG2.0　＝　ISO/IEC 40500:2020　＝　JIS X 8341-3:2016

61の達成基準、3つのレベル

あらゆる障害のニーズを踏まえてウェブコンテンツが満たすべき品質基準
・レベルA：25の達成基準
　アクセシビリティ確保に最低限の対応
　ユーザーが設定を変えることで対応できることを阻害しないレベルのもの
　これが達成されていないとまったく使えないユーザーがでてきてしまう
・レベルAA：13の達成基準
　諸外国では公的機関に要求されている
　日本では総務省が公的機関に推奨している
　多くの人が使いやすくなる
・レベルAAA：23の達成基準
　可能なものがあれば対応すると良い
　特定コンテンツにしか適用できない項目を含む
　レベルAAAを目標とすることは推奨されていない

達成基準を満たすメリット

・多くの人が使いやすくなり、ユーザー満足度が上がる
・利用者全体の使いやすさが向上する
・検索エンジン最適化にもプラスになる
・新しいデバイスにも対応しやすくなる

進め方

方針を決める：対応する範囲、目標とするレベルと対応度
↓
対応範囲で対応を進める
↓
試験を実施する
↓
試験結果を公開する

多くの場合「供給者適合宣言」は困難。
できることをできる範囲だけでも少しずつでも対応することが必要

質疑応答

画面を拡大してみている人の環境をどのように確認するか
→　OSの拡大表示／ブラウザの拡大表示／画面幅が狭い状態／文字サイズのみを大きくした状態はそれぞれ別物。それぞれの状態を別物として確認すると良い
→　ガイドラインとして第一優先はブラウザの拡大表示に対応すること
→　画面に対して位置固定しているコンテンツがあると問題が起こりやすい
→　さまざまなやりかたをしている人がいるので、いろいろ試してみることが大事

すべてのページを対応するのが難しい場合、一部だけでも対応すべき？どこを優先すべき？
→　部分的にでも対応した方が良い
→　ユーザーにとって重要度が高く、アクセスが多いページを優先する
→　ウェブサイトで完結させることだけに固執せず、困ったときに電話で問い合わせができるなど別の手段を提供することも考慮すると良い
→　対応に対して不完全でも対応ができるのであればツールを用いるなどして対応方法も柔軟に検討すると良い

コンテンツ運用時に注意する点。CMS構築時に注意すべきこと。
→　運用していく中で維持する／改善していくことは重要
→　しかしドキュメントはあまりない
→　ケースごとに教材が用意されていることがある
自治体などではウェブ担当者向けの教材などが公開されているので参考にできるかも
→　対応時と運用時に守ることはほぼイコールなので、対応時の基準をマニュアルとして整備して提供すると良い
→　システムと手動を区分けをする
→　自動化できるところは自動化する
→　コンテンツエリアのマークアップを維持できるようなブロックを提供するなど
→　公開時にチェッカーをかける
→　既存でアクセシブルを謳っているものを選定／利用する
→　基準を満たすワークフローを整備する
→　コンテンツ作成時のとりかかり時から基準を意識できるようにする

試験をする際に試験者の解釈や判断にズレが生じた場合は？
→　試験については試験者の判断に委ねざるを得ない
→　試験結果の公表が推奨されているので、それによってユーザーのフィードバックが期待できる
→　第三者的な期間は存在しない

コンテンツの整合性を担保する指針はあるか？
→　ウェブアクセシビリティの範囲ではなさそう
→　運営者に整合性がとれていないことを教えてあげると良いのでは
→　運営側はそのような意見を受け取れる場所を用意すると良い

試験実装項目リストとして広く普及しているようなものはあるか？
→　waic.jpの実装チェックリストをカスタマイズして使うことをWAICでは推奨
→　アクセシビリティサポーテッドに準拠しているかは別途確認すべき

代替テキストとは
→　画像を説明したり補足するテキストではない
→　その文脈において「画像が伝えたいこと」を過不足なく伝えるためのテキスト

デザイナーにアクセシビリティの重要さを啓蒙するやり方は？
→　なんのためにそのデザインをするのか
→　ウェブで広く情報を伝えるために何をすべきか
→　重要性ややり方、考え方を勉強会としてやってみる
→　デザインの方が重要性が高いのであれば、それを利用できない人をどう考えるかを検討すればよい。バランスが大事
→　アクセシビリティとデザインが両立できる方法を伝える
→　食わず嫌い的なところはありそう

よりユーザーのリアルに近い現状や数値根拠を示す資料はあるか
→　障害者の情報支援技術利用の統計
→　高齢者割合＋インターネット利用率／スマホ利用率
→　研究者は存在するので論文なども見つかる
→　TwitterなどのSNSでスクリーンリーダーユーザーの情報交換などもウォッチできる

画像とそれを伝えるテキストが隣り合っている場合は？
→　altを空でマークアップするとよい

ガイドラインを満たしてもアクセシビリティ的に使えないということはあるか？
→　ユーザーの環境や能力によってはある
→　対応していればそうならない確率が上がる、ということ

当事者へのテストが難しい場合はどうテストする？
→　当事者でなくても同じツール／環境を再現すればある程度はテストできる
→　ユーザー環境に左右されることは理解しておく
→　公開後にフィードバックを受けられる窓口を設けておき、真摯に対応する

アクセシビリティの前に、どんな人が、どんな風にサイト／サービスを使うのかを知ることが大切。つくり手はユーザーではない。ユーザーテストなどのプロセスを取り入れると良い。

発注側の立場として、アクセシビリティを向上させるための指針はあるか？
→　みんなの公共サイト運用ガイドライン

チェックのための自動ツールはあるか？
→　いろいろあるが自動チェックツールでチェックできる範囲は狭い
→　例えばalt属性があるかどうかはチェックできても、値が正しいか？などはチェックできない
・miChecker
https://www.soumu.go.jp/main_sosiki/joho_tsusin/b_free/michecker.html
・Chrome拡張Axe
https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd
イラレやPhotoShop、XDにもそれを確認できる機能やプラグインが提供されている