Web Almanac 2021に見るWebアクセシビリティ

2022年におけるフロントエンド開発のベースライン - LINE ENGINEERINGという記事でアクセシビリティについて触れられているのを目にしました。この記事では、The 2021 Web AlmanacというレポートのAccessibilityの章をもとにアクセシビリティの主だったデータをピックアップして紹介しています。

ここではLINE ENGINEERINGの記事からほんの少し見方を変えて、Web Almanac 2021のアクセシビリティのデータを眺めてみたいと思います。

言語属性について

Language identificationのセクションでは、lang属性についての言及があり、全体の80.5%が妥当な属性値を設定できているとあります。

Web Almanac 2021はワールドワイドなデータでしょうから、仮に例えば漢字文化圏のサイトに限ってlang属性のデータが取得して計測したとしたら、もう少しよい結果になるかもしれません。

これは、WCAG 2.1達成基準3.1.1の解説書に「ビジュアルブラウザは、文字や書体を正しく表示することができる。」とあるように、lang属性の値でブラウザーが（漢字の）フォントの選択を行っていて、漢字文化圏のコンテンツ制作者はそのことを念頭に適切なlang属性をラテン文字圏よりも記述しているだろうという推測に基づきます。

いずれにせよ、5ページのうち1ページはそもそもlang属性が与えられないために、スクリーンリーダーの読み上げでうまくいかない可能性があるということになります。

input要素のラベルについて

Figure 9.14. Where inputs get their accessible names fromのグラフで、input要素のアクセシブルな名前がどのように解決されたのかが示されています。

このグラフのデータを詳しく見る前に、<input type>について簡単に触れておきたいと思います。MDNの<input>: 入力欄 (フォーム入力) 要素を見てもわかるように、type属性の取る値は全部で22種類になります。

例えばtype=submitの場合、value属性を与えれば、それがフォームコントロールの名前になります。一方で、グラフの項目に目を向けますと、"attribute: value"（全体の3.9%）という項目があります。このことから、type=submitや（input要素で真っ先に思い浮かべるだろう）type=textを一緒くたにしたinput要素のデータになっているのだろうという推測ができます。

さすがにtype=hiddenがこのグラフでカウントされていることはないと思いますが、いずれにせよ、グラフの元データの中でどのようなtype属性の分布になっているのかは、グラフからは読み取ることはできないでしょう。

そういった状況を頭の片隅に置いておきつつ、グラフから読み取れる上位3項目のデータを取り上げてみますと、

• No accessible name - 32.7%
• relatedElement: label - 27.4%
• placeholder - 25.3%

となっています。アクセシブルな解決を計算するにあたって、label要素で名前が解決されるのが約27%、「ラベル」による名前解決ができずにplaceholder属性値にフォールバックするのが約25%、HTML上で何の手がかりもないためにアクセシブルな名前を与えられないものが約33%ということになります。

アクセシブルな名前がないinput要素が最上位であるというデータから目をそらしつつも、これら上位3項目で全体の85%を占めており、おおまかにはこれら3つが拮抗してinput要素の名前解決がされているといえます。つまるところ、スクリーンリーダーのユーザーは、3回に1回は名前がないので何の入力欄かわからず、また1回はplaceholder属性値による信頼性のない名前が伝達され、残りの1回はlabel要素による信頼できるラベルが提供されていることになります。

alt属性について

画像の代替テキストを設定するというWebアクセシビリティの入り口ともいえるだろう<img alt>について、Web Almanac 2021では属性値の長さというグラフでデータを示しています（Figure 9.19. alt attribute lengths）。

ここで注目すべきはNo alt、つまりalt属性そのものが記述されていないものが19%にものぼるという結果でしょう。HTMLの仕様上、alt属性を記述しなくてもよい場合というのは極めて限定的ですから、alt属性のない画像はアクセシビリティ上の不備といっても差し支えありません。このことから、少なくとも5つのうち1つの画像は、代替テキストを一切考慮せずに画像が提供されており、スクリーンリーダーのユーザーにはその画像が理解ができないことになります。

tabindex属性について

Figure 9.10. tabindex usageでは、tabindex属性が見つかったページのうち、デスクトップページでは8.7%のページがtabindex属性値に正の数を与えられているとのことです。Web Almanac 2021でも触れられているように、一般にtabindex属性値に正の数を指定するのはよい影響を与えることはなく、キーボード操作を妨害しているといってしまってもよいでしょう。

Web Almanac 2021の本文では、デスクトップサイト全体の58%で、何らかのtabindex属性が設定されているとあります。単純に計算すると、少なくとも20サイトに1サイトは誤ったtabindex属性の設定をしているということになります。

もっとも0以下の値を設定していて、意図したとおりにタブ順序が設定できていないというパターンもあるでしょうから、tabindex属性が原因でフォーカス順序の達成基準の問題を起こしているサイトはもっと多くなることになるでしょう。

