「Form Design Patterns」第1章まで読んだ

先日発売された「Form Design Patterns」を購入しました。ウェブの「フォーム」に焦点を当てた解説本です。

本当は最後まで読んでから感想記事を書くのがいいのでしょうけど、自分の読書ペースだと年内に読み終わるのは難しそうなので、全9章のうち取り急ぎ第1章「登録フォーム」のみを読み終わった段階での感想を書いてみます。

  1. プレースホルダー
  2. メールフィールド
  3. パスワードフィールド
  4. ボタンスタイル
  5. バリデーション

プレースホルダー

§

プレースホルダーをサポートしていないブラウザやスクリーンリーダーがあるうえ,長いヒントテキストは途中で切れる可能性があります。

プレースホルダー(p.22)

スクリーンリーダーの対応はさておき、現在サポートが続いている主要ブラウザはすべて placeholder 属性に対応しています。古いブラウザやマイナーブラウザを意識した記述なのか、それともスクリーンリーダーと組み合わせた意味で未対応ブラウザがあるという意味なのでしょうか。

なお、 placeholder には本書で触れられている以外にも Google 翻訳にURLを突っ込んでページごと翻訳した際に属性値が翻訳されないという問題が挙げられます。本質的なデメリットではなく、どちらかというと Google 側に対応してほしい問題な気がしますが、個人的に海外サービスを使うときに困ることがあるので、サイトの運営者には現実的にそういう問題もあるということを意識していただけるとうれしいです。

また、ARIAは、ネイティブ要素と同レベルのブラウザ対応は見込めません。この例においても、 aria-describedby は Internet Explorer 11 でサポートされていないのです。これが、「ARIAの使用で一番大切なのは、ARIAを使用しないこと」とされている理由です。

プレースホルダー(p.23)

この文章は「ARIAよりネイティブ要素の方がブラウザ対応が良い」という誤解を招くのではないでしょうか。例に挙げられているのは <label> 要素と aria-describedby 属性を比較したものであり、 HTML4 時代から存在する <label> が相手ではaria-describedby がブラウザ対応的に不利(html5accessibility.com) なのは当然です。

一方で、 HTML5 で登場した <main> 要素などは当初ネイティブ要素の対応が遅れており、その対策として <main role="main"> といったように、事情を知らない人が見れば無駄にも思える属性指定をしたものです。以前はW3C の HTML5 仕様(W3C) にも、「しばらくの間は role="main" を付けることを推奨する」という旨の注意文が書かれていたほどです。

そもそも、本書で言及されている「Using ARIA」の2.1 First Rule of ARIA Use(W3C) を見ても、「ネイティブのHTML要素または属性が使用できる場合はそれを使うべし」という旨のことは書かれていますが、その理由にまでは言及されていません(ブラウザの対応度合い云々といったことは書かれていない)ので、「これが……とされている理由です」と断言されている根拠が謎です。

WAI-ARIA の使用でよく言われることとして、変な使い方をするくらいならやらない方が良い(初学者は「ともかく ARIA を使わない」方針でも良い)といった意見は耳にしますが、本書に書かれているようにブラウザの対応度合いを理由に ARIA を避ける必要はないと考えるのですが、いかがでしょうか。

メールフィールド

§

p.31 でメールアドレス入力欄のラベルに関して、英語の場合は「Email Address」のように各単語の頭文字を大文字にする(タイトルケース)よりも、「Email address」と文頭や固有名詞の頭文字のみを大文字にする方(センテンスケース)が読みやすいという主張が紹介されています。

引用元の記事Making a case for letter case(medium.com) を読むと、締めの結びで「どちらにも利点はあるので理にかなった方法を採れば良い」という旨の結論がなされており、特に短いフォームラベルではタイトルケースの方が有用と考えられる場合もあると思いますが、いずれにしてもこういった点に目を向けるのは重要なことかと思いました。

パスワードフィールド

§

時々話題に挙がる(※弊TL調べ)パスワード表示機能について言及されています。パスワード入力欄の横に置かれたボタンを押すごとに type="password"type="text" を切り替えるやつですが、これには様々なデメリットが存在します。

本書でも

JavaScriptによる独自実装で、type属性をtextに切り替えられるようにすると(type="password"のときには受け付けないようにしていた)全角入力が可能になってしまったり、その他さまざまなリスクが考えられるため、慎重な判断が必要となる。

