アクセシビリティを守る理由

アクセシビリティを守ることで、障害の有無にかかわらず、そして開発者自身にとってもメリットがあります。障害のあるユーザーはスクリーンリーダーなどの支援技術を通じてWebサイトを円滑に利用でき、一般のユーザーはより速く快適な体験を得られます。さらに開発者は、より堅牢で保守しやすいコードを書けるようになります。

障害のあるユーザーにとって必要な理由

ボタンの色、アイコンの形、レイアウト、チャートや画像といった視覚情報を見ることができないユーザーは、どのように Web サイトを使うでしょうか。答えはスクリーンリーダーなどの支援技術です。このとき、適切な役割（role）、ラベル（label）、代替テキスト（alt）といったアクセシビリティ属性が提供されていないと、必要な情報が得られなかったり、ボタン・リンクなどのインタラクティブ要素を見落として大きな不便を被ります。 たとえば、単にクリックイベントを付けただけの<div>はスクリーンリーダーでボタンとして認識されず、ユーザーがその機能を利用できません。

一般ユーザーにも有用な理由

アクセシビリティを守ると、障害のない一般ユーザーでもWebをより速く、より便利に利用できます。ユーザーが慣れ親しんだWebの挙動が自然に提供されるからです。

たとえば、リンク（<a>）を正しく使えば、右クリックで「新しいタブで開く」「リンクをコピー」などの機能を利用できます。しかし、単に<div>や <span>にクリックイベントだけを付与した場合、こうした基本機能は使えません。 またフォームでは、適切な<form>、<input>、<button type="submit">を使うことで、ユーザーはEnterキーでフォームを送信できます。そうでない場合、ユーザーは期待する既定の挙動を得られません。 加えて、キーボード中心で操作するユーザーは Tab／Shift+Tab、Enter、Space、矢印キーなどでサイトを移動します。ボタンやリンク、フォーム要素に正しい役割やフォーカス管理がされていないと、キーボードでは機能を利用できません。

次の画像は、ブラウザでリンクを右クリックしたときに表示されるコンテキストメニューです。リンク要素を正しく使えば、ユーザーが期待するこうした基本機能をすべて提供できます。

このようにアクセシビリティは、障害のあるユーザーだけでなく、キーボード利用者、そして一般的なWeb体験を期待するすべての人に不便を与えないための基本原則です。アクセシビリティを考慮しないと、誰にでも起こり得る不便が生じます。

アクセシビリティを守ったときに開発者が得る利点

アクセシビリティを適切に守ると、UI テストで要素を特定するのが非常に簡単になります。たとえばtesting-libraryでは、ByRoleクエリで要素を選択することが推奨されています。これを使えば、ボタン・入力欄・リンクなど、役割（role）が明確な要素を容易に見つけられます。

たとえば次のように、名前が「保存」の「ボタン」を明確に取得できます。

// アクセシビリティが適切な場合
render(<button>保存</button>);
expect(screen.getByRole("button", { name: "保存" })).toBeInTheDocument();

同じ名前の要素が複数ある場合でも、上位要素のアクセシビリティラベルを活用すれば区別しやすく、ユーザーにとっても選択が容易です。

// 同じ名前の要素を、上位のアクセシビリティ情報で特定する
render(
  <ul>
    <li aria-labelledby="item1-title">
      <span id="item1-title">りんご</span>
      <button>保存</button>
    </li>
    <li aria-labelledby="item2-title">
      <span id="item2-title">桃</span>
      <button>保存</button>
    </li>
  </ul>
);
const 桃 = screen.getByRole("listitem", { name: "桃" });
const 桃保存ボタン = within(복숭아).getByRole("button", { name: "保存" });
expect(桃保存ボタン).toBeInTheDocument();

一方、querySelectorで要素を選ぶと、マークアップ構造が少し変わっただけでテストが壊れやすくなります。ByTestIdはテスト専用の属性を追加する必要があり、その値がサービスコードに残るという欠点があります。これに対しByRoleを使えば、実ユーザーと同じ方法で要素を探せ、固有の役割を持つ要素を容易に特定できます。これはアクセシビリティに配慮したマークアップ構造があってこそ可能なことです。

// querySelector を使う場合（マークアップ構造の変更に弱い）
expect(
  document.querySelector("ul > li:nth-child(2) > button")
).toBeInTheDocument();

// getByTestId を使う場合（テスト用属性がサービスコードに残る）
render(<button data-testid="save-btn">保存</button>);
expect(screen.getByTestId("save-btn")).toBeInTheDocument();

つまりアクセシビリティは、すべてのユーザーのためであると同時に、開発者にとっても、より堅牢で保守しやすいコードを書く助けになるのです。