Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ymrl
January 13, 2021

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

ymrl

January 13, 2021
Tweet

More Decks by ymrl

Other Decks in Technology

Transcript

  1. • : 特定の状況で、特定のユーザーにとって使いやすいこと ◦ 帰宅途中の会社員が電車の中でスマートフォンで読みやすいニュース ◦ 料理中に手が濡れたままでも次の手順を確認できるレシピ ◦ • :

    あらゆる状況で、誰にとっても使えること ◦ スマートフォン専用ではなく、タブレットやPCでも使える ◦ 料理中だけでなく、買い物に出て献立を決めるのにも使える ◦
  2. • 全盲の人も、スクリーンリーダー等の支援技術を駆使してWebを利用する ◦ 画面の内容を読み上げ、音声や点字で認識することができる ◦ キーボードを使って操作する • 弱視(ロービジョン)の場合、見えやすさが人によって異なる ◦ 画面を拡大し、色を反転させたり調整したりする

    ◦ 視覚障害者のなかでは全盲よりも数が多い 点字ディスプレイとキーボードを使用してラップトップを操作している様子 (画面を見る必要がないので、ラップトップを閉じている) freeeのアクセシビリティ。できないことができる世の中に https://jobs.freee.co.jp/recruitblog/aboutus/freee_eng_accessibility/
  3. • 色の見え方は人によって異なっている • 遺伝的な理由で特定の色の見分けがつきにくい人は多い ◦ 日本人男性の約5%が先天性赤緑色覚異常といわれてる • 色だけに頼るかたちで情報を表現しているものが読み取りづらい ◦ 成功と失敗を緑と赤で表現しているなど

    実際の写真(左)と、1型2色覚(中央)・2型2色覚(右)の 見え方を再現したもの 映っているUNOのカードはドロー4、緑7、黄8、赤2、青4 色覚異常者の色の見え方(滋賀医科大学 眼科学講座) http://www.shiga-med.ac.jp/~hqophth/farbe/miekata.html
  4. • 様々なハンディキャップをすべて把握しながら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/
  5. • 前バージョンの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
  6. • 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ファイルなど、 対応が難しいものを例外として定義
  7. • WCAGの文章が難しく、現場レベルで使っていくのは難易度が高い • 方針だけでなく、WCAGベースでガイドライン自体を作って運用する • 日本国内では、Ameba と freee のガイドラインが公開されている ◦

    Ameba https://openameba.github.io/a11y-guidelines/ ◦ freee https://a11y-guidelines.freee.co.jp/ • そのまま自社のWebアクセシビリティ方針として取り込んでも良い (とても嬉しいので、もしfreeeのガイドラインを採用してくれる会社があったらぜひ教えてください)
  8. • aXe, Lighthouse ◦ aXeは定番チェックツール。axe-coreとしてCIに組み込んだりもできる ◦ LighthouseはChromeに搭載されている。スコアとして見せてくれる • eslint-plugin-jsx-a11y とか

    eslint-plugin-vue-a11y • 新しく出てきたツール Visible, acot • いずれのツールでも、エラーが出ないから完璧というわけではないので注意
  9. • AmebaやfreeeのガイドラインでWCAG A相当の項目を読み、勘所を掴む ◦ Amebaは項目の横にレベルが記載、freeeは[MUST]がA相当 ◦ 既に達成できているものや、すぐ達成できるものを発見できるはず • Lighthouseスコアを取ってみる ◦

    最初は主要な画面やユーザー登録フローだけでいい ◦ 自動化したりもせず、手作業でブラウザで取ればいい ◦ すこしずつ修正して、まずは上げられるところまでスコアを上げる
  10. • Resources のリンクから Deque University へ移動 • WCAGの達成基準の番号がある • 日本語のドキュメントの対応箇所を読む

    ◦ WCAG の日本語訳 ◦ Ameba や freee のガイドライン https://dequeuniversity.com/rules/axe/3.3/frame-title
  11. • エンジニアの理解・協力を得る ◦ Pull Requestのレビュー時にaXeの結果やLighthouseスコアを貼る ◦ Lighthouseスコアを定期的に記録し、トラッキングできるようにする ◦ 機械的に判定できない項目を人の手で判定・修正していく •

    エンジニア以外にも広める ◦ ビジュアルデザインやコンテンツをエンジニアで頑張るのは難しい ◦ ガイドラインを読み解き、組織に適用しやすい基準をつくる