パスワードの表示(p.36)

と注意喚起が行われていますが、全角入力の問題は pattern 属性の設定によりある程度緩和可能です。

むしろ type="text" にしている間は入力したパスワードがスクリーンリーダーで読み上げられてしまうことや、ブラウザへの自動保存(オートコンプリート)との相性といった点に注意したいところです。オートコンプリート問題の詳細はパスワードマスクの切り替え機能について考えるの記事で考察しているので参照ください。

これらを解決する一案として、<output> 要素を使ったパスワード表示機能(codepen.io) を考えてみました。これならアクセシビリティやセキュリティ上の問題は起こらないように思えるのですがどうでしょうか。 ::ms-reveal { display: none } をする必要もありませんし。

ボタンスタイル

§

送信ボタンは <input type="submit"><button type="submit"> で実装することができますが(本当は <input type="image"> も送信ボタンです)、 <button> 要素の注意点として以下の記述があります。

古いバージョンの Internet Explorer では、複数の <button type="submit"> がある場合、どれがクリックされたかに関係なく、すべてのボタンの値をサーバーに送信します。

ボタンスタイル(p.40)

確かにその通りではあるのですが、これは IE 6 で見られた事象です。フォームが正しく動作しないという致命的なバグではありますが、もうさすがに気にする必要はないと思います。

逆に、この問題を考慮するほどの案件ならば、 IE 7 で value 属性値ではなく <button> 要素の中身がURLエンコードされて送信されてしまう問題も考慮する必要があります(詳細はMDN の <button> 要素のページ内で言及(developer.mozilla.org) されています)。

こういった事象が存在したのは、 <input> 要素はRFC 1866(HTML 2.0)(tools.ietf.org) 時代からあるのに対して、 <button> 要素はHTML4 で登場(W3C) した比較的新しい要素だからで、そのため昔は <button> 要素を採用するのは難しく、とくに iモードの存在を考えるといろいろとトラウマが蘇ってきて(ry

いずれにしても、 IE 7 以下や古い iモードのガラケーに対応するようなケースでもなければ、今どき <button> 要素の使用を避ける必要はありませんね。

バリデーション

§

p.48 でエラーメッセージを対象フィールドの近くに配置する際、フィールドの下ではなく上に表示する例が挙げられています。これ自体はスクリーンリーダーにおける読み上げ順序の問題などで大昔から言われている概念ですが、本書では下側を避ける理由としてブラウザのオートコンプリートパネルやオンスクリーンキーボードの存在(adrianroselli.com) が挙げられています。これは個人的に意識していなかったことなので、なるほどなぁと思いました。

スクリーンリーダーの読み上げ順序の問題だけであれば、 WAI-ARIA を使ってエラーメッセージとラベルを紐付ければ下側表示でも大きな問題は生じないと考えていたのですが、こういった事象もあるとなるとやはり基本的には上側表示の方が望ましそうです。とはいえ、 ラベル → 入力ヒント(入力可能文字種などの説明) → エラーメッセージ → 入力フィールド の配置だと、ヒントやエラーメッセージの文言が長い場合にラベルと入力フィールドが離れてしまうのはそれはそれで問題でしょうし、結局のところは状況に応じて判断するのが適切な気がします。

なお、 p.49 で入力エラー時のスクリーンリーダー向け対策として <input aria-invalid="false"> のコードが例示されていますが、これは <input aria-invalid="true"> の誤りと思われます。


とくに気になる部分についてのみ書き出してみましたが、この他にも学びを得た部分、賛同する部分、同意できない部分など多数あり、読み応えのある本となっています。

本文中には HTML や JavaScript のコードが多数含まれており、どちらかというとエンジニア向けですが、フォームの要素や配置の決定はコーディングフェーズで覆せるものではないため、ウェブ制作の上流工程で関わる方にもぜひ読んでいただきたいものです(コード部分は読み飛ばしても差し支えありません)。

一方、エンジニアにとっては具体的な実装方法も含めて参考になる部分が多いでしょう。本書で紹介されている各種フォームはデモが用意されており、監訳を務められた土屋一彦さんによる告知記事(website-usability.info) からリンクが張られているので、実際の動作を見ながら読み進めていくのも良いかもしれません。