タグ: アクセシビリティ

日本語のページを組んでいると、ふりがな、つまりルビの扱いで地味に手を取られることがある。難読の地名や人名に読みを添えたい、子ども向けや自治体のページで漢字に読みを振りたい、といった要望は今も普通に出てくる。HTMLにはもともと ruby 要素があり、<ruby>石動<rt>いするぎ</rt></ruby> のように書けば親字の上に読みが乗る。ところが実際に組んでみると、読みのほうが親字より長いときの見え方がブラウザまかせになりがちで、そこを細かく指定する手段が長らく足りていなかった。Chromeのベータ版に入った新しいCSSプロパティは、その足りなかった部分をひとつ埋めるものになっている。

ルビは日本語サイトの地味な難所

ルビの厄介さは、親字と読みの長さが一致しないところにある。二文字の漢字に四文字の読みを振れば、読みの側が横にあふれる。ブラウザはこのあふれた分を隣の文字の上に少しはみ出させて表示することが多い。行がむやみに間延びしないので、組版としてはむしろ自然な処理だ。

問題は、そのはみ出しが常に望ましいとは限らないことだった。隣にリンクや強調が続いていると読みが重なって見えづらくなる。狭いカラムや表のセルの中では、はみ出しのせいで折り返し位置が予想と変わる。逆にはみ出しを一切許さないと、親字と読みの幅を揃えるために文字間が広がり、本文の中でその部分だけ間延びして見える。どちらを選ぶかは文脈次第で、これまではCSSからその判断を伝える標準的な手段がなかった。制作側は文字サイズを下げる、ルビを画像にする、そもそもルビをあきらめるといった回り道をしてきた。

はみ出しの許し方を選べるruby-overhang

Chrome 151のベータで加わったのが ruby-overhang というプロパティで、ルビが隣にはみ出すことを許すかどうかを書き手が指定できる。初期値は auto で、これは従来どおりブラウザの判断ではみ出しを許す振る舞いにあたる。隣にも別のルビが並んでいる場合など、重なると読めなくなる状況では自動的にはみ出さない、といった配慮も仕様に含まれている。

もうひとつの値が spaces で、はみ出してよい相手を空白と約物、つまり句読点やかっこの類に限る。隣が普通の文字なら、はみ出さずにその手前で止まる。Chromeの説明によれば none は spaces の別名として扱われ、はみ出しを完全に禁じた結果として不自然な隙間ができるのを避ける形になっている。この none の解釈は資料によって記述が揃っていない段階なので、実際の見え方は手元で確かめておきたいところだ。

書き方そのものは短い。読みが隣の文字に重なると困る箇所に ruby-overhang: spaces; を当てるだけで、あとはブラウザが処理してくれる。JavaScriptで文字幅を測って調整する、といった作業はいらない。

位置や揃え方を決める指定との組み合わせ

ルビまわりのCSSは、これが最初というわけではない。読みを親字の上に置くか下に置くかを決める ruby-position、親字に対して読みをどう割り付けるかを決める ruby-align は以前から使える。縦書きで読みを右側に出したい、読みを親字の幅いっぱいに散らしたい、といった調整はこれらが受け持つ。

今回の指定は、そこに「隣との境界をどう扱うか」という軸を足すものだと考えるとわかりやすい。位置と揃え方を決めたうえで、あふれた分を外に出してよいかどうかを別に決められる。組み合わせると、たとえば見出しの中のルビははみ出しを許して行の高さを保ち、本文の狭い箇所でははみ出しを止める、といった使い分けができる。

現時点で試すときの構え

ruby-overhang は主要ブラウザすべてに揃った状態ではなく、Baselineの対象にもなっていない。Chromeでもまだ安定版ではなくベータの段階にある。今すぐ本番の見た目を左右する前提で組むものではない、というのが正直なところだ。

とはいえ、対応していないブラウザではこの指定が無視されるだけで、ルビ自体は従来どおり表示される。壊れるのではなく、これまでの見え方に戻るだけなので、段階的に足していける類の機能になる。ルビを多用しているページがあるなら、対応済みのブラウザで spaces を当てたときにどう変わるかを一度見ておくと、将来の判断が早くなる。

