アクセシビリティの対応は、要件定義段階から設計したりなど大変そうなイメージはあります。実際に本格的に対応するにはどの達成基準を目標にするか決めたり、入念なテストが必要になるなど確かに一朝一夕で対応できるわけではないでしょう。 ですが、完璧な対応を目指すのではなく、少しづづ改善できるところから進めることこともできます。実際にやってみると、簡単な HTML や CSS のコードの修正でもよい改善を得られたりします。 この記事では比較的低コストで実践入門できるアクセシビリティの改善を紹介します。
フォーカストラップ(またはループ)とは、ウェブページをキーボードで操作する際にフォーカスをとある領域からはみ出さないようにすることです。フォーカス可能な要素を抽出してその中をループすることで実現ができます。 登場シーンとしてはモーダルで使われることが多いです。実際に例を交えて確認してみましょう。
タブとは、ページ内でコンテンツを切り替えるために使用する UI です。タブ初期表示ではいずれか一つのタブパネルが表示されており、関連するタブがアクティブなスタイルで表示されます。それぞれのタブには関連するタブパネルがあり、タブを選択することで表示されるタブパネルがタブに関連するものに切り替わります。
アコーディオンは見出しであるヘッダーとコンテンツであるパネルから構成された UI が垂直に積み重ねられたセットです。ユーザーはヘッダーをクリックすることで、ヘッダーに関連付けられたパネルの表示・非表示を切り替えることができます。 アコーディオンは1つのページ内で複数のセクションのコンテンツを表示する際に、スクロールを減らすためによく 使用されます。例えば、「よくある質問」のようなページで使われていることを見たことがあるかと思います
Pa11y とは Web Content Accessibility Guidelines (WCAG) をベースに HTML のアクセシビリティを検査するツールです。適合レベル AA を対象にテストします。Pa11y にはいくつかの種類がありますが、その中でも Pa11y CI は CI 上で実行することにフォーカスしています。
HTML Standardに新しい`<search>`要素が追加された。これまで、ARIAには`<search>`に相当するHTML要素がなかったため、`<div role="search">`しか代替要素がなかった。新たに`<search>`要素を使用することにより、WAI-ARIA を使用せずともsearchランドマークを定義できるようになった。通常、`<search>`要素は少なくとも1つの入力要素を含んでおり、検索を開始するためのボタンもあることが期待されている。
ウェブアプリケーションエンジニアを対象に、アクセシビリティの対応について解説した記事。アクセシビリティを向上させるためには、正しいHTMLの書き方が必要である。HTML要素には、アクセシビリティに関する機能が元々備わっているため、適切なHTMLを選択し使用することが大切だ。複雑なUIの場合はWAI-ARIAを使用し、ARIA Authoring Practices Guideに基づき適切に実装する必要がある。UIライブラリ選びの際には、WAI-ARIAに従った実装を行っているかが基準の1つとなる。
今日の Web におけるフォームはユーザーが情報を入力して対話するための重要な要素です。支援技術を利用しているユーザーがフォームの入力を妨げられることは当然避けるべきでしょう。また障害の有無に関わらず、ユーザーに迷いを与えたり、入力ミスを誘発するようなフォームはユーザーがタスクを完了せずに途中で離脱してしまう可能性が高まり、ビジネスの観点からも望ましくありません。この記事ではフォームのアクセシビリティについて考え、実際のフォームの実装においてどのような点に注意すべきかを紹介します。
aria-label 属性はコンテンツに対してアクセシブルな名前を与えるために使用します。aria-label 属性を使用する代表例として、中身がアイコンのボタンがあげられます。aria-label 属性は手軽に使えますが、できる限り一般的な形式でテキストを提供することが望ましいです。
Virtual Screen Reader は単体テストのためにスクリーンリーダをシミュレートするライブラリです。このライブラリを使うことでマウスやキボードの操作をテストするように、スクリーンリーダーにより期待する読み上げが行われるかどうかをテストできます。なお、Virtual Screen Reader はあくまでスクリーンリーダーの挙動を模倣したものであり、現実で使われているスクリーンリーダーによるテストを代替するものではないことに注意してください。
