Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

アクセシビリティ向上への3つの心構え

こんにちは、フロントエンド推進グループの@taigakiyokawaです。横断組織のフロントエンドエンジニアとして、アクセシビリティガイドラインの作成や共通UIライブラリの開発を行っています。

今回は、社内の全エンジニア向けに発表した、アクセシビリティへの意識向上を目的としたプレゼンテーションの内容をブログとして紹介していきます。

The same article in English is here

アクセシビリティ向上への3つの心構え

まずはじめに、今回の要点です。

  1. 低いアクセシビリティは 「システム障害」
  2. できるところから地道に
  3. アクセシビリティは「対応」するものではなく 「向上」 させるもの

これらの心構えについてそれぞれ説明していきます。

アクセシビリティとは

アクセシビリティとは、サービスが「利用可能な状況の幅広さ」1のことです。

障害2の有無や年齢、言語に関わらず様々な人が、サービスや情報をあらゆる状況で利用できることが、「アクセシビリティが高い」状態です。

反対に、特定の誰かや限られた状況でしかサービスを利用できないことは、「アクセシビリティが低い」状態です。

つまり、利用可能な状況の幅を広げていくことが、「アクセシビリティを向上させる」ということです。

アクセシビリティは誰のためか

アクセシビリティは障害者や高齢者に限らず、みんなのためのものです。

よく「障害者や高齢者のためのもの」といった誤解が見られますが、アクセシビリティは特定の誰かを対象にしたものではなく、みんなが恩恵を受けるものです。

とはいえ、利用状況をイメージする上で、実際にどんな障害があるのかを知っておくことは重要です。そこで、Webサービスを利用する上での主な障害の種類について紹介します。

主な障害の種類

  • 上肢障害：マウスやキーボードでの操作が難しい
  • 弱視：画面を大きく拡大する必要がある
  • 色覚特性、色弱：色の区別が難しい、一部の色が識別できない
  • 全盲：キーボードのみでスクリーンリーダーを使う、点字ディスプレイを使う
  • 聴覚障害、ろう：字幕や手話が必要、音声書き起こしツールを使う
  • 認知・学習障害：短期記憶が難しい、テキストの読み書きが難しい
  • 一時的な障害（例）：
    • 腕の骨折によりマウスの操作が難しい
    • 家にヘッドホンを忘れたのでオンライン会議の内容が聞き取れない
    • 今すぐワークフローの承認をしないといけないが、外出していてPCが使えない
  • など

アクセシビリティは誰が取り組むのか

アクセシビリティの向上は、特定のデザイナーやエンジニアに限らず、みんなが取り組むものだと思ってもらいたいです。プロダクトの品質向上に限らず、日々の業務の中でもアクセシビリティを意識すべきポイントがあります。

  • 資料を日英併記して共有する（グローバル化への取り組みもアクセシビリティです）
  • 口頭で話したことをドキュメントに残す
  • リンク先のコンテンツの内容が分かりやすいテキストで共有する（「こちら」ではなく）
  • 営業資料の文字を小さくしすぎない
  • など

また、仕事に限らず、SNSなどにおいても、自分が発信したい情報に「本当にみんなが」アクセスできるかどうかを常に意識していきましょう。

なぜアクセシビリティが重要か

ここで伝えたいのが、「心構えその1：低いアクセシビリティは 『システム障害』」です。

その前にまずは、「障害」について考えてみましょう。障害はどこにあるのか。これについては大きく分けて「医学モデル」と「社会モデル」と呼ばれる2つの考え方があります。

医学モデル

医学モデルでは、「障害」は人間の心身の側にあるものとみなします。

体の一部や精神などに障害がある人を、治療やカウンセリング、リハビリテーションなどで正常な状態に回復させていくことで、障害を取り除いていくという考え方です。

車椅子に乗った人が段差に直面している。歩けるようになることで、自らの足で段差を上ることができる。

社会モデル

一方、社会モデルとは、障害は社会と個人の相互作用によって生まれるものとしています。

そして、多様な人や状況に対して、社会環境の方が適応していくことで、そこに「障害がある」という状態を取り除いていく考え方です。

