#アクセシビリティ

ダイアログをアクセシビルに実装するための要件を確認しましょう。

今日の Web におけるフォームはユーザーが情報を入力して対話するための重要な要素です。支援技術を利用しているユーザーがフォームの入力を妨げられることは当然避けるべきでしょう。また障害の有無に関わらず、ユーザーに迷いを与えたり、入力ミスを誘発するようなフォームはユーザーがタスクを完了せずに途中で離脱してしまう可能性が高まり、ビジネスの観点からも望ましくありません。この記事ではフォームのアクセシビリティについて考え、実際のフォームの実装においてどのような点に注意すべきかを紹介します。

WAI-ARIA における role 属性を使用する際のプラクティスとして、暗黙のロールを明示しないというものがあります。しかし、`<ul>` 要素は暗黙のロールとして `list` ロールを持っていますが、明示的に `list` ロールを宣言するべきです。

axe-core は axe というアクセシビリティテストツールのコアエンジンで、オープンソースとして提供されています。この記事では、E2E テストフレームワークの Playwright と axe-core を組み合わせて使用して、アクセシビリティテストを自動化する方法について紹介します。

リストボックスにアクセシビリティ上求められる要件を確認した後に、React で実際に要件に従った実装をおこないます。

フォーカストラップ(またはループ)とは、ウェブページをキーボードで操作する際にフォーカスをとある領域からはみ出さないようにすることです。フォーカス可能な要素を抽出してその中をループすることで実現ができます。 登場シーンとしてはモーダルで使われることが多いです。実際に例を交えて確認してみましょう。

prefers-reduced-motion とは、ユーザーの環境設定によって余計な動きを抑制することを要求したことを検出するメディアクエリです。この設定は各 OS ごとに設定できます。ユーザーがアニメーションを無効にできることは、アクセシビリティの観点で重要です。prefers-reduced-motion によりアニメーションを無効にするのでも十分ですが、アプリケーションの設定として持たせるべきだと考えています。

HTML Standardに新しい`<search>`要素が追加された。これまで、ARIAには`<search>`に相当するHTML要素がなかったため、`<div role="search">`しか代替要素がなかった。新たに`<search>`要素を使用することにより、WAI-ARIA を使用せずともsearchランドマークを定義できるようになった。通常、`<search>`要素は少なくとも1つの入力要素を含んでおり、検索を開始するためのボタンもあることが期待されている。

Pa11y とは Web Content Accessibility Guidelines (WCAG) をベースに HTML のアクセシビリティを検査するツールです。適合レベル AA を対象にテストします。Pa11y にはいくつかの種類がありますが、その中でも Pa11y CI は CI 上で実行することにフォーカスしています。

例えばフォームの項目になにか入力されるまで、送信ボタンを無効にしたい状況があるかと思います。このような場合には `<button>` に `disabled` 属性を与えることでフォームの送信を無効にできます。`disabled` 属性はデフォルトでコントロールを無効にする一般的に期待されるすべての機能を提供するため、多くの場合はこの属性を使用するべきです。しかし `disabled` 属性には 1 つ問題点が存在します。それは Tab キーによるフォーカスができなくなるという点です。

ウェブアプリケーションエンジニアを対象に、アクセシビリティの対応について解説した記事。アクセシビリティを向上させるためには、正しいHTMLの書き方が必要である。HTML要素には、アクセシビリティに関する機能が元々備わっているため、適切なHTMLを選択し使用することが大切だ。複雑なUIの場合はWAI-ARIAを使用し、ARIA Authoring Practices Guideに基づき適切に実装する必要がある。UIライブラリ選びの際には、WAI-ARIAに従った実装を行っているかが基準の1つとなる。

Tab キーでページを操作した時のみ表示される「ナビゲーションをスキップ」は一般にスキップリンクと呼ばれるものであり、ウェブアクセシビリティのガイドライン (W3C 勧告) である WCAG 2.0にあるブロックスキップと呼ばれる達成基準を達成する方法として上げられています。