Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」
基調講演「Webエンジニアとしていま知っておきたいWebアクセシビリティ」
freee株式会社 デザイナー/エンジニア ymrl さん
ウェブアクセシビリティとは何か？
・アクセシビリティ：あらゆる状況で誰にとっても使えること
状況を狭く限定して、使いやすさを深く追求する
・ユーザビリティ：特定の状況で特定のユーザーにとって使いやすいこと
状況を広げることを追求する。使いやすさには比重を置いていない
例えばスマホ最適化
・あるWebサービスをスマートフォンに最適化したビューでも提供する
→ レスポンシブなレイアウトの提供
・そのおかげでいろんな人にメリットがある
→ 既存ユーザー：外出先で使える
→ PCを使わない層が使いやすくなり、新たなユーザー獲得ができる
→ 弱視のユーザーも使いやすく
使い手目線と作り手目線
・想像しやすさから使い手目線での説明がされるが誤解を生みやすい
→ 障害者や
・使い手目線：この人がこのWebサービスを使えないのはかわいそう
→ 倫理感頼り、メリットが小さく見える
→ 個別対応で考える方向に誘導してしまう
・作り手目線：このWebサービスをみんなに使ってもらえるようにする
→ ユーザーが増えたり便利になるという具体的なメリットが見える
→ 全体的に考えてベストな方法を模索する必要がある
Webアクセシビリティを加点法で考える
・Webアクセシビリティは減点法で捉えられがち
→ やってないと特定ユーザーに怒られる
→ 完璧にしておかないといけない
→ 特別なターゲットに対して特別なことをする
・加点法でとらえるWebアクセシビリティ
→ やることですべてのユーザーを幸せにできる可能性
→ やればやるほど品質が上がる
→ すべての人に選択肢を与える普遍的なもの
受託政策の視点でWebアクセシビリティが語られていることが多い
→ 要件定義からのトップダウンのアプローチ、減点法になりがち
自社サービスのアクセシビリティに取り組む会社が増えている
→ 改善が続く。段階的に取り組んでいける
Webアクセシビリティでよく意識されるもの
ウェブアクセシビリティはすべてのひとのためのものだが、よく意識されるターゲットは存在する
・視覚障害（見えない／見えにくい）：全盲／弱視
・色覚多様性（色の見え方が異なる）：色覚異常／色弱／色盲
・上肢障害（マウス操作がしにくい）：手や腕が不自由、操作に不慣れ
・聴覚障害（音声が聞こえない／聞き取りにくい）
・一時的な障害：メガネの故障、骨折、機器の故障など
WCAG（Web Contents Accessibility Guideline）
・2.0がそのままISOやJISになっている
・達成レベルはA〜AAAが設定されている
WAI-ARIA
HTLMで表現できる範囲を逸脱したUIを作る時、支援技術にどんなUIなのかを伝えるHTML属性
組織のアクセシビリティ方針
・Webサイトごとにどこまで対応するかの基準を決めることが大事
・内閣府の例
→ WCAG2.0レベルA、AAに準拠
→ レベルAAAは達成可能な範囲で
→ 方針策定前、外部由来のもの対応が難しいものは例外として定義
公開されている組織独自のガイドラインを参考にする
・Ameba
・freee
・三井住友銀行
Webアクセシビリティの検証ツール
・aXe、Lighthouse
・eslint-plugin-jsx-a11y、eslint-plugin-vue-a11y
・Visible、acot
・エラーが出ないから完璧というわけではない
法的な制約
・欧米ではWebアクセシビリティへの取り組みは義務
・日本では必要かつ合理的な配慮が努力義務
→ 義務となるような法改正の動きもある
エンジニアから始めるウェブアクセシビリティ
・難しい
→ 想像力を必要とする
→ ガイドラインが膨大で難しい
・横断的な知識が必要
→ 企画からデザイン実装まですべてに関係する
→ 職種ごとに最適化された形で整理されていない
・すべての関係者が一丸となって取り組んでいるのが理想
・エンジニアがリードするべき
→ 実装に近いので改善サイクルを回しやすい
→ 非機能要件として取り入れやすい
・できるところから始める
→ レベルA相当のものは既に達成できていたり、すぐ対応できるものがあるはず
→ Lighthouseのスコアをとって、ちょっとずつ改善してみる
・エンジニアの理解／協力を得る
・エンジニア意外にも広める
セッション1「これからもつづけるWebアクセシビリティ」
株式会社クラウドワークス フロントエンドデザイナー yamanokuさん
知ってみる
・よく使っているサービスはアクセシビリティ対応されてる？
→ Twitter、Slack、Zoom・・・
・どういうものがアクセシブルなのか？
→ 逆説的によくないサンプルを見る（ex：体験サイト
チェックしてみる
・Lighthouse、aXeなどのツール
・WCAGの達成基準
・企業のガイドラインを参考にして比べてみる
対応してみる
・健全なマークアップをこころがける
・＋WAI-ARIAを利用する
・機械的なテストを実施する
→ 静的解析ツール
・アクセシビリティサポーテッド情報を参照する
情報を収集する
・A11YJ on Slack
・accrefs
・アクセシビリティBlog
・辻ちゃん・ウエちゃんのAccessiブルGoGo!
念頭に置くこと
・お願いベースでは進まない
・対応を強いるのではなく、一緒にやる
・「すべて」にこだわらず、簡単なところから改善していく
セッション2「実践！Reactで学ぶアクセシビリティ」
未踏ジュニアスーパークリエータ 五十嵐 涼さん
・altに形容詞を一つ入れるとなんかよさげ
・アクションをさせる要素をdivにしない
・buttonにアイコン画像だけの時はアイコンに説明をつける（aria-label）
・headerやmainなどの要素、見出しはスクリーンリーダーでスキップなどの機能を使える
・言語設定をしておかないと支援技術側の言語設定と異なった場合に正しく読み上げられないことがある
・SPAなどではページ切り替えで、どのページに遷移したかがわからない場合があるので、フォーカスをbodyやmain、最初に見出しなどに当ててあげると良い
・モーダル開閉のときのフォーカス移動も注意
・React-testing-libraryと相性が良くテストも書きやすくなる