コーディングWebアクセシビリティと僕

Webアクセシビリティ Advent Calendar 2020 の16日目の記事です。

現在の僕のアクセシビリティに対するスタンス

アドベントカレンダーぐらいしかこういうポエムを書く機会がなさそうなので書いてみます。

東京都での COVID-19 オープンデータのサイトの件が印象的でしたが、アクセリビリティは「守らなければならないこと」のような印象がやや強まりつつあるかな、と思うところがあります。

アクセシビリティなんて完璧であればあるほど良いものなんでしょうが、コスト・時間がかかり、自由度も下がる。また、実装者が当事者じゃないというメンタルモデルもあり、完璧にはできないところもある、という現状かと思います。

正直なところを言うと、僕も当事者となることがあんまりないので、そんなに意識は高くなく、後述する恩恵以外で言うと、一種のマナーと僅かな思いやりとして実装するにとどまっています。これを「守らなければならないこと」として課せられると、特にやりたいことと競合したときに、しんどいな〜と気持ちが上にならざるを得ません。

そういう中でも僕がアクセシビリティに関心を持っている理由は、Webのコーディングという範囲に限定すると、アクセシビリティの先にセマンティクスの強化があるからです。

アクセシビリティに気をつけてコーディングを行うとセマンティクスがより適切になり、実装・管理しやすくなります。

どちらかと言うと本来は逆で、セマンティクスを強化した結果として、アクセシビリティについての恩恵が発生している、というほうが合っているんじゃないかな〜と思います。

そういうわけで、僕の考えるアクセシビリティというのは、結果として Accessibility ⇒ Semantics ⇒ Accessibility + Developer Friendly という理想があるな、というところで「守らなければならないもの」とするよりは興味関心がもてるな、そうなればいいのにな、というモチベーションでいつも記事などを書くようにしています。

前置きが長くなりましたが、今回の記事では、コーディングのアクセシビリティについて知った、WAI-ARIAという存在を知った、じゃあ実装しよう、実装している、というあたりで妙に躓いた、あまり大したことないところをまとめることにしてみます。

（余談：今回の記事タイトルは、コーディングのアクセシビリティを知ったきっかけが「コーディングWebアクセシビリティ」というタイトルの本だったことに由来しています。）

なぜ「WAI-ARIA より HTML のほうを優先すべき！」？

WAI-ARIA に関する初学者向けの情報を読むと「WAI-ARIA より HTML のほうを優先すべき」という話がよく書いてあります。（例：WAI-ARIAの基本 MDN）

しかし、どうしてそうなのかについては、あまり書かれているものを見たことがありません。その上、YouTube なんかを見ると、WAI-ARIA を使いまくりで、むしろ div, span 以外の HTML 要素のほうが少ないんじゃないか？と思うぐらいまであり、どういうことなんだろうと思ったことがありました。

理由はいくつかあると思いますが、

• WAI-ARIA は基本的にはセマンティクス(意味づけ)を保証するもので、動作を保証するものではない
  • 例えば、aria-pressed="false" をつけただけではダメで、押したら true になるような JavaScript を書いたりする必要があります
• HTML 要素であれば、環境に応じたUIを表示することができる
  • 例えば、日付選択 <input type="date"> や <select> 要素は、PC とスマートフォンで UI が異なるのを知っていますか？（「input type="date" HTML UI」Google 画像検索）
  • Bootstrap で作られたドロップダウンをスマートフォンで見ると、結構選びにくいことがあります
• WAI-ARIA でのセマンティクスの付加は慎重にやらないと不整合が起こる
  • ドロップダウンメニューひとつでも、結構 WAI-ARIA をつけるのは難しいものです、失敗するとセマンティクスが崩れ、読み上げもうまくいかないことがあります。
• リーダーによっては対応していない WAI-ARIA 属性がある
  • と、聞いたことがありますが、案の定当事者でないのでちゃんとわかってません。

あたりが、僕の理解です。

が、HTMLを書いていると

• HTML のネイティブ要素をCSSでスタイリングしようとすると柔軟にできず、満足にできない部分がある
  • <input type="radio"> とか、 display: flex な <button> とか
• ページ上に UI をたくさん配置するような Web アプリを開発するとき、HTMLのセマンティクスだと無理がある
  • 機能のパネルは <section> で囲うべきですか？
  • そうであればその中に見出しタグをつけるべきですか？
  • ラベルのテキストは頻出ですが <label> タグは意図しない動作や使用シーンが自然にマークアップできないことがあります・・・。

ということが合ったりするので、超理想形としては上の懸念を満たした上で WAI-ARIA を積極的に使うべきだと僕は考えています。・・・超理想形としては、ですよ。

WAI-ARIA を使った実装をするときに参照すると良いところ

実際に WAI-ARIA を使って実装するときに一番困ったのは「そのマークアップは正しいか？？？」ということでした。

初学者向けの本や情報でも、わりとごく当たり前なレベルのUIしか書いてなく、実務で扱う複雑な UI だと結構混乱しました。仕様を読み込んだりして、頑張って実装していましたが、仕様を読んで落とし込む、というのはやっぱり大変な作業です。

Web アプリケーションを実装する上で大きく助けになったのは、以下の２つでした。

Material Design - Web Component

各 UI をクリックすると「Implementation」というタブがあり、その中の example で書かれている HTML がとても参考になります。
WAI-ARIA 属性がしっかり書かれていて、ベストプラクティスとして参考にしているものの一つです。

Adobe Spectrum (Spectrum CSS)

こちらも Material Design 同様、UI Component 集です。
React Spectrum もありますが、未実装のコンポーネントも割とあるので、Web Component 版であるこちらのほうが良いかと思います。
WAI-ARIA のプラクティスとしても良質な上、Material Design にはないが、アプリケーションとしてよく使われるコンポーネントが多く参考になります。

さて、欲張ったら結構な分量になってしまいました。

来年もみなさまにとって良い年でありますように。