車椅子に乗った人が段差に直面している。段差がスロープに変わることで、車椅子のまま上ることができる。

我々は、障害の社会モデルの考え方に基づいてアクセシビリティを向上させていきます。

つまり、障害はユーザーが持っているものではなく、ユーザーとサービスのあいだに存在すると捉えます。

アクセシビリティが低い状態は「利用しづらい」だけではない

アクセシビリティが低い状態というのは、単に使いづらいだけではなく、全く使えないという状況を生みます。

ところで、ユーザーがサービスを利用できない状況の原因を、我々は何と呼ぶでしょうか。

単にバグやエラーとも言いますよね。ここではまとめて「システム障害」と呼ぶことにします。

つまり、アクセシビリティが低い状態とシステムに障害が発生している状態は、どちらもユーザーがサービスが利用できない状況を生み出すという点において共通しています。

他にも色々理由はある

「なぜアクセシビリティが重要か」について答える理由は他にも色々ありますが...

最も重要だと思うのは、アクセシビリティが低い状態は、ユーザーがサービスを利用できない状況を生む原因、つまり障害となりうるからだと考えます。

心構えその1：低いアクセシビリティは「システム障害」

  • 障害はユーザーが持っているものではなく、ユーザーとサービスのあいだに存在するもの
  • アクセシビリティが低いサービスは単に利用しづらいだけではなく、全く利用できない状況を生む原因となる
  • サービスが利用できない状況を生む原因という点で、アクセシビリティが低い状態はシステム障害と同じ

やや大げさに聞こえるかもしれませんが、これくらいの意識をもって取り組んでいきましょう。

どうアクセシビリティを向上させていくか

ここで大事なのが、「心構えその2：できるところから地道に」です。

まずは課題を把握しよう

ぜひ、チームのみんなでプロダクトを触ってみてチェックしていただきたいです。

その際に参考となるのがアクセシビリティガイドラインやチェックリストといった資料です。

Web アクセシビリティガイドライン&チェックリスト

Webアクセシビリティに関するガイドラインやチェックリストは、国際標準であるWCAGをはじめ、日本の企業が公開しているものもいくつかあります。

当社では、Money Forward Cloud Accessibility Guidelinesというものを英語で作成し、現在は社内向けに公開しています。 このガイドラインは、WCAG 2.2をベースとして、デザイン、実装、QAにおけるポイントを各達成基準ごとにまとめています。

「知覚可能」から目指そう

ただ、たくさんあるガイドラインをどこから見ていけば良いか分からないと思います。そこで、WCAG が提示している「アクセシビリティの4原則」のうち、「知覚可能」な状態から目指していくことをおすすめします。コンテンツを操作や理解できるようになるには、まずはその存在を知覚できる必要があるためです。

この4原則についてそれぞれ簡単に説明していきます。

アクセシビリティの4原則

WCAGは以下の4つを「アクセシビリティの4原則」としています。

  1. 知覚可能
  2. 操作可能
  3. 理解可能
  4. 堅牢

(出典: Introduction to Understanding WCAG | WAI | W3C)

1. 知覚可能

知覚可能とは、ユーザーが知覚できる方法で情報を提示することです。

  • 代替テキストを付与する
  • 関係性を示す
  • 1つの感覚に依存しない（視覚、色覚、聴覚）
  • など

2. 操作可能

操作可能とは、インタラクションやナビゲーションが操作できることです。

  • キーボードで操作できる
  • タイミングを調節できる
  • 支援技術でナビゲートしやすくする
  • など

3. 理解可能

理解可能とは、情報や動作が理解できることです。

  • 適切な言語設定
  • 予期せぬ動作が起きない
  • エラー箇所が特定できる
  • ラベルや説明がある
  • など

4. 堅牢

堅牢とは、支援技術などあらゆる手段でコンテンツが解釈できることです。

  • UIの役割、名前、状態が適切に設定されている
  • など

アクセシビリティを自動で解決する方法はほとんどない

実際にアクセシビリティ向上を目指していく上で注意していただきたいのが、自動で解決できる方法はほとんどないという点です。

