タグ: HTML

Chromeの安定版151が7月28日に公開された。大型の目玉機能というより細かい追加が並ぶ回だったが、そのなかにaria-actionsという属性が入っていて、これは現場の作り方に素直に馴染みそうだと感じた。ある要素に付き添っている別の操作ボタンの存在を、スクリーンリーダーなどの支援技術に伝えるための指定である。Chromeのリリースノートによると、W3CのARIA仕様に沿った形で実装されたとされている。

想定されている典型例は、タブの見出しに小さく付いている閉じるボタンだ。マウスで操作していれば見えているので迷わないが、キーボードと読み上げでたどっている人には、そのタブに閉じる手段が添えられていること自体が伝わりにくい。メールの一覧行に並ぶアーカイブや削除のボタン、カード型のリストに乗った編集ボタンなども同じ構図になる。主となる要素と、その脇に置かれた操作との関係を機械が読み取る手がかりがなく、支援技術の側から見つけづらいことは、以前から課題として挙げられていた部分だ。近くにボタンが置いてあることは、画面上の距離では明らかでも、読み上げの順番のなかでは伝わらない。結果として、タブ移動を重ねて偶然行き当たるまで存在に気づけない、という状態が起きていた。

既存のマークアップを壊さずに足せる

使い方は他のARIA属性と似ていて、主となる要素から、関連するボタンのidを指すだけでよい。属性を足しても見た目やクリックの挙動は変わらず、対応していないブラウザは単に無視する。既存のコンポーネントに後から付け足す形で試せるので、導入の判断はしやすい。開発者ツール側でも、他のid参照型のARIA属性と同じように、参照先がどの要素を指しているかを確認できるようになっている。W3C側の仕様もほぼ固まっており、Firefoxはすでに対応済み、WebKitは試作の段階と伝えられている。ChromeはまずWindows、Mac、Linuxのデスクトップで有効になり、モバイル向けは後続になるとのことだ。

もっとも、属性を書けばすぐ読み上げが変わるという話ではない。支援技術の側がこの関係をどう利用者に案内するかは、各社の実装がこれから揃っていく段階にある。ただMicrosoftのUI部品群を手がけるチームが早い時期の取り込みに前向きだと伝えられており、部品ライブラリ経由で静かに広まっていく類の機能ではありそうだ。自前でタブやリストのUIを組んでいるなら、仕様の様子を眺めておく価値はある。

中小企業のサイトでも、同じ形はあちこちにある。予約フォームの入力欄に添えたクリアボタン、実績一覧のカードに置いた詳細ボタン、通知バーの右端にある閉じる印。どれも見えている人には自明で、見えていない人には気づきにくい。ARIAは足しすぎるとかえって読み上げを濁らせるので万能ではないが、これまで説明のしようがなかった関係を素直に書ける手段が増えたのは、地味ながらありがたい変化だと思う。

ウェブサイトでカメラやマイクを使う場面は、ここ数年で少しずつ増えてきました。オンライン相談の入口、動画で送るお問い合わせ、現場のスタッフが撮影してそのまま投稿する仕組みなど、業種を問わず出てきます。その手前に必ず挟まるのが、ブラウザが表示する「カメラの使用を許可しますか」という確認です。

Chrome 151が2026年7月28日に公開され、この確認の出し方そのものを見直す新しいHTML要素、usermedia要素が使えるようになりました。JavaScriptから許可を求めるのではなく、ブラウザが仲立ちする部品を押してもらう形に変わります。

スクリプトから許可を求める方式のつまずき

これまでカメラやマイクを使うには、JavaScriptでgetUserMediaという命令を呼び、その瞬間にブラウザが許可の確認を出す形が標準でした。書き方としては素直ですが、実際の現場では困りごとがついて回ります。

ひとつは、確認が出るタイミングを利用者が予想しにくいことです。ページを開いた直後に何の脈絡もなく確認が出れば、多くの人はとりあえず拒否します。もうひとつは、拒否したあとの復帰が難しいことです。いったん拒否すると次からは確認すら出ず、ブラウザの設定画面を自力で開いて権限を戻す必要があります。制作側からは、その設定画面への案内文を書き添えるくらいしか打つ手がありませんでした。

迷惑な確認を減らすため、ブラウザ側が自動的に確認を抑え込む挙動も広がっています。まっとうに作ったページが、その網に引っかかって何も起きないという事故も起こり得ます。

ボタンを包むだけの書き方

usermedia要素は、押してもらうボタンをこの要素で包むだけで使えます。中に置いたボタンの見た目はこれまでどおり自由に整えられ、押されたあとの段取りをブラウザが引き受けます。

結果の受け取りは、要素が発火する3種類の出来事を見張る形です。許可されたときのstream、失敗したときのerror、利用者が確認を閉じたときのcancelの3つで、映像や音声の本体はstreamから受け取ります。解像度やエコー除去といった希望は、押される前にsetConstraintsで指定しておきます。従来の書き方で必要だった成功と失敗の分岐や状態管理のコードは、かなり減らせます。

