タグ: アクセシビリティ

ウェブサイトの使いやすさを測る物差しが、欧州で一段新しいものに切り替わろうとしている。情報通信技術のアクセシビリティ要件を定めた欧州規格EN 301 549の新しい版が2026年9月に公開され、参照する指針がWCAG 2.1からWCAG 2.2へと改められた。

規格の版が上がっただけと言えばそれまでだが、中身を見ていくと、派手な新機能の話ではなく、日々の制作でつい後回しにしがちな部分が並んでいる。法令の直接の対象になるかどうかとは別に、自分たちのサイトを点検する材料として読む価値がありそうだ。

欧州の参照先が入れ替わる準備が進んだ

新版のEN 301 549 V4.1.1は、ウェブコンテンツだけでなく、ソフトウェアや電子文書に対する要件もWCAG 2.2に合わせて更新されている。公開元の説明によると、欧州アクセシビリティ法を明確に意識して作られた最初の版でもあり、規格の要件と同法の要求事項を結びつける附属書が新しく加わったという。

ただし、公開されたからといってすぐに法的な基準が切り替わるわけではない。欧州委員会が官報で新版を正式に引用するまでは、2021年の版であるV3.2.1、つまりWCAG 2.1のレベルAAが参照される基準として残る。正式に引用された後は、新版に適合していれば欧州アクセシビリティ法とウェブアクセシビリティ指令の両方に適合しているとみなされる扱いになる。

言い換えると、いま慌てて何かを差し替える必要はない。その一方で、欧州が向かう先がWCAG 2.2だとはっきりしたので、準備を始めるなら目標は定まったことになる。

増えた達成基準はどれも地味で実務的

WCAG 2.1と比べると、ウェブコンテンツ向けにはレベルAとAAの達成基準が六つ増えている。キーボードのフォーカスが他の要素に覆い隠されないこと、ドラッグ操作に代わる手段を用意すること、クリックやタップの対象を一定の大きさに保つこと、ヘルプへの導線を各ページで同じように置くこと、同じ情報を何度も入力させないこと、そして認証で記憶や謎解きに頼らせないこと。並べてみると、どれも新しい技術の話ではなく、作り方の話だと分かる。

たとえばクリック対象の大きさは24×24ピクセルが目安になるが、周囲に他の対象が近接していない場合や、同じ機能を別の適合した方法でも実行できる場合、文章やリストの中のリンクである場合などは除外される。ドラッグについても、並べ替えのような操作をドラッグ以外の単一のポインタ操作でも達成できるようにすることが求められ、ドラッグそのものが本質的な機能である場合は対象外になる。

再入力に関する基準は、ひとつの手続きの途中で同じ情報を書かせる場面を想定している。前に入力した内容を自動で埋めるか、選べるようにするのが基本で、安全上の問題がある場合や、以前の情報がもう有効でない場合は例外として扱われる。

中小企業のサイトで先に引っかかりやすいところ

この六つを実際のサイトに当てはめると、引っかかりやすい場所はだいたい決まっている。画面上部に固定したヘッダーや同意を求めるバーは、キーボードで送っていったフォーカスを覆い隠しやすい。スマートフォン向けに詰めて配置した小さなアイコンは、対象の大きさの目安を下回りやすい。

問い合わせフォームも見どころが多い。確認画面から戻ったときに入力内容が消える作りは、再入力に関する基準から見ると改善の余地がある。パスワードの貼り付けを禁止する設定も、記憶に頼らせない方向とは逆を向いている。ヘルプや連絡先の置き場所がページによってばらばらというサイトも珍しくない。

どれも大規模な作り直しを必要とする話ではない。固定ヘッダーの高さの分だけスクロール位置をずらす、アイコンの間隔を少し空ける、入力値を保持する。こうした細かい修正の積み重ねで届く範囲がかなりある。

法令の対象でなくても点検の材料になる

欧州の規格なので、国内の中小企業サイトが直接その適用を受ける場面は限られる。ただ、欧州向けに商品やサービスを販売しているなら無関係とは言えないし、この動きは欧州だけにとどまらない。オーストラリアの規格も欧州規格を土台にしており、現時点ではWCAG 2.1を参照しているが、今後の改訂で新しい版を取り込む可能性が指摘されている。

公開元が当面の準備として挙げているのは、サイトと電子文書をWCAG 2.2の観点で見直すこと、検査の手順や点検表を更新すること、調達の条件や発注先への要求を見直すことなどだ。制作を請け負う側からすると、最後の項目が効いてくる。発注元の点検表が更新されれば、納品物に求められる水準もそこに合わせて動く。