中小企業のサイトでルビが主役になる場面は多くないが、社名や商品名の読み、地域名、業界特有の用語など、読みを添えたい単語は意外とある。読みを振ると崩れるから避ける、という選択をしてきた現場ほど、こうした指定が揃ってきたことの意味は大きい。日本語の組版に関わる指定がウェブ標準の側で少しずつ整っていくのは、地味だが歓迎したい流れだ。

ボタンや見出しの背景色を決めたあと、その上に載せる文字を黒にするか白にするかで迷った経験は、制作に関わる人なら一度はあるはずです。背景が濃ければ白、淡ければ黒と感覚で選んでいくものの、配色のパターンが増えるほど組み合わせの管理は地味に重くなります。この「背景に対して読みやすい文字色を選ぶ」という判断を、CSSだけで自動化するcontrast-color()という関数が、主要ブラウザにようやく出そろいました。

背景色から文字色を自動で決める関数

contrast-color()は、引数に渡した色に対して黒と白のどちらがより高いコントラストになるかを判定し、読みやすいほうを返す関数です。色を指定できる場所であればどこでも使えるので、文字色の指定に組み込めば背景色に応じて自動的に切り替わります。

書き方はとてもシンプルで、背景にブランド色を変数で渡しているなら、文字色は次のように一行で済みます。

background-color: var(–brand); color: contrast-color(var(–brand));

判定にはWCAGのコントラスト比の考え方が使われており、読みやすさの最低限を機械的に満たしやすくなります。Chrome 147、Firefox 146、Safari 26と三つのブラウザエンジンが2026年に対応し、安全に使える機能をまとめたBaselineでも新たに利用可能の段階に入りました。ブラウザ間の挙動をそろえるInterop 2026の対象にも含まれており、どの環境でも同じ結果になることが期待できます。

これまでの配色対応との違い

ブラウザが標準で対応する前から、読みやすい文字色を得る方法はいくつかありました。JavaScriptのライブラリで表示時にコントラスト比を計算して色を当てる、Sassの関数であらかじめ対になる色を生成しておく、あるいは単純に人の目で一つずつ黒と白を決めておく、といった具合です。

どれも動きはしますが、手間と保守の負担は残ります。表示時に計算する方法は画面が出るまでにわずかな処理を挟みますし、ビルド時に色を固定する方法は背景色を変えるたびに対の色も作り直すことになります。手作業の指定は、ライトモードとダークモードで色の組を二重に持つことになりがちです。contrast-color()はこの判断をブラウザ側に任せるため、背景色を一か所変えれば文字色もそのまま追従します。

制作現場で効く場面

恩恵が分かりやすいのは、背景色が一定しない場面です。ブランド色をボタンに使うコンポーネントなら、色だけ差し替えれば文字の見やすさは自動で保たれます。ホバーで背景を明るくする演出を入れた場合も、必要に応じて文字色が白から黒へ切り替わります。

ライトとダークの切り替えとも相性がよく、prefers-color-schemeで背景の変数だけを入れ替えれば、文字色の組を別々に書く必要がなくなります。color-mix()などで動的に作り出した色にも追従するため、配色をプログラム的に生成する設計とも噛み合います。デザインシステムのように色をトークンとして一元管理する作り方とも相性がよく、土台の色を一つ変えるだけで関連する文字色がまとめて整うため、配色の調整にかかる手数を減らせます。

地方の中小企業サイトやCMSでは、色の設定を制作者以外が触る場面も少なくありません。管理画面でテーマ色を選ぶと文字色まで適切に決まる、という作りにしておけば、運用する人がコントラスト比を意識しなくても読みにくい配色になりにくくなります。納品後の更新で配色が崩れるリスクを下げられる点は、長く運用するサイトほど効いてきます。

使う前に知っておきたい制約

便利な一方で、現時点の仕様には割り切りもあります。返すのは黒か白のどちらかだけで、中間調の背景に対しては必ずしも最適な結果にならないことがあります。判定の方式を選べる拡張的な書き方も一部ブラウザで試験的に使えるものの、Baselineの範囲ではまだ標準化されていません。

そのため、重要なボタンや本文など可読性が要になる箇所は、自動任せにせず実際の表示で確かめる姿勢は残しておきたいところです。とはいえ、配色の土台を機械的に整える層として置いておく価値は十分にあります。これまで手で管理してきたコントラストの一部を、ようやくCSSそのものに預けられるようになったという意味で、地味ながら実務に効く一歩だと言えます。