Webフロントエンドエンジニアがアクセシビリティを学習する利点

Posted at 2024-12-12

はじめに

近年ではリモートワーク、ネットショッピング、娯楽ネットメディア、公共サービス、等Web経由のサービスが増大しています。こういったWebサービスの価値をより多くの人に届けるためにはアクセシビリティを考慮したWebサイトの設計が重要です。

とはいえ、アクセシビリティの重要性を理解していても、いざ手をつけようとすると、想定以上に工数がかかってしまうんじゃないか、と懸念するかもしれません。（私がそうでした）

ここでは、アクセシビリティを意識することがエンジニアに利点をもたらす可能性を提示して、アクセシビリティに対する心理的障壁の軽減に役立てればと思います。

まずは、Webサービスのアクセシビリティがどのようにして利用者に提供されるのかを理解する必要があります。

ブラウザはDOMを基にアクセシビリティオブジェクトモデル（AOM）を生成します。
そして、読み上げソフトなどの支援技術が AOM を基にして利用者に支援（読み上げ機能等）を提供します。

簡単な図で表すと以下のようになります。

AOM が重要な役割を担っていることがわかります。そしてそれを生成するための情報源である DOM がアクセシビリティを意識したつくりになっていることで、より良い支援を提供できることになります。

ブラウザは HTML を解析して DOM ツリーを構築します。この DOM ツリーは、HTML 要素をノードとして階層構造で表現しています。
例:

<html>
  <body>
    <button>Click me</button>
  </body>
</html>

この HTML を基に、次のような DOM ツリーが生成されます。

html
└── body
    └── button
        └── "Click me"

次に、ブラウザは DOM ノードを基にアクセシビリティ属性（例: role, aria-* 属性）を解析します。これらの属性は、AOM を生成する際に重要な手がかりとなります。

例:

<button aria-label="Warning">Click me</button>

この場合、aria-label="Warning" がアクセシビリティ情報を追加提供します。

CSS も AOM の生成に影響を与えます。たとえば、要素が display: none; や visibility: hidden; によって非表示になっている場合、その要素はアクセシビリティツリーに含まれないことがあります。

ブラウザは DOM ノードの情報とアクセシビリティ属性を統合して AOM を構築します。この AOM は、スクリーンリーダーやその他のアクセシビリティツールが利用するための抽象化されたツリー構造です。

例: DOM:

html
└── body
    └── button
        └── "Click me"

対応する AOM:

document
└── button
    └── label: "Warning"
    role: button

ブラウザは、不要なノードや情報を除外し、アクセシビリティツールにとって有用な情報のみを保持するように AOM を最適化します。

最終的に生成された AOM は、スクリーンリーダーなどのツールに提供されます。これにより、視覚的な情報が見えないユーザーでもウェブページを利用できるようになります。

以上のように AOM は DOM の意味（セマンティック）を解釈して生成されます。つまり機械的に判定可能な意味を DOM から読み取れる状態が理想です。この状態（もしくは近い状態）を実現できれば、以下の利点が得られると思います。

アクセシビリティに配慮した開発は、標準に従ったコーディングを促進します。これは次の理由でシンプルな実装につながります。

セマンティックな HTML の活用
セマンティック HTML 要素（例: <header>, <main>, <button>）は、視覚的な役割だけでなく、アクセシビリティの情報も同時に提供します。これにより、複雑な JavaScript や ARIA 属性で補完する必要が減り、コードが簡潔になります。
再利用可能なコンポーネントの設計
アクセシビリティを考慮したコンポーネントは、明確な役割と一貫性を持つため、保守性が向上します。これにより、コードの重複や冗長な処理を減らせます。

アクセシビリティに対応した実装は、ユーザーインターフェースの振る舞いを明確に定義するため、テストの効率性が向上します。

標準的なルールに基づく検証
WCAG（Web Content Accessibility Guidelines）やセマンティック HTML のルールに基づく開発は、アクセシビリティツール（例：Testing Library、Axe、Lighthouse ）を使った自動テストが容易です。これにより、人手による確認の負担が軽減されます。
ユーザビリティの一貫性
アクセシブルな設計では、フォーカス移動やキーボード操作が明確に定義されるため、シナリオテストやエンドツーエンドテストを効率的に実施できます。
障害時のトラブルシューティングが簡単
シンプルな実装により、問題が発生した場合でも、修正箇所が特定しやすくなり、迅速な対応が可能です。

ブラウザの開発者ツールを使うと、要素ごとのアクセシビリティツリーを参照できて便利です。以下は Qiita の「投稿する」ボタンのアクセシビリティを確認したときのスナップショットです（ブラウザは Edge です）。

以上のように、アクセシビリティを考慮した実装は、ユーザー数を増やすだけではなく、実装のシンプルさとテストのしやすさにもつながると思います。この点はエンジニアにとっても有益ではないでしょうか？

という感じで私見をごり押ししてしまいましたが、私自身まだまだアクセシビリティについては勉強しはじめだったりします

この記事をきっかけにアクセシビリティへの取り組みに前向きな気持ちを持っていただければうれしいです。まずは小さな改善から取り組んでみましょう