アクセシビリティの問題をチェックする上で、自動チェックツールや静的解析ツール（Linter）はたくさんあります。これらはぜひとも導入していっていただきたいです。

ただし、アクセシビリティのチェックは基本的には人の手で確認する必要があります。例えば、画像の代替テキストをチェックする場合、自動ツールでは代替テキストの有無はチェックできても、そのテキストが意図した通りの内容かどうかまではできないため、人間がチェックする必要があります。（近いうちにAIに任せられるかもしれませんが、他のコンテンツとの文脈も含めた説明が意図通り設定されているかどうかは、今は機械的に判断することは難しいです。）

加えて、「これを導入すればWCAGに対応できます」と謳う、いわゆる「アクセシビリティオーバーレイ」と呼ばれるサービスに注意してください。Overlay Fact Sheetなどにその有効性や問題点が挙げられているように、これらのサービスによってアクセシビリティの問題を根本的に解決することは難しいです。

あくまでも、できるところから地道に、コツコツと向上させていきましょう。

よくある事例

ここで、現状の当社プロダクトでよくある事例とその解決方法について説明していきます。（社内プレゼンテーションでは、マネーフォワード クラウド勤怠をスクリーンリーダーで使ってみるデモを実施しました。）

  1. アイコンボタンが読めない
  2. ドロップダウンメニューの振る舞いが分からない
  3. 目的のセクションが見つけにくい
  4. ボタンを押した時の結果が分からない

1. アイコンボタンが読めない

ラベルを持たないアイコン付きのボタンには、必ずアイコンに代替テキストを付与しましょう。また、そもそもボタン自体が<div>要素や<span>要素で作られている場合は、<button>要素を使ってフォーカス可能にしましょう。

<button type="button">
  <svg role="img" aria-label="お知らせ">...</svg>
</button>

ちなみに、<button>要素にaria-label属性を付与することもできますが、この場合の<svg>要素は意味を持つ画像であるため、こちらにaria-label属性を付与しています。この理由の詳細については、以下の記事をご参照ください。

zenn.dev

2. ドロップダウンメニューの振る舞いが分からない

ドロップダウンメニューをきちんとアクセシブルにするのは難しいです。コンポーネントレベルでのアクセシビリティが担保されているライブラリを使うことをおすすめします。

3. 目的のセクションが見つけにくい

見出しがなかったり、正しい見出しレベルが付与されていないと、ユーザーによってはセクションの関係性が分かりにくくなります。適切な見出しレベルを用いたり、ランドマークロールと呼ばれる役割を持つHTML要素を使うことで、目的のセクションに辿り着きやすくなります。場合によっては、画面構成自体を見直す必要があるかもしれません。

<section id="workflow-list">
  <h2>申請一覧</h2>
  <div>...</div>
</section>

4. ボタンを押した時の結果が分からない

ボタンを押した時に表示されるメッセージが、ユーザーによっては伝わらない場合があります。画面上の変化が支援技術にしっかり伝わるようにしましょう。

<div role="status">ユーザー情報を更新しました</div>

心構えその 2：できるところから地道に

  • みんなでプロダクトを触って課題を見つけよう
  • ガイドラインを参考に、「知覚可能」な状態から目指していこう
  • 自動で解決する方法はほとんどない

ある程度課題や解決策が分かってくると、きっとアクセシビリティを考えること自体が面白いと感じると思うので、まずは地道に取り組んでいきましょう。

いつアクセシビリティに取り組むのか

心構えその3：アクセシビリティは「対応」するものではなく 「向上」 させるもの

（ちなみに「アクセシビリティは『向上』させるもの」という言葉は、SmartHRさんのアクセシビリティ基本研修を元にしています。）

「アクセシビリティ対応」が招く誤解

「アクセシビリティ対応」という言葉を見たり聞いたりしたことはありませんか。

このアクセシビリティ対応という言葉はアクセシビリティの改善に取り組むという意図でしばしば使われることがあります。

自分も使っていたことがあります。

しかしこの 「対応」というのは、アクセシビリティの改善が後づけで取り組めるオプションのような誤解を招きます。「対応」を行うのはあくまでガイドラインに対してであって、アクセシビリティそのものは「対応」するものではないです。

