私がかつて『マルチデバイス対応における「三本の矢」』というコラムを書いたのは、2014年3月のこと。その中で、Webサイトがマルチデバイスに対応するための3要件を、戦国武将・毛利元就にまつわる「三矢の教え」になぞらえて紹介しました。具体的には

• アクセシビリティ
• マルチスクリーン・デザイン
• 高速な表示パフォーマンス

の3つがそれで、最初のアクセシビリティについてはこのシリーズ記事の（その3）アクセシビリティ標準対応と（その4）標準対応の進化とアクセシビリティに関する多様な取り組みで、またマルチスクリーン・デザインについては（その5）レスポンシブWebデザインと（その6）レスポンシブWebデザインの検品で触れてきました。

最後に残された、つまり社内において最も後発となったのが、表示パフォーマンスという品質への取り組み。決してそれを軽視してきたつもりはないのですが、結果として後回しにせざるを得なかったのは、単にアクセシビリティとマルチスクリーン・デザインの優先度が高かっただけではなく、他にも理由があります。

第一に、表示パフォーマンスにはさまざまな要素が影響します。フロントエンドはもちろんのこと、バックエンドやネットワークも、表示パフォーマンスを大きく左右し得るのです。従い、未公開のコンテンツをお客様の環境で実際に公開するより前に社内で検品する必要上、どこまでどう割り切って評価すべきかは難しい問題でした。

第二に、表示パフォーマンスと一言で言っても、それを測るための指標は数多く存在します。どのタイミングで、何を、どのように測るか......またその計測結果につき、どの程度の数値なら検品に合格＝必要十分な表示パフォーマンスを備えており、ゆえにお客様への納品が可能と認めるかは、非常に悩ましい問題です。

第三に、表示パフォーマンス指標の中には、計測を実行する環境のCPU性能やインターネットへの接続速度などが、計測結果に大きく影響するものがあります。従い、制作者が検品を依頼する前にセルフチェック（社内では「自己検品」と呼びます）を行った結果と、検品する側が計測した結果とが著しく乖離することのないよう、指標や測り方を選ばなくてはなりません。

もろもろ検討した結果、Google Chromeに付属するLighthouseの表示パフォーマンススコアを指標とし、またその計測については制作者や検品担当者のPCを使わず専用のシステムを構築、その上で実行することとしました。そして気がつけば、『Webコンテンツの「当たり前品質」に表示パフォーマンスを追加』を書くまで、記事冒頭に紹介したコラムからは5年以上の月日が経過していました。

おそらく最終回となる次回、品質の追求（その8）では、専用のシステムを使った表示パフォーマンス品質のチェックについて、もう少し詳しく紹介する予定です。

デスクトップ版Firefoxのバージョン102.0がリリースされました（リリースノート：Firefox 102.0, See All New Features, Updates and Fixes）。

今回のアップデートで個人的に気になったのが、updateというメディア特性への対応。これは、コンテンツを出力する対象が、どれぐらいの頻度で表示を更新できるかに応じて、スタイルを変更できるようにするものです。

値にはnone / slow / fastの3種類が用意されています。対象が一般的なPCやスマートフォンであれば表示上の更新頻度に制約なくCSSアニメーションを利用できるためfast、紙面であれば逆に更新は一切できないのでnone、一部の電子ブックリーダーのように頻繁な更新が行えず滑らかなアニメーション表示できないデバイスであればslowを選択することになります。当初、具体的なユースケースをイメージできなかったのですが、該当のBugzillaを見ますと

Authors can use that to style things differently on print vs ebook readers, even though both media are paginated. This kind of nuance was not possible to express just with @media print {...}

というくだりがあり、なるほど従来のメディア種別（print）だけでは難しかった区別が可能になるのですね。電子書籍やそれに類するコンテンツでの利用が強く意図されているように感じましたが、ハードウェアの進化は著しいので、slowの指定に現状どれだけニーズがあるのか興味が湧きました。

本バージョンには、ほかにも複数の機能追加、バグ修正、セキュリティ修正（全19件、うち重要度高：4件）が含まれています。開発者向けには、Firefox 102 for developers - Mozilla | MDNが参考になるでしょう。

次のメジャーバージョンアップ、Firefox 103のリリースは、Firefox Release Calendar - MozillaWikiによると2022年7月26日の予定のようです。

検品に用いている主要ブラウザのアップデートについてお知らせします。

Google Chrome 103が安定版になり、デスクトップ版Chromeでバージョン103.0.5060.53がリリースされました（Chrome Releases: Stable Channel Update for Desktop）。

このアップデートでは、表示パフォーマンスに関する機能の追加が目を引きました。新たにサポートされたHTTPステータスコード、103 Early Hintsは主にWebブラウザがサブリソースを先読みしやすくするためのものですし、DevToolsにおいてRecorderパネルやPerformance insightsパネルがそれぞれ進化したのも、ユーザーがWebページを操作する際の表示パフォーマンスをより多角的に把握・評価するためのものと認識しています。

DevToolsについては、Lighthouseを使った監査においてナビゲーション、測定期間、スナップショットの3つのモードが用意されました。従来の監査に近しいのはナビゲーションであり、ページ読み込み時にフォーカスしたモードで、デフォルトではこれが選択されます。測定期間は何らかのユーザーによる操作を含む一定期間を対象に監査するモード、スナップショットはユーザーがページ操作をした後などの特定の状態を監査対象とするためのモードです。

これら3つのモードを組み合わせることにより、たとえばSPAとして構成されたWebアプリケーションを、より実際のユーザー体験に則したかたちで監査できるようです。詳細はUser Flows in Lighthouseを確認していただければと思います。

