［連載］徹底解説！インクルーシブHTML + CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン (10)

こんにちは、freeeの伊原です。freeeに参加して8ヶ月ほど経ちますが、ようやくアクセシビリティ対応に関する最初のリリースを出すことができました。「freee が「人事労務freee」のモバイルアプリをリリース。モバイルアプリの活用と勤怠機能の強化で、日々の勤怠入力を効率化」というプレスリリースの中で、このアプリがiOSのVoiceOver（画面読み上げ）に対応したことが触れられています。実際の動作の様子はYouTubeでご覧いただけますので、ぜひ一度確認してみてください。AccSell主宰の中根さんも第141回のポッドキャストで「結論から言うと良くできている」と評価してくださったので、ひと安心です。

こういった対応を事業会社のなかでやってみて思ったこととしては、やはり「アクセシビリティ対応が社会にとって、会社にとって、製品にとって、チームにとってどういう意味があるのか」を明らかにしていくことが大事だ、ということです。ビジネスとして対応し、そこに工数が割かれる以上、そのお題にちゃんと応える必要があるわけです。今回の対応にしても、実際このアプリの存在によって導入に至った企業があるか、そこで実際にアクセシブルになった事例はあるか、ということが今後問われていくことになります。

......というわけで宣伝です！企業や団体に所属するみなさま、経理や人事労務の分野をアクセシブルにしていくことにご興味が有りましたらぜひ私までお問い合わせください！ あ、ちなみに「いま職場の経理や人事労務が関わるところで、こういうことで困っている」的な、職場環境の改善に関するお話でも大歓迎です。実際のニーズに基づいた製品を開発し、それをまたAccSellで紹介していけるような流れを作りたいと思っておりますので、お問い合わせをお待ちしております。

さて、そんな声に応えるためにも、まずはコードレベルで何ができるのかをきちんと把握するのが重要！ということで、今回も書籍から内容をダイジェストでご紹介いたします！

11章：登録フォーム

前回までは商品リストやフィルターウィジェットといった、ウェブサイトもしくはECサイトの中身の話でした。ところで、実際に商品を購入しようとするときに、避けて通れないもう一つ重要な存在があります。それは登録フォームです。商品購入やサービスの利用開始時、多くのサイトではアカウントの作成とログインが必要となります。この関所を突破することではじめて利用が可能となるわけで、ここをアクセシブルにすることが真の入り口だったりするわけです。

また、現在のウェブサービスにおいて、フォームは重要な存在です。ユーザーとある程度複雑な情報（クリックやタップだけで済ませられない程度に複雑な情報）をやりとりするためにはどうしてもフォームを使う必要があるからです。たとえば私が所属するfreeeのサービスなどは、ほとんどフォームのカタマリと言っていい状態です。ウェブで最重要なのはリンク、ギリギリ2番手がフォームという説もあるぐらいです。

そして、フォームは他の要素と違って「一連の流れがすべてアクセシブルになっている必要がある」という存在です。フォームは、それが単に見えるだけでは役に立ちません。入力欄が認識できて、きちんと入力できて、エラーがあれば修正し、送信が完了してこそ「情報にアクセスできた」となるのです。「フォームは送信してもらえばこそ」というわけで、今回は登録フォームをアクセシブルにする方法について迫っていきます。

登録フォームの置き方から考える

「登録フォーム」と聞くと、ついフォームコントロールの話から入りたくなりますが、それより先に、まずフォームをどのように配置するかという点について考える必要があります。この書籍では登録フォームがいつもログインフォームのあとに「アカウントをお持ちでない方」的なリンクで置かれることについて問題提起しています。確かにこのように配置すると、ログインフォームをすべて通過してからでないと登録フォームに移動することができません。

これを解消する案として、ログインフォームと登録フォームをタブにするという手段を紹介しています。このようにすればスクリーンリーダーであっても、視覚的にも、最初にどちらのフォームに用があるかをユーザーが選択できます。以前もこのような「視覚でも聴覚でもわかりやすくするには？」と考えてみるのがインクルーシブデザインであり、その結果どちらにとっても現状より良い案になる、ということはいろいろありそうです。デザインを検討するときのtipsとしてぜひ押さえましょう。

フォームといえばlabel

さて、実際のフォームコントロールの話に移っていくわけですが、まずはコードを見てみましょう。

<form id="register">
    <label for="email">メールアドレス</label>
    <input type="text" id="email" name="email">
    <label for="username">ユーザー名</label>
    <input type="text" id="username" name="username" placeholder="例:HotStuff666">
    <label for="password">パスワード</label>
    <input type="password" id="password" name="password">
    <button type="submit">登録する</button>
</form>

この中でまず大事なのは、label要素を使って入力欄に紐づくラベルを与えているという点です。このようにしておけば、入力欄から別の入力欄に直接移動しても、その入力欄に紐づくラベルがスクリーンリーダーで読み上げられるようになります。NVDAなどのスクリーンリーダーでフォームを利用する際は、フォーカスモードという、いわゆる「キーボードのタブキーで入力欄を移動して入力」という通常のキーボード利用時と同じ操作を繰り返して入力していくことになるため、入力欄にフォーカスした際にそのラベルが読み上げられる必要があるわけです。

ちなみにlabel要素には暗黙的な書き方（label要素内にテキストラベルとinput要素を入れる）と、明示的な書き方（input要素のid属性値をlabel要素のfor属性で参照して紐付ける）の2種類の使い方があります。仕様上はどちらを使っても良いはずですが、スクリーンリーダーによっては明示的なほうでなければうまくラベルを読み上げないケースがあるようです。できれば明示的な書き方にしたほうがよいでしょう（label要素内にinputを入れている場合でも、for属性で紐づけたほうがよさそうです）。

とはいえ、ページ内にあとからinput要素が出現する場合などでは動的にidを付与しつつfor属性で参照する必要があったりするため、暗黙的な書き方のほうが使い勝手がいいケースもあります。このあたりはコストパフォーマンスを考えるとなかなか悩ましい部分ですね。

つづきはメルマガで……。