つまり、対応というニュアンスには、何かのサービスや機能をリリースした「後に」アクセシビリティチェックを行い、課題を見つけて、コストをかけて改善していくというものが含まれます。3

たしかに、既にリリースしてしまったものに対しては前のセクションでやったように、そのように対処するしかありません。

しかし、これだといつまでも余分にコストがかかって優先度が上がらないものという扱いになってしまいます。

すべての開発プロセスでアクセシビリティを向上させていく

では、いつアクセシビリティを向上させるのか。それはすべての開発プロセスです。プロダクト開発には大きく分けて「設計」「実装」「QA」の3つのプロセスがありますが、それぞれでアクセシビリティ向上させるために意識すべきポイントがあります。

設計プロセスでのアクセシビリティ向上

設計プロセスでは、アクセシビリティ上の仕様についてデザイナーと入念に話し合ってきちんと決めておきましょう。

  • この画像の代替テキストは何か
  • このUIはどのようにキーボードで操作するか
  • このUIは何のHTML要素を想定しているか
  • など

実装プロセスでのアクセシビリティ向上

実装プロセスでは、Web標準に従ってUIを作り、コンポーネントレベルでのインタラクションやキーボード操作についてテストを実施しましょう。

  • 適切なHTML要素や属性値を用いる
  • 静的解析によるチェックを導入する（eslint-plugin-jsx-a11y など）
  • コンポーネントレベルでのインタラクションをテストする
  • キーボード操作をエミュレートする自動テストを行う
  • Pull Requestごとに簡易的な手動チェックを行う
  • など

QAプロセスでのアクセシビリティ向上

QAプロセスにて、機能リリース前に必ずプロダクトレベルでアクセシビリティチェックを実施しましょう。

  • キーボードだけで操作できるか
  • スクリーンリーダーがUIの役割や名前、状態を認識できるか
  • 自動チェックツールによる確認（axe DevToolsなど）
  • など

心構えその3：アクセシビリティは「対応」するものではなく「向上」させるもの

  • 「アクセシビリティ対応」は後づけで取り組めるという誤解を招く
  • 設計、実装、QAすべての開発プロセスでアクセシビリティの向上を意識する
  • 設計の時点でアクセシビリティ上のUIの仕様をきちんと決めて、リリース前に必ずチェックしよう

はじめから、アクセシビリティを根付かせていきましょう。新機能開発の時には特に意識しましょう。

アクセシビリティ向上への3つの心構え（再）

要点のおさらいです。

  1. 低いアクセシビリティは 「システム障害」
  2. できるところから地道に
  3. アクセシビリティは「対応」するものではなく 「向上」 させるもの

最後に

最後に、World Wide Webの生みの親であるティム・バーナーズ=リー氏の言葉を紹介します。

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee W3C Founding Director and inventor of the World Wide Web

(出典: Accessibility | Our mission | W3C)

「Webの力とは、その普遍性にある。障害の有無に関わらず誰もがアクセスできることは、不可欠な要素である。」

Webは元からアクセシブルにできるように設計されています。

そんなWebの力を最大限引き出せるサービスを作っていきましょう！

Let's improve Accessibility Together!

参考・関連リンク

  1. 伊原 力也、小林 大輔、桝田 草一、山本 伶『Webアプリケーションアクセシビリティ──今日から始める現場からの改善』（2023、技術評論社）第1章「Webアクセシビリティとは」1.1「アクセシビリティとは」より引用↩
  2. 本記事内での「障害」という表記については、障害の社会モデルの考え方に基づき、「害」は障害者本人が持つものではなく、適応できていない社会環境の側に存在するものとしているため、「障がい」ではなく「障害」としています。また、「障がい」と表記することで、読み上げなどが適切に行われないなどのアクセシビリティ上の懸念も考慮しています。↩
  3. コトバンクによると「対応する」という言葉には「④ 相手の出方や状況に応じてそれにふさわしく行動すること。」が含まれており、何かに対するリアクションという意図を含みます。↩