このアップデートにはほかにも数多くの修正（セキュリティに関する修正については14件）と改良が含まれています。開発者向けにはNew in Chrome 103 - Chrome Developersがわかりやすいでしょう。また、新たに追加されたDevToolsの機能については、What's New In DevTools (Chrome 103) - Chrome Developersにまとめられています。

次のメジャーバージョン、Chrome 104のリリースは、Chromium Dashによると2022年8月2日の予定のようです。

アクセシビリティに関する検品について、今回はWCAG 2.1の2.4.4「リンクの目的 (コンテキスト内)」という項目を取り上げたいと思います。

該当の達成基準2.4.4項目についてはWeb Content Accessibility Guidelines (WCAG) 2.1（ウェブアクセシビリティ基盤委員会による日本語訳）のページで確認できます。

達成基準の日本語訳は「それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。」となっており、解説書の表現を借りると「利用者がリンクを辿りたいかどうか決めることができるように」リンクテキストを記載するか、前後の文脈でリンク先が判断できることを求めています。

なお、前後の文脈によるリンク先の判断をNGとする、達成基準2.4.9「リンクの目的 (リンクのみ)」という項目が存在します。こちらは難易度が高いレベルAAAに位置づけされており、当社の標準対応（レベルA相当）では対象外となっています。

検品の方法

リンクテキストの妥当性を検品するにあたっては、コンテンツの意味や文脈を追っていく必要があるため機械的なチェックが難しいケースが多く、品質管理部門のスタッフによる目視チェックが中心となります。

当社内での検品時には前工程から原稿がインプットされますので、原稿と一致したリンクテキストであるか比較するチェックを行っています。リンクテキストとリンクパスが一覧化されているという点でファイルリストを参照するケースもあります。どのドキュメントを正とするかは前工程からのインプット次第で変わります。

原稿にあたるドキュメントが指示されず、検品対象ページのリンクテキストを正とする場合もあります。その場合は、テストサイト上で実際にページ遷移し、遷移先のページタイトルと文字列ないし意味が一致しているかを確認します。遷移先ページの検品がすでに終了している場合はこの方法が妥当となります。

なお、解説書では「リンクとタイトルが一致する又は極めて似ていることは、グッドプラクティス」であると記されています。リンクテキストと遷移先ページのタイトルが完全一致することが前提になる場合に限っては、機械的なチェックも可能になる認識です。

様々な実装状況への対応

リンクテキストの表現について、検品方法と合わせて2件ほど例示してみます。

「詳しくはこちら」といったテキストの「こちら」をリンク化して詳細ページへ誘導する実装はよく見られるパターンだと思います。この場合、「こちら」のリンクで遷移するページ内容について、「こちら」の前後の文脈で読み取ることができるかどうかがポイントになります。例えば「本サービスの導入事例についてはこちら」というテキストであれば、ユーザーには「こちら」の指し示す意味が伝わる文脈といえるでしょう。検品時には、前後の文脈から遷移先の判断が可能かを確認しています。

なお、上記例に関する達成方法集ではリンクの後にそのリンクを理解するために必要な情報を置いてしまうと、音声読み上げ環境を使用しているユーザーには分かりにくくなってしまうと指摘されています。達成基準は満たしていますが配慮したい内容という位置づけです。

また、img 要素をリンクに含んでいる場合、代替テキストがリンクテキストの役割を果たします。画像の意味と同等のテキストを記載することで、必要十分な内容になると思います。検品では適切に代替テキストが記載されているか、意味内容を含めて確認します。

上記を含んだ実装例については、達成方法集に一覧化されていますのでご参考にしてください。

検品に用いている主要ブラウザのアップデートについてお知らせします。

デスクトップ版Firefoxのバージョン101.0.1がリリースされました（リリースノート：Firefox 101.0.1, See All New Features, Updates and Fixes）。

このアップデートでは、macOSにおいてFirefox終了時にクリップボードの内容を空にしてしまう問題や、安定性に関する問題など、複数のバグが修正されています。

セキュリティに関する修正は、含まれていません。

検品に用いている主要ブラウザのアップデートについてお知らせします。

デスクトップ版Chromeのバージョン102.0.5005.115がリリースされました（リリースノート：Chrome Releases: Stable Channel Update for Desktop）。

このアップデートには7件のセキュリティの修正（うち4件は重要度「高」）が含まれています。

デスクトップ版Firefoxのバージョン101.0がリリースされました（リリースノート：Firefox 101.0, See All New Features, Updates and Fixes）。

本バージョンで特に気になったのは、prefers-contrastメディアクエリに対応した点です。このメディアクエリは、ユーザーがデフォルトより高い（もしくは低い）コントラストでの表示を求めているかを検知するものです。古い記事ですが、アクセシビリティBlogのハイコントラスト表示とメディアクエリーで初めて紹介をしました。また、ミツエーテックラジオの下記の2回でも言及していますので、是非チェックしてみてください。

• #17「新技術から見る次世代のレスポンシブWebデザイン」
• #26「2021年のミツエーテックラジオを振り返る」

本バージョンには、ほかにも複数の機能追加、バグ修正、セキュリティ修正（全13件、うち重要度高：8件）が含まれています。開発者向けには、Firefox 101 for developers - Mozilla | MDNが参考になるでしょう。

次のメジャーバージョンアップ、Firefox 102のリリースは、Firefox Release Calendar - MozillaWikiによると2022年6月28日の予定のようです。