はじめに

前から気になっていたWAI-ARIA（ウェイアリア）。
HTML5 Conference 2018に参加して、WAI-ARIAをマークアップ以外の視点から掘ってみたいと思ったので記事を書いてみようと思いました。

基本的内容からつらつら書いてみています。大まかな流れが頭の中に入りやすいように、細かい専門用語は控え目にしてみています。

WAI-ARIAってなんですか？

⇒ WAI-ARIAはHTMLタグだけでは表現できない。セマンティクスを補強してくれる。

状態を表す属性とかあって、js, cssのセレクタとして利用できたら便利！
[is-selected]クラスを付与するより[aria-selected]属性を付与して状態を表現できたほうがコードが読みやすそう。
→やってみたーい！
が引き金

でも待てよ。
何だか「もやっと」する。
js, cssのセレクタとして利用できるってのはあくまで技術者にとってのメリットなんだよなぁ。

⇒ WAI-ARIAは誰のため、何のためのものなのだろうか？

誰のためというのは、健常者だけではなく支援技術が必要な人も含めたみんなのため。
何のためというのは、セマンティクスを補強し、検索エンジンの評価やSEO・アクセシビリティ・メンテナンス性を向上させるため。
支援技術とは、スクリーンリーダーだったり、点字キーボードだったりといったもの。

webを閲覧するうえで、健常者だけではなくみんなが使えるようになったらいいよね。という思想がもとになっている。

ではどのようなプロセスを経て支援技術が利用できるに至るのだろうか？

ブラウザ　⇔　OS ⇔ 支援技術

アクセシビリティツリーはOSが支援技術とやり取りをするときに必要。
htmlタグのセマンティクスと、WAI-ARIAのセマンティクス情報を持ちあわせている。

⇒ アクセシビリティツリーがどうやってできるのかが気になる。

ブラウザがアクセシビリティツリーを生成するのですが、アクセサビリティツリーを説明するためには、レンダリングツリーとは何かを抑えておく必要がある。

レンダリングツリーの説明も含めて、ブラウザが画面を描画するまでの流れを追ってみます。
とはいえ、あんまり詳しく書くと本題からそれてしまいそうなので、大まかに。

html構造から、DOMツリー・CSSOMツリーを生成する。
- DOMツリー生成中にcssの読み込みが発生する。このタイミングで CSSOMツリーの生成も発生する。
- 上記２つの生成が完了
DOMツリーと、CSSOMツリーのを組み合わせてレンダリングツリーを作る
- DOMツリーのルートから処理していく。この時スタイルでdisplay:none;されている要素は処理から除外
- DOMツリーのノードを処理するたびに、当てはまるCSSOMルールを適用させる
- 全部終わったら出力。これがレンダリングツリー
レイアウト処理を行う
- レンダリングツリーのルートからノードの大きさの解釈をしていく。
描画する（ペインティング・ラスタライジングともいう）
- 画面の大きさから、レンダリングツリーの大きさをピクセル変換する。
描画に至る。

⇒ アクセシビリティツリーは上記で作ったレンダリングツリーをWAI-ARIAで補強したもの。

アクセシビリティツリーはChromeであれば、要素検証の「Elements」パネルから「Accessibility」ペインを開くことで確認することができます。

この記事を読んでWAI-ARIAについて「もやっと」していた方が少しでも「スッキリ」になりましたら幸いです。