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

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

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

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

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

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

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

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

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

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

本書でも

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

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

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

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

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

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

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

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

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

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

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