Firefox 146 が正式版になりましたね。アップデート内容をざっと眺めてみても、新しいAPIが増えたとか、見た目が大きく変わったといった大きな変化はありませんでした。そのせいか、「今回のアップデートは地味だなぁ」と感じた方もいらっしゃるかもしれません。
ただ、Web開発目線で見ると、派手ではないけど地味に効いてきそうな変更がいくつか入っている――そんな印象でした。
ARIA / アクセシビリティ関連の解釈修正が入ったそうな
地味に効いてきそうな変更、そのひとつが “ARIA やアクセシビリティ周りの解釈修正” です。
リリースノートを見ると、「HTML / CSS の解釈が、より仕様準拠に寄った」という記述があり、その中でも特にARIA やアクセシビリティ関連の挙動が調整された、と……。
UX が重視される昨今、こうした変更は一見地味でも、日々の実装やチェックにじわじわ効いてきます。
FirefoxのAccessibilityタブは、思ったより正直
ふだんの表示確認や軽いデバッグで、Accessibility タブを覗く機会も多いのではないでしょうか。
Firefoxの Accessibility タブでは、あまり意識していない情報が、かなりはっきり見えてきます。
たとえば……
- スクリーンリーダーからどう見えるか
- キーボードで操作できるか
- 要素にちゃんと「名前」が付いているか
といった点です。
見た目やデザインの話ではなく、実際に使えるかどうかを基準にしているので、人間の目で見ていると気づきにくい部分が浮き彫りになる感覚があります。
なぜ Firefox だと、こういう問題が見えてきやすいのか
ここまで読んで、
「でも、これって他のブラウザでも見られるんじゃないの？」と思った方もいらっしゃるかもしれません。
実際、Chrome や Edge でもアクセシビリティの確認はできます。
ただ、実務でチェックしていると Firefox のほうが「問題として見えやすい」ケースが多い、という印象があります。いくつかの理由を挙げてみます。
理由① アクセシビリティツリーを“そのまま”見せてくれる
まずひとつ目は、Firefox の Accessibility タブが、ブラウザ内部のアクセシビリティツリーをかなりストレートに見せてくれることです。
要素の Role や Name、フォーカス可能かどうかといった情報を、補正なしでそのまま表示してくれるんですよね。だから「今、支援技術からはこう見えている」という状態を、想像ではなく事実として確認できます。
逆に言うと、Firefox はあまり “親切にごまかしてくれない”。でも、それがチェック用途としては大きな強みだと感じています。
理由② Chrome は“とりあえず使える”方向に寄りやすい
一方で Chrome は、多少雑な実装でも「とりあえず使える」方向に寄せてくれることが多いです。
これは普段使いのブラウザとしてはとても親切なのですが、アクセシビリティの確認という観点では、「本当は問題があるのに、問題として表に出てこない」ということが起こりがちです。
理由③ Firefox は仕様準拠の影響が見えやすい
Firefox は、比較的早い段階で仕様に寄せた挙動を反映しやすいブラウザです。
今回の Firefox 146 でも、HTML や ARIA の解釈がより仕様準拠に寄ったことで、「今まで問題なく見えていたものが、少し違って見える」という変化が出てきました。
これは Firefox 独自のクセというより、”もともと実装に潜んでいた粗が見えるようになった” というケースがほとんどです。
つまり、Firefox で見えてくる問題は、「Firefox だから起きている問題」ではなく「どの環境でも起こり得る問題」だと考えたほうが近いということです。
実際に見えてくる粗 ――見た目は問題なさそう。でも使うとつまずく
ぱっと見はちゃんと表示されていて、今まで特に問題なく動いているように見える要素でも、Accessibility タブを通して見ると「あれ？」となるケースがあります。
いくつかのケースを見てみましょう。
ボタンっぽいけど、ボタンじゃなかった
<div role="button">送信</div>
見た目は完全にボタンですし、Nu Html Checkerでも特に指摘はされません。ただ、Firefoxで確認してみると実は次のような状態になっています。
- キーボードフォーカスが当たらない
- Enterキーを押しても反応しない
マウスが使える人には問題なくても、キーボード操作や支援技術を使う人にとっては、操作できないUIです。
“role” はあくまで「役割を示す」ものなので、実際に操作できるようにするところまでは面倒を見てくれません。
labelはあるのに、入力欄の「名前」がない
<label>メールアドレス</label>
<input type="email" id="email">
画面を見る限り問題なさそうですが、Accessibility タブを見ると入力欄の Name が空になっています。
スクリーンリーダー的には 「この欄には何を入力すればいいんだ？」 といった状態です。
labelは、ただ置けばいいものではありません。
フォーム要素と結びついて初めて意味を持つということが、ここではっきり分かります。
ARIAは便利だけど、油断すると一気に危ない
ARIA は、アクセシビリティ対応を助けてくれる便利な仕組みです。ただし、使い方を間違えると、影響がかなり大きく出ることもあります。
例えばこんな感じで……
<nav aria-hidden="true">
<a href="/about">About</a>
</nav>
画面上では普通に見えていて、リンクもクリックできます。ところが Firefox の Accessibility タブでは、この中身が丸ごと存在しない扱いになります。
なぜかって、 aria-hidden で存在ごと消してしまっている状態だからです。
「読み上げを少し抑えたかっただけ」のつもりが、完全にアクセスできない状態を作ってしまっている、というケースですね。
ARIA は強力だからこそ、「本当に隠していいのか？」を一度立ち止まって考える必要があります。
見出し構造、意外とちゃんと見られている
<h1>タイトル</h1>
<h3>サブタイトル</h3>
見た目やデザイン的には、特に問題なさそうに見えるかもしれません。
でも、Firefox で見出し一覧を確認すると、h2 がなく、いきなり h3 が出てきます。
スクリーンリーダーでは「次の見出しへ」と移動していくので、見出しレベルが飛んでいると文書構造がつかみにくくなります。
見出しは、文書の構造を伝える役割を持っている、という点を意識したいところです。
「見えない」と「読まれない」は、同じじゃない
Firefox で確認していると「見えないものは読まれない」と、つい思い込んでいたことにも気づくかもしれません。
display: none や visibility: hidden は、アクセシビリティツリーから完全に除外されます。
一方で、opacity: 0 や画面外に配置した要素は、見えないだけで普通に残ります。
つまり「画面には見えないけど、スクリーンリーダーでは読まれる」という状態が起こり得ます。
意図せず情報を読み上げてしまうケースもあるので、「隠し方」には注意が必要です。
確認は、思ったより難しくない
こまで読むと、「確認するの大変そう……」と感じるかもしれません。
でも、やることはとてもシンプルです。
- Firefox 146 でページを開く
- 開発者ツールから Accessibility を開く
- 気になる要素をクリックする
見るポイントは次のような点だけ。
- Role
- Name
- キーボード操作できるか
たったこれだけでも、「あ、これはちょっと雑だったな」と気づける箇所が、意外と見つかります。
NuでOKでも、Firefox で一度見ておく
Nu Html Checkerは、HTML の文法チェックとしてとても便利です。ただ、それは「書き方として正しいか」を見ているツールです。
Firefox の Accessibility タブは、「実際に使えるかどうか」を見せてくれます。
Firefox 146 は派手なアップデートではありませんが、Web 開発目線で見ると、地味に効く改善がちゃんと積み重なっています。
「アクセシビリティ対応、できているはず」と思ったときほど、一度 Firefox で覗いてみる。
それだけで、あとから気まずくなる確率は、かなり下げられるはずです。
