Webエンジニアとして いま知っておきたい Webアクセシビリティ

Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 基調講演
https://forkwell.connpass.com/event/198726/

Google Slides: https://docs.google.com/presentation/d/1uhCvhh6sZCPUnReSBVDjvGfNAOTKbZ5Sxs8fYMlxMsI/edit?usp=sharing

2. • ymrl（やまある） • freee株式会社 • フロントエンドエンジニア兼UIデザイナー • freeeの社内向けデザインシステムを作る（デザイン・実装・運用）傍ら、 Webアクセシビリティの向上施策や社内教育をしています
3. • エンジニアの視点でWebアクセシビリティを捉えなおす ◦ エンジニアに特化したWebアクセシビリティの情報が意外と少ない ◦ エンジニアにはWeb技術のエキスパートとしての視点がある • エンジニアの立場でのWebアクセシビリティへの向き合い方の話 ◦ 「いつかやらなきゃいけないと思っているんだけど」への回答 ◦ 明日からWebアクセシビリティに取り組み始められるようにする
5. （英: accessibility）とは、近づきやすさやアクセスのしやす さのことであり、利用しやすさ、交通の便などの意味を含む。国立国語研究所 「外来語」委員会は日本語への言い換えとして「 」を提案している [1][注釈 1]。 アクセシビリティ - Wikipedia https://ja.wikipedia.org/wiki/アクセシビリティ
6. 一般にアクセシビリティとは、アクセスのしやすさを意味します。転じて、製品やサービスの利用しやすさという意味で も使われます。 似た意味をもつ言葉にユーザビリティがありますが、アクセシビリティはユーザビリティより幅広い利用 状況、多様な利用者を前提とします。 ウェブのアクセシビリティを言い表す言葉がウェブアクセシビリティです。ウェブコンテンツ、より具体的にはウェブ ページにある情報や機能の を意味します。 さまざまな利用者が、さまざまなデバイスを使い、さまざまな状 況でウェブを使うようになった今、あらゆるウェブコンテンツにとって、ウェブアクセシビリティは必要不可欠な品質と 言えます。 アクセシビリティとは（ウェブアクセシビリティ基盤委員会） https://waic.jp/knowledge/accessibility/
7. • アクセシビリティ = 利用しやすさ？ • ユーザビリティ = 使いやすさ？ • ？？？？
8. • : 特定の状況で、特定のユーザーにとって使いやすいこと ◦ 帰宅途中の会社員が電車の中でスマートフォンで読みやすいニュース ◦ 料理中に手が濡れたままでも次の手順を確認できるレシピ ◦ • : あらゆる状況で、誰にとっても使えること ◦ スマートフォン専用ではなく、タブレットやPCでも使える ◦ 料理中だけでなく、買い物に出て献立を決めるのにも使える ◦
9. • 障害者・高齢者のためだけのもの • 一般のユーザーには関係ない
10. • あるWebサービスを、スマートフォンに最適化したビューでも提供したい ◦ レスポンシブなレイアウトを提供する • そのおかげでいろんな人にとって良いことがある ◦ 既存のユーザーは外出先で使ったりできるようになった ◦ PCを使わない層にも使いやすくなり、新たなユーザーを獲得できた ◦ 画面を拡大して使う弱視のユーザーにとっても使いやすくなった • アクセシビリティは
11. • 想像しやすさから使い手目線での説明がされるが、誤解を生んでしまう • この人がこのWebサービスを使えないのはかわいそう ◦ 倫理感頼り、メリットが小さく見える ◦ 個別対応で考える方向に誘導してしまう • このWebサービスをみんなに使ってもらえるようにする ◦ ユーザーが増えたり便利になるという具体的なメリットが見える ◦ 全体的に考えてベストな方法を模索する必要がある
12. • Webアクセシビリティは減点法で捉えられがちだった ◦ やってないと特定のユーザーに怒られるもの ◦ 完璧にしておかないといけないもの ◦ 特別なターゲットに対して特別なことをするもの • 加点法で捉えるWebアクセシビリティ ◦ やることですべてのユーザーを幸せにできる可能性があるもの ◦ やればやるほど品質が上がるもの ◦ すべての人に選択肢を与える普遍的なもの
13. • 受託制作の視点でWebアクセシビリティが語られていることが多かった ◦ リリースがゴール。要件に入っているとやってないと怒られる ◦ 要件定義からのトップダウンのアプローチ、減点法 • 日本国内で、自社サービスのアクセシビリティに取り組む会社が増えている ◦ クラウドワークス、サイバーエージェント、サイボウズ、GMOペパボ、 SmartHR、Chartwork、freee、弁護士ドットコム、READYFOR、など ◦ リリース後も改善が続く、段階的にアクセシビリティを高められる ◦ 現場からのボトムアップのアプローチが可能、加点法
14. • 誰かのための特別な対応ではなく、すべての人に向けた普遍的な改善 • 段階的に改善していき、常に高めていく努力をしていくもの
16. • Webアクセシビリティはすべての人のためのもの • しかし、特に意識されるのは障害者・高齢者が抱えているハンディキャップ • 次のスライドから具体的なハンディキャップの例を挙げますが、 あくまで意識されるものの一例であることに注意してください
17. • 全盲の人も、スクリーンリーダー等の支援技術を駆使してWebを利用する ◦ 画面の内容を読み上げ、音声や点字で認識することができる ◦ キーボードを使って操作する • 弱視（ロービジョン）の場合、見えやすさが人によって異なる ◦ 画面を拡大し、色を反転させたり調整したりする ◦ 視覚障害者のなかでは全盲よりも数が多い 点字ディスプレイとキーボードを使用してラップトップを操作している様子 （画面を見る必要がないので、ラップトップを閉じている） freeeのアクセシビリティ。できないことができる世の中に https://jobs.freee.co.jp/recruitblog/aboutus/freee_eng_accessibility/
18. • 色の見え方は人によって異なっている • 遺伝的な理由で特定の色の見分けがつきにくい人は多い ◦ 日本人男性の約5％が先天性赤緑色覚異常といわれてる • 色だけに頼るかたちで情報を表現しているものが読み取りづらい ◦ 成功と失敗を緑と赤で表現しているなど 実際の写真（左）と、1型2色覚（中央）・2型2色覚（右）の 見え方を再現したもの 映っているUNOのカードはドロー4、緑7、黄8、赤2、青4 色覚異常者の色の見え方（滋賀医科大学 眼科学講座） http://www.shiga-med.ac.jp/~hqophth/farbe/miekata.html
19. • 手や腕に障害があったり、寝たきりであったりするとマウスを使いづらい ◦ 全く使えなかったり、細かい作業が苦手だったりする ◦ ドラッグ＆ドロップやマウスホバーによる表示がやりづらい • マウス操作に慣れてない場合にもやはり細かい操作がしづらくなる • キーボードで操作できれば使える可能性が高まる ◦ キーボードは指以外でも操作することができるが、マウスは難しい
20. • 動画や音声が埋め込まれている場合、音声が聞けない場合の考慮が必要 ◦ 字幕を表示する・手話通訳をつける・書き起こしを提供する • ライブ動画の場合も、機械認識で字幕をつけたりすることができる 東京都知事の会見映像配信は、UDトークによる文字おこしが提供されている 【シェア希望】都知事の会見にUDトークで字幕がつきます！ https://udtalk.jp/post-3837/
21. • ここまで紹介したものは自分に関係ないように思われてしまうかもしれない • 一時的に、ふだん使える身体機能や入力装置が使えなくなることもある ◦ コンタクトレンズを紛失した、メガネが壊れてしまった ◦ スノーボードで両手首を骨折した ◦ 無線マウスやキーボードの電池が切れた ◦ イヤホンが無いので動画の音を出せない ◦ スマホの「ギガ」が切れたので動画を見ることができない
22. • 様々なハンディキャップをすべて把握しながらWeb開発するのは難しい • 統一的なガイドライン: WCAG (Web Contents Accesibility Guildelines) ◦ 原文 https://www.w3.org/TR/WCAG21/ ◦ 日本語訳 https://waic.jp/docs/WCAG21/ • 関連文書にある解説書を一緒に読むのを推奨（ガイドライン本文が難しい） ◦ 原文 https://www.w3.org/WAI/WCAG21/Understanding/ ◦ 日本語訳 https://waic.jp/docs/WCAG21/Understanding/
23. • 前バージョンの2.0がそのままISOやJISになっている ◦ 後方互換性があるので、WCAG 2.1に準拠すればISOやJIS準拠となる • 「達成基準」にそれぞれ「レベルA」から「レベルAAA」が設定されている ◦ レベルAは致命的な問題となる、レベルAAAは達成の難易度が高い • 現在、WCAG 2.2 や WCAG 3.0 の策定作業が進んでいる ◦ WCAG 3.0では色のコントラスト比の計算が大きく変わりそう ◦ その内容については 2021年のWebアクセシビリティ という記事を参照 https://gihyo.jp/design/column/newyear/2021/web-accessibility-prospect
24. • もともとHTMLで表現できる範囲を逸脱したUIを作るとき、 スクリーンリーダー等の支援技術にどんなUIなのかを伝えるHTML属性 ◦ 「これはコンボボックスで、こういう選択肢を選択している」 ◦ 「<div>で作ってあるけどここは<td>みたいなやつです」 • WAI-ARIAの実例は WAI-ARIA Authoring Practicesを参照するのがよい ◦ 原文 https://www.w3.org/TR/wai-aria-practices-1.1/ ◦ 日本語訳 https://waic.jp/docs/2019/NOTE-wai-aria-practices-1.1-20190207/
25. • WCAGのAAAまでの達成基準をすべて満たすのは、ほぼ不可能 • Webサイトごとに、どこまでやるかの方針を明確にしておく • 内閣府の例 https://www.cao.go.jp/notice/accessibility_guidelines.html ◦ JIS X 8341-3:2016 (WCAG 2.0) のレベルA, レベルAAに準拠 ◦ 一部のレベルAAA達成基準は可能な範囲で対応 ◦ 方針策定前のコンテンツ、外部由来のもの、PDFやExcelファイルなど、 対応が難しいものを例外として定義
26. • WCAGの文章が難しく、現場レベルで使っていくのは難易度が高い • 方針だけでなく、WCAGベースでガイドライン自体を作って運用する • 日本国内では、Ameba と freee のガイドラインが公開されている ◦ Ameba https://openameba.github.io/a11y-guidelines/ ◦ freee https://a11y-guidelines.freee.co.jp/ • そのまま自社のWebアクセシビリティ方針として取り込んでも良い （とても嬉しいので、もしfreeeのガイドラインを採用してくれる会社があったらぜひ教えてください）
27. • aXe, Lighthouse ◦ aXeは定番チェックツール。axe-coreとしてCIに組み込んだりもできる ◦ LighthouseはChromeに搭載されている。スコアとして見せてくれる • eslint-plugin-jsx-a11y とか eslint-plugin-vue-a11y • 新しく出てきたツール Visible, acot • いずれのツールでも、エラーが出ないから完璧というわけではないので注意
28. • 欧米では法律で、Webアクセシビリティに取り組むのは義務になっている ◦ 米国では年間2000件を超える訴訟が起きている ◦ グローバル展開するのならWebアクセシビリティは必須 • 日本の障害者差別禁止法では、必要かつ合理的な配慮は努力義務 ◦ 罰則規定はないが、努力する義務がないわけでもない ◦ もうすぐ義務となるよう法改正が行われる動きもある 障害者差別解消法 改正法案提出を検討（福祉新聞） https://www.fukushishimbun.co.jp/topics/25305
30. • 想像力を必要とする ◦ Webサービスを使おうとしている障害者や高齢者が身近にいない ◦ WCAGを読めばいいはずだが、量が大くて文章が難解 • 横断的な知識が必要 ◦ 企画からデザインから実装まで、すべてに関係してしまう ◦ 職域ごとに最適化されたかたちで整理されていない
31. • すべての関係者が一丸となってWebアクセシビリティに取り組んでいる ◦ 全員で統一されたWebアクセシビリティ方針をもっている ◦ 全員がそれに従って作業をすることができている • 現実には難しい ◦ Webアクセシビリティ方針を作るには深くて広い理解が必要 ◦ さらにそれを組織全体に浸透させられていなければならない
32. • エンジニアはWeb技術のエキスパート ◦ クライアント・ディレクター・デザイナーよりWeb技術に詳しい ◦ 実装物に最も近く、改善サイクルを回しやすい • パフォーマンスやコードの保守性と同じような非機能要件 ◦ 技術への深い理解や現場の肌感覚がなければ基準を決めたりできない ◦ 非技術者がトップダウンで基準を決めるのが難しい
33. • AmebaやfreeeのガイドラインでWCAG A相当の項目を読み、勘所を掴む ◦ Amebaは項目の横にレベルが記載、freeeは[MUST]がA相当 ◦ 既に達成できているものや、すぐ達成できるものを発見できるはず • Lighthouseスコアを取ってみる ◦ 最初は主要な画面やユーザー登録フローだけでいい ◦ 自動化したりもせず、手作業でブラウザで取ればいい ◦ すこしずつ修正して、まずは上げられるところまでスコアを上げる
35. https://web.dev/frame-title/
36. • Resources のリンクから Deque University へ移動 • WCAGの達成基準の番号がある • 日本語のドキュメントの対応箇所を読む ◦ WCAG の日本語訳 ◦ Ameba や freee のガイドライン https://dequeuniversity.com/rules/axe/3.3/frame-title
37. • エンジニアの理解・協力を得る ◦ Pull Requestのレビュー時にaXeの結果やLighthouseスコアを貼る ◦ Lighthouseスコアを定期的に記録し、トラッキングできるようにする ◦ 機械的に判定できない項目を人の手で判定・修正していく • エンジニア以外にも広める ◦ ビジュアルデザインやコンテンツをエンジニアで頑張るのは難しい ◦ ガイドラインを読み解き、組織に適用しやすい基準をつくる
38. • Webアクセシビリティを普遍的な品質の要素として捉え、加点法で評価する • エンジニアこそWebアクセシビリティをリードできる立場にある • エンジニアからボトムアップで方針を定め、すこしずつ改善できる