「間違った ARIA を使うより ARIA を使わない方が優れている」APG でアクセシビリティを学ぶ。
こんにちは、上條(mk-0A0)です。
弊社 Gaji-Labo はスタートアップ支援のプロダクト開発支援をしています。
より良いプロダクトになる支援ができるようアクセシビリティを意識した実装についても日々勉強しているのですが、その中で私が参考にしているものの1つが『APG』と呼ばれるガイドです。今回はこの APG についてご紹介したいと思います。
APG とは
ARIA Authoring Practices Guide の略で、ARIA の定義をもとにしたアクセシブルな UI を学べるガイドです。HTML, CSS, JavaScript と ARIA の組み合わせや、アクセシブルな名前の提供やキーボード操作の方法などが学べます。
ここで紹介されているものは WCAG や ARIA のような規約やデザインシステムの役割は持っておらず、あくまでアクセシビリティの概念を学ぶためのものになっています。
APG は主に以下4つのセクションで構成されています。
- Patterns:アクセシブルな UI パターンの要件
- Practices:アクセシブルな名前の提供やキーボード操作の有効化など、アクセシビリティの要件を満たす方法
- Index:role や ARIA プロパティ、ステートで分別された UI パターンの Example 一覧
- About:APG の概要
4つのうち利用する頻度が高いのは Patterns と Practices だと思います。これらが主体のコンテンツですが、まずは APG を利用するうえで押さえておきたいページを見ておくとより理解が深まると思うのでご紹介します。
はじめに押さえておきたいこと
APG 内のいくつかのページでアナウンスされていますが、まずはじめに読むことを推奨されているページがあります。
タイトルからしてそのまんまですね。この Read Me First には、APG を利用するうえで必要な前提知識や 注意点が書かれており、ざっくり以下のような内容です。詳しくはぜひ本家を読んでみてください。
- 間違った ARIA を使うより ARIA を使わない方が優れている
- スクリーンリーダーを使うユーザーにとって ARIA はページ内のコンテンツを伝える役割を持つため、正確でない ARIA を使うと非視覚体験に影響が出る可能性がある
- 2つの基本原則を理解して ARIA を取り入れる必要がある
- その role を持たない HTML 要素に role を指定した場合、キーボード操作などの機能も提供する
- ARIA は HTML 本来のセマンティクスを良くも悪くも上書きできてしまうため、意図せず適切でない上書きをしてしまう可能性がある
- APG の目的は ARIA 1.2 の適切な使い方の説明であるため、サンプルコードはブラウザや支援技術の問題を回避する設計になっていない。そのため各ブラウザや支援技術の相互運用性のテストは必要である
- モバイル端末やタッチ操作との互換性は示していない
- モバイル端末やタッチ操作でサポートされていない ARIA の機能もある
- ブラウザ間でのタッチ操作が標準化されたアプローチはまだないが、詳しいガイドのリリースは今後予定されている
ここで理解しておく必要があるのは1番目の 間違った ARIA を使うより ARIA を使わない方が優れている
だと思っています(原文:No ARIA is better than Bad ARIA)。Patterns や Practices のページトップに設置されている Read Me First への導線でもこの文言が強調されていることから、APG が特に重要視していることだと捉えました。
有名な話ですが、ARIA は使えば使うほどよくなるものではありません。良かれと思って使ったものが逆に情報を正しく伝えられない可能性もあります。コードをただそのまま使うのではなく、その環境に本当に必要なものかを考えて取捨選択する必要がありそうです。
どんなことが書いてある?
Read Me First で最低限知っておくべき ARIA の特性が分かったところで Patterns や Practices を見ていきましょう。
まず Patterns にはアコーディオンやカルーセル、ダイアログなど約30個の UI パターンが掲載されています。
各パターンの内容は以下の構成になっています。
- About This Pattern:UI の要件
- Examples:サンプルコード
- Keyboard Interaction:必要なキーボード操作
- WAI-ARIA Roles, States, and Properties:UI で使用される ARIA
Examples があるとつい先にそちらを見がちですが、サンプルコードは Keyboard Interaction や WAI-ARIA Roles, States, and Properties を踏まえたものになっているので、個人的には先にそれらを把握してから Examples を見るとより理解が深まるなと思っています。
次に Practices にはランドマークやアクセシブルな名前、キーボード操作など、必要とされるアクセシビリティの要件を満たす方法が7つ掲載されています。
こちらは私もまだあまり読み込めてないので、お盆休み中(執筆当時はお盆休み前でした)のお供として目を通したいと思っているところです。
アクセシブルな名前・説明のセクション、Providing Accessible Names and Descriptions のボリュームにだいぶ圧倒されていますが、それだけ重要なポイントだと捉えて理解を深めていきたいと思っています。
まとめ
APG の Example(サンプルコード)は見たことあるけど、そもそも APG がどういうものかよく分からないという方は意外と多いのではないでしょうか。APG でより理解を深めるための参考になれば嬉しいです。次回は APG で紹介されているパターンから1つピックアップして書いてみようと思います。
Gaji-Labo は「アクセシブルな UI」について語りたいエンジニア・デザイナーの方とお話ししたいと思っています。興味のある方、ぜひカジュアル面談でお話ししましょう!
Gaji-Labo は新規事業やサービス開発に取り組む、事業会社・スタートアップへの支援を行っています。
弊社では、Next.js を用いた Web アプリケーションのフロントエンド開発をリードするフロントエンドエンジニアを募集しています!さまざまなプロダクトやチームに関わりながら、一緒に成長を体験しませんか?
もちろん、一緒にお仕事をしてくださるパートナーさんも随時募集中です。まずはお気軽に声をかけてください!