はじめに

2024年4月施行の障害者差別解消法の改正の中で、Webサイトに関する取り組み例の文言が追加され、いっそうWebアクセシビリティへの取り組みや理解が求められてるようになってきたのではないでしょうか。
しかし、アクセシビリティ考慮の範囲は膨大で、レガシー環境のエンハンスなどを行っていると（筆者自身の置かれた環境）、どこから手をつけたら良いものか、急に途方に暮れてしまいます。
そこで、フロントエンド観点のみ、かつアクセシビリティ考慮のスコープを小さくし、まずは、日々のコードレビューでよく耳にする「アクセシビリティのためにセマンティックなマークアップをこころがけよう」というところから取り組んでいくことにしました。以下では取り組みのために必要となる基礎知識についてまとめています。

障害者差別解消法の改正について、アクセシビリティの取り組みが義務化されたということではありません。アクセシビリティの取り組みは「環境の整備」に位置付けられる考えで、本記事執筆時点では努力義務です。
参考：今回の改正における新旧対照表
※ウェブサイトの例をとった追加文言については同表の、«改正：イ　合理的配慮と環境の整備内の例２項目に記述されています

セマンティクスとアクセシビリティ

セマンティクスとは

セマンティクスとは、もともと「意味」「意味論」を表す単語です。MDNより引用すると、HTMLにおけるセマンティクスとは、

そのHTML要素には、どのような目的や役割があるのか？

ということを表し、HTMLのセマンティック要素はコンピュータに意味を提供します。

セマンティクスとマシンリーダブル

つまり、セマンティックなマークアップがアクセシビリティにつながる理由は、

セマンティックにマークアップすると、マシンリーダブル（機械可読）になる

からです。
スクリーンリーダーなどの支援技術のテクノロジーにも利用可能になり、コンテンツを使える人の層が増え、アクセシビリティ向上につながります。これはWCAGの挙げている「知覚可能」「操作可能」「理解可能」「堅牢」という4つの原則のうち「堅牢」にあたります。

Webアクセシビリティの根幹の一つがマシンリーダビリティ（機械可読性）です。
マシンリーダブルにすることで多様なアクセスの可能性が広がります。例えば、SEOにおいてもクローラーがウェブサイトの内容を理解できるようにするという点では同理論であり、セマンティックな実装は有効です。
このように支援技術だけにとどまらず、自身のWebサイト外のサービスやアプリケーションに転用できる可能性も広がります。

支援技術では次のようにセマンティクスが伝わります。

アクセシビリティオブジェクトモデル（AOM）

スクリーンリーダーなどの支援技術は、OSがもつアクセシビリティAPIを介してOS上のアプリケーションとやりとりをしてセマンティクスを伝えられます。

アプリケーションはアプリケーションのウィンドウをルートノードにしてアクセシビリティオブジェクトモデル（AOM。アクセシビリティツリーとも呼ばれる）を生成
AOMをアクセシビリティAPIを通して公開
支援技術がAOMを読み取り操作する
ユーザーに伝わる、操作できる
支援技術がユーザー操作を検知
アクセシビリティノード上でアクションを実行する

原文（英語）

AOMの生成

ブラウザが画面描画をするには、HTMLからDOM（ドキュメントオブジェクトモデル）を生成し、CSSからCSSOM（CSSオブジェクトモデル）を生成、2つのモデルを合成し、レンダリングツリーを作成、レイアウト計算、描画を行います。
AOMも同じように、DOMとCSSOMを組み合わせて作成されます。

DOMから名前や役割、状態などのセマンティクスを読み取る
CSSOMからdisplay:none;などのスタイル情報を読み取り反映させる　
※display:none;とした要素は、スクリーンリーダーからも隠される。visibilityプロパティも同様

以下の例では、チェックボックスをカスタムコンポーネントとするため、HTMLネイティブのinput要素をdisplay:none;としています。

html

<input type="checkbox" id="receive-info">
<label for="receive-info">新着情報を受け取る</label>

css

input[type=checkbox] {
    display: none;
}
label::before {
 /* 独自のチェックボックスのスタイル*/
}

