Webアクセシビリティの向上に取り組むための準備
こんにちは。イチマルイチデザインでフロントエンドエンジニアを担当している長谷川です。
ここ最近、企業からのWebアクセシビリティの向上や改善といった言葉をよく目にするようになりました。
様々な活動事例を見て、誰もが利用できるWebサイトやWebサービスを作ることの大切さを感じ、これを機にWebアクセシビリティの向上に真剣に取り組んでみようと考えました。
ただ最初から、セマンティックなマークアップやWAI-ARIAなどのテクニカルなことには取り組んでおりません。
今回は、取り組むまでの経緯、目標設定、役立つツールの整理に留めております。
Webアクセシビリティとは
ウェブのアクセシビリティを言い表す言葉がウェブアクセシビリティです。ウェブコンテンツ、より具体的にはウェブページにある情報や機能の利用しやすさを意味します。
さまざまな利用者が、さまざまなデバイスを使い、さまざまな状況でウェブを使うようになった今、あらゆるウェブコンテンツにとって、ウェブアクセシビリティは必要不可欠な品質と言えます。
より引用）
アクセシビリティというのはあなたのウェブサイトを可能な限り多くの人に利用してもらうようにすることです。かつては我々はアクセシビリティのことをハンディキャップを持つ人々のためのものだと考えていましたが、現在はモバイルデバイスや遅いネットワークを利用している人々のためのものでもあると考えられています。
（MDN「アクセシビリティとは？」より引用）
なぜこれまでWebアクセシビリティの向上に取り組むことがなかったのかを、簡単に振り返る
Webアクセシビリティという存在自体は知っていましたが、やっていかないとなーと漠然と思うだけで、プロジェクトに落とし込んだ経験はありませんでした。
それは知見がないという理由はもちろんですが、大きな理由としましては、経営目線的なことでした。
「サイトパフォーマンスの向上で、売上が〇〇%上昇します。」
上記の指標は、多くの開発者や運用担当者が目にしたことがあるのではないでしょうか。
しかし、
「Webアクセシビリティの向上で売上が〇〇%上昇します。」
上記はどうでしょうか。なかなか目にしたことは無いのではと思います。
つまり、
クライアント側も、利益になるか分からないWebアクセシビリティの向上は要求しない
開発者側も、クライアントから要求のないものを実装するのは不利益
というように、Webアクセシビリティの向上は双方に利益が無いのでは？やる必要あるの？という状況に陥っていたからです。
どうやるのか？ではなくなぜやるのか？で議論が終わってしまっていました。
まずは目標の設定：出来ることから対応し、最低限のレベルAに準拠したい
闇雲にWebアクセシビリティの向上に取り組むぞーではなく、最初に目標を定めました。
WCAG2.1（Web Content Accessibility Guidelines）には、以下の達成基準が定義されています。
レベルA（最低限のレベル。達成できていないと、スクリーンリーダーや拡大鏡などの支援技術を用いても、サービスを利用できない）
レベルAA（より良いレベル。達成できれば、支援技術無しでもサービスを利用できることが多くなり、より多くのユーザー・状況で使えるようになる）
レベルAAA（より発展的なレベル。達成できれば、よりサービスを利用しやすくなる場合がある。ただし、項目の中には達成が難しいものもあり、サービスによって検討が必要なものもある）
全ての達成基準を網羅するのは困難だと思い、最低限のレベルAから準拠していこうと考えました。
最低限とは言っても、結構大変
例えば、非テキストコンテンツの代替テキスト（<img>タグのalt属性）の対応ですが、Webサイト全体で使用される画像が多いほど、代替テキストを考えなければなりません。
この画像は1年ほど前のモスのネット注文のWebサイトです。（現在は閲覧できなくなっています。）
信じられない数のジョイマン高木の画像がこれでもかと散りばめられており、その全ての画像のaltが「ジョイマン高木」と記述されていました。
思わず笑ってしまいましたが、実装する側の人を思うと涙が出てきます。
このようにaltを考えるのも一苦労ですし、
最低限のレベルAだけでも達成基準項目数が30項目あります。
最低限って多いな・・・と正直感じました。頑張ります。
Webアクセシビリティの向上に取り組むにあたっての便利なツール
早速手を動かすよりも、まずは現時点での問題を可視化します。
ですが、人の手で一つ一つ調べ上げながら問題を見つけるのは困難です。
そこで、Webアクセシビリティ問題可視化の手助けとなるツールを紹介します。
axe DevTools
axe DevToolsはブラウザ上でアクセシビリティの問題を検知してくれるChrome拡張機能です。
Critical、Serious、Moderate、Minorの4段階でアクセシビリティの問題を洗い出してくれて、どの箇所が問題なのかをissueでリスト化してくれるので、とても分かりやすいです。
また、Chrome拡張機能ということで、導入しやすいと思います。
Lint系
Lintをプロジェクトで用いて、事前にエラーを検知するのも良いと思います。
Reactを用いた開発の場合
Vueを用いた開発の場合
HTMLを書く人向け
その他参考になるサイトなど
MDN「アクセシビリティー」
開発者目線でアクセシビリティの紹介がされています。
freeeアクセシビリティー・ガイドライン
Ameba Accessibility Guidelines
具体例、実装方法、チェック方法などで構成されていて、参考にしやすいです。
Accessibility Support
スクリーンリーダーの対応一覧表です。上級者向けかもしれません。
まとめ
Webアクセシビリティの向上に取り組む準備として、まずは目標を設定し、ツールを使用してアクセシブルでない問題の可視化を行う方法を紹介しました。
準備段階ではありますが、Webアクセシビリティの向上に取り組むことで、誰もが利用できるより良いサービスを生み出したいと思っております。
終わりに
イチマルイチデザイン株式会社では、WebアプリケーションやWebサイトの開発をするフロントエンドエンジニアの仲間を募集しています。
デザイナーやバックエンドエンジニアの方も募集をしておりますので、興味がある方はご連絡お待ちしております。
▼採用サイトはこちら