インクルーシブHTML+CSS & JavaScript 本を読んだ

投稿

紙媒体としては昨年11月に発売された本ですが、電子版の発売を待ってようやく読むことができました。

Amazon で買う

本の概要や制作秘話などは翻訳者を含む他の方のブログや Amazon レビュー等で多く語られているので、ここでは自分が読んで共感した部分、異論のある部分、誤りの指摘などをいくつか。

第6章 ナビゲーション領域

§

ロゴ画像リンクの代替テキスト

§

多くのサイトでページヘッダーの左上にサイトロゴを置き、トップページへのリンクを設定することが行われていますが、その際のロゴ画像の代替テキストについてこんな記述が。

画像をリンクにする場合は、代替テキスト（altの値）には画像の説明ではなくリンク先を書くべきです。つまり、「プロジェクトのロゴ」では不十分です。「プロジェクトのホーム」か、単に「ホーム」とするのが適切です。

Kindle の位置No.2797-2799

で、提示されたコード例はこのようになっています。

<a href="/home"><img src="images/logo.svg" alt="ホーム"></a>

確かに、原則論としては画像リンクの代替テキストはリンク先の意味を記す(WHATWG)のが適切でしょう。

しかし、代替テキストの役割は画像にアクセスできない環境において同等の情報を提供するものです。HTMLの仕様書にももっとも一般的な規則としてこのようなガイドラインが示されています。

The most general rule to consider when writing alternative text is the following: the intent is that replacing every image with the text of its alt attribute not change the meaning of the page.

4.8.4.4.1 General guidelines(WHATWG)

ロゴ画像に話を戻して、画像が表示される環境下では単にサイトロゴが表示されているだけであり、強いて言えばマウスカーソルを乗せるとポインター形状が変わるので何かしらのリンクであるということしか分かりません。「リンク先がトップページである」という情報は提示されていませんし、タッチデバイスではリンクになっているかどうかすら不明です。しかし多くの人は「ページの左上にロゴがある」という画像の掲載位置でもって、それがトップページへのリンクであると推定できると思います。そう考えると、ここに alt="ホーム" を設定することは、画像が見られない人に対してより多くの情報を提供することになり、不適切と言えます。

視覚障害でスクリーンリーダーを使っているユーザーも、あるいは回線の都合等で画像がロードできないケースも、本質的には画像が見られるときと同じで「ページの先頭にあるサイト名が書かれたリンクはトップページへ遷移する」ことは慣例的に周知の事実ですから、多くのサイトがそう設定しているように、ここの代替テキストはサイト名で良いのではないでしょうか。

第7章 メニューボタン

§

SVGスプライト

§

SVGスプライトをクロスブラウザブラウザ対応させる場合は、ページ内に直接埋め込むのがベストです。

Kindle の位置No.3254-3255

「クロスブラウザブラウザ」は誤記と思われます。

第9章 商品リスト

§

ビジネスにおいては、反応の良さそうなユーザーをターゲットにしてコミュニケーションをしようとする傾向があります。

(中略)

また、自分たちの商品を使いたがるのは誰なのか当てるゲームも必要ですが、その際、人々がどのように使うかを決めてかかると、潜在的なファンや顧客を疎外してしまうだけの結果になります。

いわゆる平均的ユーザーをターゲットにすることは、悲劇を招くインターフェイスデザイン戦略です。

(中略)

家庭用品などで有名なOXO社はこれをよく理解しており、まず極端な状況や身体的な障害を持つ人々のニーズを満たすことで、人間工学的に優れた、一般消費者を引きつける製品を生み出しています。

Kindle の位置No.3866-3878

これは大事な視点ですね。ウェブサイトを設計するにあたり、つい平均的な訪問者を想定してしまいがちですが、むしろ平均からもっとも遠い位置をどこに置くか（どこまで極端なユーザーをターゲットに含めるのか）を考えるべきかと思います。

激しく同意した一節でした。

第10章 フィルターウィジェット

§

role="form"

§

ARIA in HTMLでは、form要素は暗黙のformロールを持ち、明示的にrole="form"を指定すべきではないとされています。しかし実際には、多くのスクリーンリーダーの実装は、role属性のないform要素をランドマークとしては扱いません。そのため、role属性を明示的に指定するとランドマークとして扱われ、ランドマークにジャンプする機能で移動できるようになります。

なお、ほとんどのスクリーンリーダーは、フォームコントロールにジャンプする機能を備えています。role="form"の指定がない場合でも、フォームに飛ぶ機能を利用すれば比較的容易に戻ることができるでしょう。

Kindle の位置No.4713-4718

これは知りませんでした。手元の NVDA 2018.1jp を使って複数のブラウザで確認してみましたが、確かに role="form" を付けると「フォーム ランドマーク」と読み上げられ、 D キーのショートカットでの移動も行われました。

これまで自分は検索フォームのみ role="search" を付け、それ以外のフォームは role 属性を書かないようにしていたのですが、ランドマーク扱いされた方が便利だったりするのでしょうか。日常的にスクリーンリーダーを使っている方の意見も聞いてみたいところです。

第11章 登録フォーム

§

placeholder属性

§

プレースホルダーのスタイル設定について、以下のコードが示されています。

::placeholder {
  color: #000;
  font-style: italic;
}

::-webkit-input-placeholder {
  color: #000;
  font-style: italic;
}

::-moz-placeholder {
  color: #000;
  font-style: italic;
}

また、訳注では IE と Edge の対応について補足されています。

Internet ExplorerやEdgeにも対応させたければ、::-ms-input-placeholderも追加すると良いでしょう。

Kindle の位置No.5621-5622

これらはちょっと正しくなくて、実際は以下のような状況となっています。

  • Firefox 19 以降のデフォルトスタイルは、 color による灰色文字ではなく opacity: 0.54 による透過度が設定されている（参考: Bug 556145(bugzilla.mozilla.org)、Bug 618260(bugzilla.mozilla.org)）
  • Firefox は2017年1月にリリースされた バージョン 51 で接頭辞無しの ::placeholder に対応したので、 -moz- 接頭辞付きはもう不要（参考: Bug 1069012(bugzilla.mozilla.org)）
  • IE 11 は疑似クラスのみサポートしているので、シングルコロンの :-ms-input-placeholder が必要
  • Edge は ::-ms-input-placeholder の疑似要素をサポートしているが、 -webkit- 接頭辞にも対応しているので -ms- 接頭辞の疑似要素はわざわざ書く必要なし

まとめると、 IE 11 や Android 4 系などの古いブラウザも考慮した、2018年3月時点での記述はこんな感じが良いでしょう。

::-webkit-input-placeholder {
  color: #000;
  font-style: italic;
}

:-ms-input-placeholder {
  color: #000;
  font-style: italic;
} /* IE 11 用 */

::placeholder {
  color: #000;
  font-style: italic;
  opacity: 1; /* Firefox 用 */
}