このときのAOMはDOMとCSSOMを合成し生成されますが、CSSOMのinput要素がdisplay:none;となるので、input要素が含まれていません。

AOMが提供する情報

AOMは以下の情報を提供し、スクリーンリーダーなどはこれら情報をもとに読み上げを行います。WAI-ARIAにはAOMのプロパティに対応した語彙があります。

Nameプロパティ

オブジェクトの名前
button要素のテキストやlabel要素のテキストなど、要素のテキストノードから取れる
- 上の例でinput要素が表示される場合、input要素のNameはlabelと関連づけられているので、Name:"新着情報を受け取る"となる
WAI-ARIAでは直接Nameプロパティを与えるaria-labelやaria-labelledby属性でも指定ができる

Roleプロパティ

オブジェクトの役割
button要素であれば、Role:buttonとなる。クリック可能であることを伝える。HTML要素にそれぞれ割り当てられている
WAI-ARIAでは直接role属性で指定できる

Descriptionプロパティ

オブジェクトの説明。Nameプロパティより詳細
HTMLではtitle属性、WAI-ARIAではaria-description属性など

その他プロパティ

他にも、Expandedプロパティ（オブジェクトが展開されているか）、Checkedプロパティ（チェックされているか）、Disabledプロパティ（無効か）などの状態プロパティがある
- WAI-ARIAではaria-expanded,aria-checked,aria-disabledなど
また、Busyプロパティ（要素内が変更されている途中か）など、HTMLネイティブがもたない属性もある
- WAI-ARIAではaria-busyなど

AOM適用の優先順位

セマンティクスの優先順位は、 WAI-ARIA >（CSS + HTML） となり、WAI-ARIAが最も優先されます。

WAI-ARIAが優先されるのは基本的にはどのブラウザでも同じだが、CSSによるRoleの変更はブラウザによることがある
WAI-ARIAは、role属性とaria-*属性を個々に指定できるが、p要素がchecked属性をとれないように、ある程度組み合わせが定めらている
HTMLとWAI-ARIAについても許可された組み合わせがあり、ARIA in HTML日本語訳にまとまっている
※元ページ（英語版）：ARIA in HTML

WAI-ARIAはHTMLセマンティクスの補完

これまで見てきたように、WAI-ARIAは支援技術にアクセスできる有効な手段ですが、以下の理由からHTML要素の使用が可能であればHTML要素を使うことを基本とし、使用できない場合の補完としてWAI-ARIAを使用するようにしましょう。

前項「AOM適用の優先順位」の注意事項にあるように、WAI-ARIAには使用のルールがあり、間違えて使用するとユーザーの混乱を招く可能性がある
WAI-ARIAではbutton要素やa要素などのインタラクションの補完はできない。HTMLの要素が使用できないのであれば、JavaScriptなどから機能を追加しなければならず、コーディングコストがかかる
ブラウザによってはWAI-ARIAを理解できない、一部の機能がサポートされていないが、HTMLのセマンティクスならサポートしている場合がある

おわりに

アクセシビリティ取り組みのアプローチはプロジェクトの環境に依存するところが大きいため様々ですが、適切なマークアップを行うだけでマシンリーダビリティの多くは担保されます。ベースができていれば、次の目標にもスムーズにつなげられます。（「スクリーンリーダー対応を目標にする」、「キーボード操作など要素のインタラクションをテストして足りない機能を追加する」など）

「WCAGの基準AAに準拠させよう」とすると範囲が膨大となって挫折したり、いきなり「WAI-ARIAを学んで記述しよう」とすると、学習コストがかかり、かえってアプローチとしては遠回りになる可能性があります。まずは、小さいスコープで改善観点をシンプルにし、できるところから取り組んでいきましょう。

その他参考

書籍：「Webアプリケーションアクセシビリティ――今日から始める現場からの改善」伊原力也，小林大輔，桝田草一，山本伶　著（出版：技術評論社）
内閣府ホームページ：リーフレット「令和６年４月１日から合理的配慮の提供が義務化されます！」
MDN：Accessibility tree (アクセシビリティツリー)
MDN：ARIA の状態とプロパティ