目に見えて変わるのは、確認が出る条件です。従来はスクリプトの都合で確認を出せましたが、この要素ではブラウザが用意した部品が実際に押されるまで確認は出ません。裏を返せば、勝手なタイミングで確認を出す作りが成立しなくなるということでもあり、利用者側から見た予測しやすさは上がります。

拒否されたあとに戻ってこられるかどうか

この要素の効き目がはっきり出ているのが、一度拒否されたあとの復帰です。Chromeの開発者向け情報によると、試験導入に参加したCiscoの計測では、従来の方式で復帰できた人がおよそ1割だったのに対し、新しい要素では6割を超えたとされています。Zoomでは撮影や録音の失敗が約47パーセント減り、Google Meetでは「マイクが動かない」という申告が約17パーセント減ったという数字も挙がっています。

理由は単純で、利用者が自分でボタンを押したという事実をブラウザが確実に把握できるからです。押した本人の意思がはっきりしているぶん、ブラウザは自動的な抑制を回さずに済み、拒否済みの状態からその場で復帰させる専用の流れを出せます。設定画面まで手順を案内しなくてよくなるのは、問い合わせ対応の手間という面でも小さくありません。

今すぐ全面的に置き換えるものではない

現時点で動くのはChrome 151以降で、他のブラウザはこれからです。仕様はW3Cのメディアキャプチャ拡張仕様に載っており、将来はカメラ用、マイク用といった用途別の要素も検討されています。

対応しているかどうかは、HTMLUserMediaElementという名前がブラウザ側に存在するかで判定できます。対応していないブラウザでは要素の中に書いた内容がそのまま表示されるので、中に従来のgetUserMediaを呼ぶボタンを置いておけば、ひとつの記述で両方の環境をまかなえます。新規に組むならこの入れ子の形から始めておくと、対応ブラウザが増えたときに書き直さずに済みます。

カメラやマイクを扱うページは、動くかどうかが問い合わせ件数に直結します。実装の難しさよりも、拒否したまま戻れなくなった利用者をどう救うかが実際の課題だった現場は多いはずで、そこにブラウザ側から手が入ったという意味で、頭の片隅に置いておく価値のある変化です。

画像の遅延読み込みでおなじみの loading=”lazy” が、video要素と audio要素でも使えるようになった。要素にこの属性を書き足すだけで、ページを開いた瞬間ではなく、その要素が画面に近づいたタイミングまで読み込みを後回しにできる。Chrome 148 で標準の挙動として全プラットフォームに行き渡り、特別な準備なしにそのまま動くようになっている。

面白いのは、後回しになる対象が動画本体のデータだけではない点だ。ポスター画像やメタデータの取得、それに autoplay の再生開始まで、要素が表示領域に入る手前まで待つ。これまでも preload=”none” やメタデータのみの指定で動画データの通信量はある程度抑えられたが、ポスター画像の取得まで含めて遅らせられるのは新しい。書き方は img要素や iframe要素の loading=”lazy” とまったく同じで、WHATWG の仕様に沿った標準の動きとして扱われる。特別なライブラリを読み込む必要はなく、既存のマークアップに一語足すだけで完結する手軽さがある。

実務でうれしいのは、専用の JavaScript を用意しなくてよくなることだ。従来はページ下部に並ぶ動画を遅らせるために、IntersectionObserver で表示位置を監視する自前のコードを書くのが定番だった。その方法だと、スクリプトが動くタイミングとブラウザ内部の読み込みスケジュールが微妙にずれて、境目でのちらつきや二重の読み込みに気を配る必要がある。属性ひとつに任せれば、こうした細かな調整から解放される。preload 属性の指定自体はこれまでどおり効くが、その判断が要素の表示まで遅れる、と理解しておけばよい。

ひとつ気を配りたいのは、レイアウトのずれだ。メタデータの取得が後回しになると、動画の縦横比が分かるのも遅れるため、読み込みの瞬間に高さが変わって周囲がガタつくことがある。video要素に width と height を指定しておくか、CSS の aspect-ratio で先に場所を確保しておけば、この飛び跳ねは避けられる。遅延読み込みと表示の安定は、セットで考えると気持ちよく収まる。

使いどころも選びたい。ページを開いてすぐ目に入る主役の動画に付けると、かえって表示が一拍遅れて見えることがある。向いているのは、スクロールした先に置いた紹介動画や、複数の音声サンプルを並べたページなど、最初の画面には映らない要素だ。折り返しより下にあるものを選んで付ける、という素直な使い分けでよい。

対応はまず Chrome 系が先行し、ほかのブラウザは順次追随していく段階にある。とはいえ非対応のブラウザでは属性が無視されて従来どおり読み込まれるだけなので、progressive enhancement として今から書き足しておいて困ることはない。動画を多く載せる商品紹介ページやサービスサイトで、最初の表示を軽くするための一行として頭の隅に置いておきたい。細かな挙動はweb.devの解説にまとまっている。