Moi! UXエンジニアのヨーナスです。今回は、フロントエンドエンジニアに向けて、アクセシビリティに関する3つの誤解について解説したいと思います。
ITイベントやミートアップに参加するとき、業界の仲間たちにアクセシビリティについての印象を積極的に聞くことにしています。そして次のようなことをよく耳にするのです。
- アクセシビリティは特別な知識が必要
- アクセシビリティは、時間の余裕ができたら対応してもいい
- アクセシビリティは、限られた人にしかメリットがない
正直にいうと、このような誤解がずっと残り続けているのは非常に残念ですが、アクセシビリティに触れる機会がないままフロントエンドエンジニアとしてIT業界に入った者として、こうした考え方をよく覚えています。まず、開発者として、何をいつどうすればいいかという問いに簡単に答える内容のコンテンツはまだまだ少ないですし、（自分の活動も含めて）アクセシビリティ啓蒙活動の中では、様々なステークホルダーにもたらされるメリットについて十分に語られていない気がします。
アクセシビリティという言葉に「専門知識が必要な特別対応」というイメージが定着してしまったのも無理はありません。正確なイメージがないと開発プロセスの中での優先度が下がってしまうのはよく聞く話です。
では、このようなアクセシビリティ改善を阻害する思い込みをフロントエンド開発者の視点から解消してみたいと思います！
1. アクセシビリティ対応は特別な知識が必要？ スクリーンリーダーを例に解説
私は、基本的なフロントエンドでのアクセシビリティの担保には、専門知識がほとんど必要ないと思っています。それは、致命的なアクセシビリティ課題の多くは、高度な対応ができていないからではなく、HTMLの間違った使い方から生じるからです。
具体例として、スクリーンリーダーについて説明します。スクリーンリーダーのような支援技術は、ページの内容を正しくユーザーに伝えるため、セマンティックなHTMLに頼っています。「スクリーンリーダー」という言葉から「ページの内容を読み上げるためのみのもの」と想像してしまうかもしれませんが、実はそれだけではなく、ページを操作する様々な機能もユーザーに提供しています。スクリーンリーダーを使えば、ページの全体像をまとめて見たり、見出しやメニューにジャンプしたりすることができます。これを可能にするのは、多くのHTML要素がその役割や利用可能なインタラクションについての情報を持っているロールがあるからです。これがセマンティックなHTMLの本質です。
もうひとつスクリーンリーダーについて知っておくべきことは、ページの中身は上から順番にユーザー伝えられることです。absoluteやfixedで自由に配置された要素でも、マークアップの順番に読み上げられるので、サイトの見た目はデザインデータ通りになっても、関連する要素からあまりにも離れる要素は、支援技術利用者にとってアクセスしにくくなってしまう可能性があります。
では、非セマンティックなタグの使い方で発生するアクセシビリティ課題の例を見てみましょう。
<button>の代わりにonClickが付与された<div>要素はボタンとして認識されない<h1>、<h2>などではなく、文字サイズだけで調整された<span>や<p>要素は見出しとして認識されない- 横に並んでいる削除ボタンと編集ボタンはDOM上では離れて見つからない
些細なミスに見えるかもしれませんが、このような書き方でページの内容がユーザーに正しく伝わらず、サイトやサービスを使えなくなってしまうことは想像に難くありません。
ウェブアクセシビリティを向上させるもっとも効果的な方法は、HTML要素を本来の用途通りに使うことです。タグの使い方に迷ったらMDN（例 MDN: <ul>: 順序なしリスト要素）やHTML Living Standard ですぐ確認できるので、ぜひ使う前に一度参考にしてください。もちろん、サービス内の高度な機能にはWAI-ARIAなどの対応が必要になる場合もありますが、とはいえ、まずは基礎を押さえた方が良いでしょう。
2. 時間の余裕ができたら対応？ 開発プロセスに組み込むことの重要さ
言うまでもなく、フロントエンドにおけるアクセシビリティの幅は広いです。テキストの色による可読性の調整や画像の代替テキストの追加といった、技術的観点から見れば比較的容易に対処できる課題もあれば、膨大な技術的負債に繋がり得る課題もあります。膨大な技術的負債を防ぐにはどうすればいいのでしょうか。
その答えは、ページレイアウトやコンポーネント設計の段階におけるアクセシビリティ向上に注目することです。
React、Vue、Svelteといったフロントエンドライブラリーでの開発は、マークアップが基盤になるため、アプリケーションのロジックは多かれ少なかれHTML構造に依存します。しかし、仕様や開発アプローチについて議論されるとき、土台となるHTML構造がアクセシビリティ向上にどれくらい関係するか、また、コストがどれくらいかかるかは話題として十分に考慮されない気がします。
欠陥がある土台の上に構築されたシステムは、やがて複雑化し、技術的負債を増大させ、将来のリファクタコストを増加させます。HTMLは単純な技術だと思われがちですが、利用箇所が増えたり例外が重ねたりすると、大幅なリファクタなしではアクセシビリティの向上ができなくなってしまいます。その結果、アクセシビリティは開発ロードマップに載りにくくなり、少し余裕ができても本格的な対応は後回しになってしまいます。
では、どうすれば良いでしょうか？
コードエディターに正しいマークアップを強制するMarkuplintを入れたり、ESLintのeslint-plugin-jsx-a11yルールを有効にしたりして適切なHTMLを書くことを開発プロセスに取り込むことがもっとも効率的ではないかと思います。完璧を目指さなくてもいいので、まずは「特別対応」という認識を「コードの品質の保証」にリフレーミングし、しっかりしたHTMLに力を入れ、将来のアクセシビリティ向上の負担を抑えた方が良いではないでしょうか。
参考：
- 解説書 達成基準 1.3.1: 情報及び関係性 | WAI | W3C
- 解説書 達成基準 1.3.2: 意味のあるシーケンス | WAI | W3C
- 解説書 達成基準 2.4.3: フォーカス順序 | WAI | W3C
③ 限られた人にしかメリットがない？より広い視点から見たアクセシビリティ
最後に、アクセシビリティの概念について書きたいと思います。
ユーザビリティとアクセシビリティは別のものとしてよく認識されていますが、個人的には、アクセシビリティはユーザビリティを内包すると思っています。アクセシビリティを向上させることでユーザビリティも担保されるのではないでしょうか。
世界中でアクセシビリティの基準として広く採用されているWeb Content Accessibility Guidelines (WCAG) の中には、デザインの一貫性、インタラクションの原則、テキストコンテンツの書き方など一般的なユーザビリティガイドラインとしてもよく使われている内容が多く含まれています。しかしながら、それに沿った開発が「アクセシビリティ向上」として認識されることは稀です。なぜなら、ユーザビリティとアクセシビリティが別個のものとしてよく認識されているからです。この背景には、いわゆる「健常者」のための使いやさを意味する「ユーザビリティ」と障害者の使いやすさを意味する「アクセシビリティ」という恣意的な区別があるのではないかと思います。
アクセシビリティの定義は業界によって様々ですが、個人的に一番しっくりくるISO 9241-11:2018に基づく日本産業規格JIS Z 8521:2020に記載されている定義を紹介したいと思います。
3.2.2 アクセシビリティ（accessibility）
製品、システム、サービス、環境及び施設が、特定の利用状況において特定の目標を達成するために、ユーザの多様なニーズ、特性及び能力で使える度合い。
この定義には、注目してほしいポイントが一つあります。それは、「障害」という言葉が一切使われていないということです。私はこの点を非常に気に入っています。なぜなら、固定概念にとらわれずに、アクセシビリティの本質を捉え直すことができるからです。例えば、身体障害によって制限を受けている利用者もいるかもしれないし、会社から付与されたデバイスによって制限を受けている利用者もいるかもしれません。アクセシビリティガイドラインに沿った改善はほとんどのユーザーにいい影響を与えるため「障害」という概念に留まる必要がありません。
ここで言いたいのは、アクセシビリティガイドラインは制限するものではなく、すべてのデザインや開発活動を、あらゆる人にとって使いやすい方向へと導くためのものであると捉えてほしい、ということです。
最後に
少しでもアクセシビリティのイメージが湧きましたでしょうか。
HTML自体は本来アクセシブルな設計になっています。そのため、適切な使い方を守るだけで多くのアクセシビリティ課題を事前に解決できます。これは個人的に非常に魅力的です。機能が高度な場合はアクセシビリティ対応の難易度ももちろん上がりますが、土台となるHTML構造がアクセシビリティに則っていれば、改修のハードルはぐっと下がります。
アクセシビリティへの理解を深め、前向きに開発活動に取り入れることで、自分や所属組織へのメリットが少しずつ見えてくるはずです。ぜひ、今日から意識してみてください！
Love Differences, and Merry Christmas!