フォーカスインジケーターについて

Focus Stylesのセクションによれば、:focus { outline: none; }あるいは:focus { outline: 0; }を指定しているページが9割を超えるとのことです。もっとも、疑似クラスに対するカウントデータかと思いますので、実際のページの90%が明示的にフォーカスインジケーターを消しているということではない、という理解ではいます。

しかしながら、例えばリンクボタンを考えると、フォーカスが当たったときにボタンのコントラスト比が変化すれば、キーボードで操作するユーザーにフォーカスが当たっていることが伝わるわけです。よって、アウトラインを消すことがそのままキーボード操作を阻害するわけではないことには注意が必要です。

ここで立ち止まって考えたいのは、わざわざoutlineプロパティでアウトラインを「消す」という選択をしているページが9割にのぼっているということでしょう。

話は変わりますが、Google DevelopersにChrome のフォーム コントロールとフォーカスのアップデートという記事が掲載されたのは2020年4月のことでした。Chromeで新しいインジケータースタイルに取って代わったのはたかだかここ2年のことです。

多くの人はデフォルトのインジケーターに不満があるからこそ、インジケーターを消してしまうという悲劇が起こっているのではないでしょうか。言いかえるならば、ブラウザーがフォーム関連の機能に貧弱なスタイルを提供していた（あるいはしている）一方で、コンテンツ制作者がそのスタイルを簡単に変更できない、という環境が根本の原因といえるのではないでしょうか。

最後に付け加えておくと、策定中のWCAG 2.2のフォーカスの可視化では適合レベルがレベルAに変更予定です。

コントラスト比について

22%ほどのサイトがコントラスト比のテストに失敗しているとありますが、何とも皮肉なことに、まさにコントラスト比に言及しているグラフ（Figure 9.1. Mobile sites with sufficient color contrast.）そのものがコントラスト比4.5:1を満たせていません（例えばグラフ中の文字「2021」）。ですから、機械による自動テストに加えて人間の目で見てテストをすれば、実際はもっと悪い数値になると思われます。

ただし、WCAG 2.1の視点で見ますと、コントラスト比の達成基準はレベルAAという位置付けではあります。つまり、達成基準のレベルという観点だけでならば、レベルAAであるサイトのコントラスト比の改善よりも前に、より最低限で基本となるレベルAの達成基準について改善をすべしということにはなります。

もちろんコントラスト比を改善することも重要ですが、ここまで取り上げてきた「言語属性」から「tabindex属性について」まではすべて適合レベルA相当のものになってきます。まずはここから取り組むべきでしょう。

また、コントラスト比に関しては、APCAと呼ばれる新たなコントラストのテスト基準も検討されています。現状のコントラスト比が必ずしも妥当な基準とは言い切れないことに留意すべきでしょう。

ちなみに、Chart UI accessibilityというissueでこの問題はすでに報告されていますから、今後改善されていくことかと思われます。

まとめ

データの性格上、どうしても「できていない」というところに目が行ってしまいますが、これまで取り上げた数値をまとめておきます。

• 19.5% のサイトはlang属性による適切な言語属性を設定できておらず、スクリーンリーダーの読み上げ自体を阻害する可能性がある。ただし、日本語サイトを対象とすればもう少し数値は改善されているかもしれない
• 49.0% のサイトはinput要素の入力欄について、適切なアクセシブルな名前を付けるのに失敗している。これは、スクリーンリーダーユーザーが何の入力欄なのか理解するのを難しくしている
• 19.0% のサイトはalt属性そのものが存在しない画像であり、スクリーンリーダーユーザーは画像の理解が著しく困難になっている
• 5% 見当のサイトはtabindex属性に正の数を与えており、ユーザーのキーボード操作を妨害している
• 90% 以上のサイトがブラウザーデフォルトのフォーカスインジケーターを消している（:focus疑似クラスを設定しているサイトのうち）。ただし、これがそのままキーボードユーザーの操作を困難にするわけではない。むしろ、ブラウザーの提供するフォームのデフォルトスタイルを取り巻く問題もあると考えられる
• 22% のサイトしかコントラスト比の自動テストをパスしていない。ただし、これはWCAG 2.1適合レベルAAの達成基準であり、適合レベルの観点からは、これよりも優先的に取り組むべき問題がある。また、新しいテスト基準が策定中であり、現行のテスト基準が最良というわけではない

なお、筆者が2020年末に日本企業500社を対象にLighthouseのアクセシビリティスコアを計測してみたでまとめたグラフからもわかるように、自動テストですべての項目をパスするほうが希有です（たかだか3%ほどに過ぎません）。

Webアクセシビリティに関してはさまざまな課題がありますが、WCAGの達成基準の観点からは、まずはWebサイトの自動テストを行ったうえで、持続的にWebアクセシビリティに取り組んでいくことが重要でしょう。