Web開発におけるアクセシビリティについて学ぶ
はじめに
Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass を見て、アクセシビリティ面白いと思い、色々調べたり実際にアクセシビリティ改善を行ってみました。
アクセシビリティとは
Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass の基調講演「Webエンジニアとしていま知っておきたいWebアクセシビリティ」より、
アクセシビリティとは「状況を広げることを追求する。使いやすさに比重を置いていない」ことです。
ユーザビリティとの違いは簡単にいうと下記のように話がありました。
アクセシビリティ
— nori (@nori0__) January 13, 2021
あらゆる状態で誰でも使える
ユーザビリティ
特定の状況で特定のユーザーにとって使いやすい
#FEStudy
欧米では法律で義務化されていたり当たり前のように考慮されているため日本もそうなっていくのではないかと思います。
アクセシビリティのガイドライン
Web Content Accessibility Guidelines (WCAG) Overview | Web Accessibility Initiative (WAI) | W3C があります。
今の最新はWeb Content Accessibility Guidelines (WCAG) 2.1 のようです。
ガイドラインに解説書Understanding WCAG 2.1 があって合わせて読むのが推奨のようです。
日本語訳WCAG 2.1 解説書 を読んでたら気が遠くなりそうなぐらい長文ですね。
GitHub - waic/wcag21: WCAG 2.1 Japanese で管理しているようです。
WAI-ARIA
デフォルトと異なるUI実装をした場合にセマンティクス(意味)を伝えることができるHTML属性のこと。
Accessible Rich Internet Applications (WAI-ARIA) 1.1
WAI-ARIA オーサリング・プラクティス 1.1
上記のサイトからメニューを見て合う要素を探して実装してみるのが良いとのことです。
さらに、マークアップを進化させる WAI-ARIA の基本 より補完できるものは以下の3点。
また、WAI-ARIAの仕組みをざっくりと説明すると
だそうで、すごく分かりやすかったです。
他社のアクセシビリティの事例
WCAG難しいよーってなる場合は他社さんのガイドライン見た方がまだ分かりやすいし手を出しやすいと思いました。
Ameba Accessibility Guidelines
freeeアクセシビリティー・ガイドライン — freeeアクセシビリティー・ガイドライン Ver. 202101.1 ドキュメント
検証ツール
aXe: 定番なチェックツール。CIに組み込むことも可能 (axe-core)
Lighthouse: Chromeに搭載されている。パフォーマンスも測定できる
eslint-plugin-jsx-a11y, eslint-plugin-vue-a11y: eslintでアクセシビリティのチェックを行う
@storybook/addon-a11y: コンポーネントでアクセシビリティをみる
Visible: Webサイトのアクセシビリティ診断。あなたのサイト、見えますか？ - Visible
acot: Accessibility Testing Frameworkとして現在開発が行われている。acot-a11y/acot: Accessibility Testing Framework. More accessible web, all over the world.
Puppeteer と ARIA Handler: ARIA情報をもとにブラウザ自動化を行う。Puppeteer と ARIA Handler | Medium
VoiceOver: Mac OSであればVoice Overを使って、簡単にスクリーンリーダーを扱うことができます。macOS の VoiceOver で Web サイトのスクリーンリーダー対応をはじめよう - Qiita
Webアクセシビリティの適用の考え方
Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」 - connpass の基調講演「Webエンジニアとしていま知っておきたいWebアクセシビリティ」で話していた内容になりますが、
作り手の目線で考えるとこのサービスを多くの方に使ってもらえるようにする普遍的な改善、そして段階的に改善するものというのが、いい考えだなと思います。
また、主要な画面に絞って実施する、最初は手動で試すというのもハードルを下げるという意味で重要だと思います。
アクセシビリティの問題のあるサイトとして駒瑠市という架空のWebサイトがあるそうです。
https://a11yc.com/city-komaru/
実際にアクセシビリティ改善を行ってみた
今回改善するのはこのサイト。
やはり好きなコンテンツは、たくさんのユーザーに楽しんでもらいたいですからね！
早速Lighthouseを測ってみました。
Lighthouseで測った時に出てくるリンクLearn moreで原因を見つつ改善していきましょう。
Buttons do not have an accessible name
ボタンのアクセシビリティに関する名前がついていないと言われてます。
確かにイメージカラーを選択するボタンにはコンテキストがありません。
<button class="ui circular button circle-btn " style="background: rgb(247, 161, 186);">
aria-labelで別途名前をつけることにします。
Background and foreground colors do not have a sufficient contrast ratio.
リンクのコンストラスト比が十分ではない、つまり背景と色が似てて見づらいと言われています。
<a href="https://sparql.crssnky.xyz/imas/">
aタグを使っているだけなのですが、デフォルトの色だとコンストラクト比足りないんですね。
アクセシビリティ改善した！77%から100%！
— nori (@nori0__) January 31, 2021
楽しかった>< pic.twitter.com/vUwKF0rP3G
上記の対応で100%になりました！
他にも自動テストでカバーできない項目も書いてあります！
適宜参考にしましょう。
Lighthouseでは最低限のところのチェックのみなので、改善するにあたって、
accrefs - Webアクセシビリティの参考資料まとめ
で情報を仕入れつつ、
Reactなら初学者は
アクセシビリティ – React
今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界
を見て、aria属性に困ったらWAI-ARIAのガイドラインを見るという方法で進めてみるのが良いのではないかと思いました。
