先日勉強会でアクセシビリティについての発表をしたので、その内容をかいつまみます🙋‍♀️

Webアクセシビリティとは

Webアクセシビリティとは、「障害や状況問わず、誰でもウェブサイトにアクセスでき、利用できるようにすること」です。
元々は、障害者を考慮して提唱されていましたが、現在はアクセシビリティの対象は障害者以外にも広がっています。

例えば、以下のような状況・方々もアクセシビリティの範囲に含まれます。

• 画面や入力モードが異なるデバイスの利用者（スマートテレビ、スマートウォッチなど）
• メガネをなくした、腕が折れたなど、一時的な障害を持つ人
• 明るい日差しの下にいる人（画面が見づらい）
• 音声が聞けない環境にいる人（音声コンテンツが使いにくい）

アクセシビリティを取り巻く状況

各国と日系企業の状況を調べてみました。

各国の状況

全体的に、障害者やアクセシビリティに関わる法規制が進んでいます。
アクセシビリティは障害者差別に繋がる課題とされており、実際に訴訟も起きている国も存在します。

アメリカ

障害者やアクセシビリティに関わる法規制が複数存在

Section508、ADA、ACAAなどがあります。

アクセシビリティ関連の訴訟件数は年々増加

有名企業や有名人のサイトも訴訟を受けています。賠償金や和解金などを支払うケースもあります。

EU

EUはアクセシビリティ関連の指令を出しており、加盟国は国内法に内容を反映する必要がありました。

Web アクセシビリティ指令（2016年12月施行）

公共部門の Web サイトやモバイル アプリを、誰もが読み、理解し、手続きを完了できるようにする共通のアクセシビリティ要件を定めています。

欧州アクセシビリティ法（2019年6月施行）

多くの主要なICT製品およびサービスを含む共通のアクセシビリティ要件を定めています。

日本

アクセシビリティを明示した法律はありませんが、関連する法律に変更が入りました。

障害者差別解消法 改正（2021年5月公布/公布日より3年以内に施行）

民間企業による障害者への合理的配慮提供を義務化しました。

※改正前は公共団体のみ義務で、民間企業は努力義務でした。
※合理的配慮提供：障害者から何らかの配慮を求められた場合、事業所側は過重な負担がない範囲で、障壁を取り除く配慮を行うことです。

日系企業の状況

全体的に、アクセシビリティ対応は「出来たらなおよし」よりも「当たり前にしていこう」という風潮ができつつありそうです👀

企業としての取り組み

以下のような対応をされている企業もあります。気になる方は検索してみてください🔍

• アクセシビリティへの対応方針を公開する
• 独自のガイドラインを定める

エンジニアなどの取り組み

企業のエンジニアブログを覗いてみると、それぞれアクセシビリティ対応を進めている様子も伺えました。
以下は、エンジニアチームが取っていた対応の一例です。

• アクセシビリティ関連のOSSツールを利用する
• アクセシビリティチームを立ち上げる
• 独自のアクセシビリティ基準を定めており、基準を満たしている

企業がアクセシビリティ対応するメリット

企業に勤められているエンジニアさんは多いと思うので、企業的に何が良いのか、も調べてみました。

ユーザー層の拡大/ユーザビリティの向上

• アクセシビリティ不十分により、サイトを利用できなかった人たちが利用可能になる
• 見にくさ・使いづらさが減る、それによる離脱も減る

企業価値の向上

障害者差別と直結するアクセシビリティは、社会的・政治的な意思表明を意味するので、CSRやロイヤリティの向上を期待できます。

• CSR・ESG対策
• ブランドロイヤリティの向上

SEO対策

マシンリーダビリティが向上するため、SEOにも有効と言われています。

アクセシビリティ基準・対応

アクセシビリティにはガイドラインがあり、項目や基準が定められています。
以下が有名どころです💫

• Web Content Accessibility Guidelines (WCAG) 2.0
• ISO/IEC 40500:2012
• JIS X 8341-3:2016

原則別の対応内容

WCAGではアクセシビリティの4つの原則が示されています。
ここでは、その原則別に対応内容を紹介します。

知覚可能

Webページ上の内容を認識できることです。

• 画像・図などの代替テキスト
• 動画・音声の字幕や書き起こし
• 色のコントラスト比の確保

など。

操作可能

ページ上の機能を誰でも操作できることです。

• キーボードのみで操作可能
• 動きのあるコンテンツの停止・一時停止
• 操作に時間制限を設けない
• 閃光を基準値以下にする（発作防止）

など。

理解可能

ページの内容や挙動を理解・予測でき、それらに一貫性があることです。

• 要素がフォーカスできる・フォーカス箇所がわかる
• エラー箇所がどんなユーザーにもわかる
• ナビゲーションの位置や文言が一貫している

など。

堅牢

Webページが標準仕様であり、それによって、スクリーンリーダー等の支援技術が連携できることです。

• HTMLの文法エラーがない
• スクリーンリーダー等の支援技術が情報を読み取れる

など。

エンジニアが取り入れられるアクセシビリティ対応

ツールを使った検証

aXe, Lighthouseなどでアクセシビリティの検証をすることができます。
上記どちらもChromeの拡張機能として使用可能です🙆

アクセシビリティ系のライブラリを導入する

axe-core、eslint-plugin-jsx-a11yなど、アクセシビリティ系のライブラリをアプリケーションに導入するのも１つの手です✋

HTMLコーディングへの配慮

HTMLコーディングに配慮することで、ブラウザや支援技術が文書の意味を正しく認識できるようになります。

例えば、その要素が果たす意味に最も適切なHTMLタグを使用し、セマンティックなHTMLを書くことです。
また、要素が何か、性質、状態などの意味を付与するHTML属性「WAI-ARIA」を追加することも有効です。

実際に確認する

• キーボードのみで操作可能か
• フォーカスは適切に当たっているか、分かりやすいか

など、実際に確認した方が分かりやすいこともあります。

まとめ

ざっとアクセシビリティのことや、エンジニアができることを見てきました。
アクセシビリティ対応は、一気にできるようなものではなく、積み重ねていくものなので、1人1人ができることから取り組むのが大切かと思います👀