期限が切られているわけではないので、次に作るサイトから少しずつ織り込んでいけば足りる。フォーカスが隠れていないか、指で押せる大きさか、同じことを二度書かせていないか。基準の番号を覚えるより先に、その三つを手元の画面で確かめてみるところからでいいと思う。

ウェブサイトで何かを開いたり閉じたりする操作は、どんなサイトにもあります。ハンバーガーメニューの開閉、問い合わせ前に表示するモーダル、よくある質問のアコーディオン、小さなツールチップ。こうした開閉パーツは長らくJavaScriptのライブラリで組むのが当たり前でした。ところが2026年に入り、ブラウザ標準の機能だけで同じことができる場面がぐっと増えています。

節目になったのが、2026年5月に公開されたSafari 26.5です。ここでopen擬似クラス(:open)が実装され、ChromeやFirefoxと足並みがそろいました。地味な追加に見えますが、標準機能だけで開閉UIを組む流れを後押しする一歩です。詳しくはWebKitの公式ブログでも解説されています。

open擬似クラスが開いた状態をまとめて扱う

:openは、要素が開いている状態にスタイルを当てるための擬似クラスです。対象はdetails要素やdialog要素、それにselect要素や、日付や色を選ぶinput要素のピッカーが開いたときまで含みます。開閉する部品を、種類を問わず同じ書き方で整えられるのが利点です。矢印の向きを変える、背景色を切り替えるといった見た目の調整を、状態ごとにCSSの中で完結させられます。

これまでは[open]属性セレクタで開閉状態を拾っていました。ただしこの書き方が効くのはdetails要素とdialog要素だけで、select要素やinput要素には使えませんでした。細かな差に見えますが、開閉するあらゆる要素を一貫した書き方で扱えるようになった意味は小さくありません。要素の種類ごとに別々のセレクタを覚える負担が減り、スタイルの見通しも良くなります。詳しい対応状況はMDNで確認できます。

標準タグだけで組める開閉パーツ

開閉UIの部品は、ここ数年でブラウザ側にそろってきました。モーダルはdialog要素のshowModalで開けます。背景を暗くする処理やフォーカスの閉じ込め、Escキーで閉じる動きまで、ブラウザがはじめから面倒をみてくれます。ちょっとしたメニューや吹き出しは、HTMLにpopover属性を足すだけで開閉できます。Popover APIは2025年4月に主要ブラウザで安定して使えるようになり、いまでは前提として組み込める土台になりました。popover属性を付けた要素は、外側をクリックしたりEscキーを押したりすると自動的に閉じます。いわゆるライトディスミスの挙動を、自分で書かなくてもブラウザが用意してくれます。

よくある質問のアコーディオンは、details要素とsummary要素だけで作れます。開いたときの見た目は:openで整えれば、開閉の状態管理をJavaScriptで書く必要はありません。ポップオーバーが表示中かどうかは:popover-openでも拾えます。Safari 26.5では、どの要素がポップオーバーを開いたかを知るための仕組みも加わり、複数の開閉部品が絡む画面でも扱いやすくなりました。ボタンを押すと候補が開くドロップダウンのような部品も、こうした標準機能の組み合わせで素直に表現できます。素朴なHTMLの積み重ねで、これまで外部ライブラリに任せていた動きの多くがまかなえます。

制作現場にとっての意味

標準機能に寄せる利点は、まずコードが軽くなることです。開閉のためだけに読み込んでいた外部ライブラリを減らせば、ページの表示は速くなり、保守の手間も下がります。加えて見落としがちなのがアクセシビリティです。dialog要素やpopover属性は、キーボード操作やスクリーンリーダーへの対応がはじめから組み込まれています。自前で作った開閉UIにありがちな、フォーカスが迷子になる、Escキーで閉じないといった不具合を避けやすくなります。ブラウザ標準の挙動に乗るぶん、環境による見え方や操作感のばらつきも抑えやすくなります。

中小企業のサイトでも、問い合わせ導線のモーダルやFAQのアコーディオンなど、使いどころは多いはずです。たとえば、以前はプラグイン頼みで組んでいたFAQの開閉を、details要素と:openだけに置き換えれば、依存が減って動作も安定します。ただし現状では、古いブラウザ向けのフォールバックや、凝ったアニメーションでのCSSとの併用など、細かい調整が要る場面は残ります。それでも、開閉UIの土台をブラウザ任せにできる範囲は着実に広がっています。新しく組むときは、まず標準機能だけで足りるかを出発点に考える価値が出てきました。手が込んだ実装に進むのは、それで届かないところを見極めてからでも遅くありません。