State of HTML 2023にみるアクセシビリティの現状

先月の話になりますが、State of HTML 2023の結果が公開されました。フロントエンド開発者の方であれば、State of JavascriptやState of CSSをご存じの方もいると思いますが、これらのHTML版ということになります（アクセシビリティBlogでは過去にState of CSS 2023に見るアクセシビリティ関連機能という記事もあります）。State of HTMLのもう少し詳しい説明については、アンケートの設計を主導したLea Verou氏のBlog記事Help Design the Inaugural State of HTML Survey!を参照してください。

さて、内容の方を見ていきたいと思いますが、この記事では特にアクセシビリティの側面から調査結果を眺めていくことにします。（正面からの話題については、当社のUI開発者がフロントエンドBlogあるいはミツエーテックラジオで取り上げる...かもしれません。）

アクセシビリティに関しては、Accessibilityのページにまとめられています。このページでは、調査が実施された42の機能のうち、ランドマーク要素、tabindex属性、<search>要素、focusgroup属性の4つに絞り込まれますが、例えばautocomplete属性はFormsに分類されており、Accessibilityのページ以外にもアクセシビリティに関連する機能が存在することに注意が必要です。

この調査におけるランドマーク要素というのは、<main>, <nav>, <aside>, <header>, <footer>, <section>の6つの要素をまとめて指しており、同様なランドマークロールを持つ<search>要素が、あえてわけられているのが興味深いところです。もっとも、MDNのsearch要素でもわかるように、<search>要素は2023年10月に主要ブラウザーの実装が出そろった新しい機能ですから、別項目として設問を設けるのは自然な流れといえるでしょう。

調査では、ランドマーク要素と<search>要素を「Used it（使っている）」と答えたのはそれぞれ95.6％、11.8％となっています。ランドマーク要素は、一定規模のモダンなWebサイトであれば見かけない方がまれであり、筆者のアクセシビリティ検証の業務を通じた肌感覚ともよく合っているように思われます。一方、<search>要素を見かけた記憶は乏しいです。<search>要素については「Heard of it（聞いたことがある）」が27.3％となっていることから、これから徐々に浸透していくのではという楽観的な予測が立つでしょう。

tabindex属性を使っていると答えたのは81.8％となっています。HTMLネイティブの要素では実現できないインターフェイス機能を実装する場合に、キーボード操作を制御するにはtabindex属性が必要不可欠ですから、使わざるを得ないというのが実情ではないでしょうか。「Negative（否定的）」と答えたのが4.2％ですが、これはAccessibilityに分類されている機能で最も高くなっています。

focusgroup属性ですが、これはまだ仕様になっておらず、Open UIにfocusgroup (Explainer)として存在しているものです。実装もChromeで試験的に実装されているFeature: Focusgroupのみであり、使ったことがあるという回答も1.5％に過ぎません（聞いたことがあるという回答は18.3％）。これはキーボードの矢印キーでのナビゲーションなどの機能を提案するものであり、場合によってはtabindex属性を使うことなくキーボード制御できるようにするという提案です。仕様・実装とも不足していますから、今後に期待といったところでしょうか。

Accessibilityのページ以外にまとめられている機能についてもざっくりと触れたいと思います。

前述のautocomplete属性は、47.9％が使っている、28.2％が聞いたことがあるという回答になっています。よくできているページではautocomplete属性が見られますから、こんなものかな...という感想です。自動補完を無効にしたいというコメントや、そもそもブラウザーの実装が信頼できない、（日本での）住所の書式にマッチしないというようなコメントが目に付きました。

HTMLネイティブで開閉できる<details>/<summary>要素、ダイアログのための<dialog>要素も設問として登場しています。使っているのが46.7％と31.2％、聞いたことがあるのが25.9％と46.2％とそれぞれなっており、7割ほどの回答者に知られています。両者ともに100を越えるコメントが寄せられているのが興味深いところです（全体で上から数えた方が早い数）。単純な機能としては使えるものの、カスタマイズ性に乏しいという意見が多いように見受けられます。裏を返せば、そのような機能はARIAで実装せざるを得ないという状況でしょうか。

inert属性も調査結果が見られます。「不活性化」をする属性であり、かれこれ10年近く議論されていたと記憶していますが、ようやく2023年に主要ブラウザーの実装が出そろった機能です（MDNのinert属性）。6.4％が使っている、14.2％が聞いたことがあるという回答となっており、思ったよりも知名度がないことが少し意外でした。aria-hidden属性と何が違うのか、というようなコメントが見られました。

最後に、Pain Points（問題点）の設問について触れておきましょう。各機能のカテゴリーごとに問題点を自由記述で回答するものですが、その中の「What are your pain points around HTML forms?」（HTMLフォームに関する問題点は何か？）という質問に対して、「Styling & customization」に関して3652（！）ものコメントが寄せられました（Pain Pointsの設問では最も多い回答数）。この調査に参加したのは20000名ほど（ただしアンケート完了状況にはばらつきがある）ですから、参加者の実に2割ほどがHTMLフォームのスタイルやカスタマイズに明確に不満を述べていることになります。

この調査結果に呼応するように、5月にOpenUI、WHATWG/HTML、CSSWGの3グループの合同ミーティングが2回開催され、HTMLフォーム要素のスタイルに関する議論が行われています（CSS WG Blogの5月8日、5月23日の議事録）。

特にフォーム関連については、HTML標準の見た目が貧弱ということもあって、見た目のためにカスタムインターフェイスが実装されることがよくあります。しかし、アクセシビリティ検証を行うと、マウスやタッチ操作が前提でキーボードで操作できない、あるいはWAI-ARIAが提供されないか、提供されても不正確な実装が多数見受けられます。

前述の合同ミーティングを起点として、関連する標準策定の議論が加速すると思われる一方、HTML属性、APIあるいはCSSプロパティが充実するにはまだまだ時間がかかるでしょう。複雑なインターフェイスについては、よくアクセシビリティについてテストされたフレームワークやコンポーネントを活用する、あるいは自前で実装するのであればARIA APGに沿って実装をするというような方法で、アクセシブルなHTMLフォームを実現していただくとよいのではないかと思います。