こんにちは、JobPicks チームにてフロントエンドを担当しております、イイダです。 今回の記事では、Web Client の開発をしていく中で、私達が日頃どういった視点で "HTML" と向き合っているかという話をさせていただきます。
私達は、「表示データをできるだけ正しく HTML の element tag で表現する」ため、日々模索しています。 「表現方法」なので「これが絶対に正しい」なんて言えない部分もありますが、「みんなとHTML talk したい！」と思い、筆を執りました。 温かい目で読んでいただけるとありがたいです。
この記事を読む前に
フロントエンドと一言でいえど、関連の分野は多岐に渡ります。 Web Accessibility、HTML Semantic Elements、Web Performance、Web Architecture等、パッと上げただけでもその幅の広さを感じます。 このブログでは特に「Web Accessibility」「HTML Semantic Elements」の視点で読んで頂ける内容になっています。 その他に関してはまた別の機会で紹介させてください。
HTML と向き合うってどういうこと？
HTML とは HyperText Markup Language の略称で、HTML: HyperText Markup Language | MDN でも紹介されている通り、ウェブのもっとも基本的な構成要素です。 現在は WHATWG が策定するリビングスタンダードが HTML と DOM の唯一の標準となっています。 （ 2019年の5月28日に発表された WHATWG と W3C の間で行われた合意 のニュースも記憶に新しいです。）
HTML は Web 開発に携わったことがある方でしたら誰しもが触ったことがあるだろう身近なものだと思います。 なので、その身近さゆえに「向き合う」と言われた時に「今更？」と困惑する方もいらっしゃるかもしれません。
そんな方には是非 HTML の element tag の一覧をご覧になっていただきたいです。 HTML Living Standard に掲載されている Text-level semantics だけで 29 種類もあります。 思ったより多いと感じた方もいらっしゃったんではないでしょうか？
我々は、Web フロントエンドエンジニアとして、 Web のプラットフォームに関わる上で、上記の通り表現力豊かな HTML の element tag を使用しながら、配信する情報やデータをより正確にお届けするよう精進しております。 （故に、コードレビュー中で使用する element tag について言及することは日常的な光景です！）
どうして気にかけているの？
- Web のプラットフォームに関わっているならルールを守って関わるべき
- そこに定義があるから定義を守ろう（より適した道具を使おう！）
- ルールをちゃんと守れている開発チームってかっこよい
など理由は沢山ありますが、一言でいうと
- メディアとして、より正しい情報をより正しく表現し、読み手側に伝えたい
というのが大きいです。
Web Accessibility (a11y) の視点
表現手法としての HTML の話をしましたが、その表現は Web コンテンツとして多岐にわたる表現がカバーされています。 特に Web Accessibility の文脈でも語ることができます。
昨今、Web Accessibility の話もたくさん耳にしますし、業界での取り組みには本当に学ぶことが多く、できうる範囲で弊チームでも気をつけています。 でも「Accessibility やってるよ」って言うのって（本来だと、息をするように対応、向上できていたらいいのですが）結構大変だと思うんです。
支援技術 *1 が必要な当事者の方にテストを受けていただきたい気持ちもありますが、なかなかそこまで手が回らないのが現状です。 そんな中、「誰でもできる Web Accessibility」という意味では「正しく HTML の element tag を選定する」というのが一番身近なんじゃないでしょうか。
例えば、「タップ領域は 48px 以上の領域をもたせる」「色のコントラストをチェックする」などデザイン的なところもあると思いますが（もちろん項目をチームで気をつけていくことはとても重要！）、「押す UI のものをキーボード操作でフォーカスできる＆押せる」「リストから選択する UI をキーボード操作で選択できる」などは正しい HTML element tag を選定していたらすぐに対応できます。 こんなに身近な Accessibility への一歩ってないと思いますし、それをしっかり自分が守ることで「今、利用者や読者が一人増えているかもしれない」と希望を持って、コードを書くことができています。
希望を持ちながらコードが書けるって、私にとってとてもうれしいことです。
具体的にどういった形で向き合っている？
では、実際に JobPicks プロダクトでは、どのような表現、どのような向き合い方を行っているか紹介させていただきます。
コーディング面
表現の例として、JobPicks のトップページにある「転職・就活のヒント」セクションをあげたいと思います。
みなさんだったらどのような HTML の構成にしますか？ 私がザックリ考えた例を以下に記すので、是非比べてください。（そして、HTML talk しましょう）
私は、最初に弊チームデザイナーさんからデザインデータを受け取ったタイミングで、
- 並列の情報がリストとして横並び表示
- 扱っているデータは「記事」データ
- 記事の情報として、画像、タイトル、関連する職業の名前、公開日の時間が掲載
の構成だと思いました。
よって、簡単ではありますが、（とても大雑把に、ザックリ）HTML の構成は以下のようになると考えました。 *2
<ul>
<li>
<a href="記事へ遷移するための URL">
<article>
<img /> or 背景画像を持つ <div>
<hN>記事のタイトル</hN>
<span>関連する職業の名前</span>
<time>公開日時</time>
</article>
</a>
</li>
{/** 上記と同じため省略 **/}
</ul>
それぞれの element tag の意味をここでお伝えするのも冗長だと思うので省きます。 （もっと知りたいという方は、是非 HTML の Documnt を参考にしてみてください）
「意外と普通じゃん」って思われるかもしれないですが、実はこの「普通じゃん」がとっても重要です。 （開き直りのようにも聞こえると思いますが、）なぜなら「普通」こそが「Standard に則っている」とも言えると考えられるからです。
「じゃあ、どういったところに気をつけているのか」というと、tag 選定時に「本当にそれか？」という問いを自身に投げながら選定しています。 先述した通り、 tag には多くの種類があります。それぞれの意味に対して一番近い使い方を狙って選定する必要があります。
例えば、要素を囲む element tag を考えた際に div と打った後「本当に div か？」と問います。
なぜなら、そのデザインは「囲う」以外の意味がそこにあるかもしれないからです。
（ご理解いただけていると思いますが、 div を使用することが悪いという意図は全くありません。）
以下のスクリーンショットは、現在 HTML Living Standard 内に掲載されているSections と Grouping content として定義されている tag 一覧です。
どれも「囲う」際によく用いられる element tag ですが、それぞれ別の意味を持っています。 あなたが今実装しようとした component のその「囲う」デザインは「囲う」以上の意味はありましたか？ もし近しい意味を持つ element tag があれば、是非使用してみてください。 きっと表示されるデータはその element tag を待ってます！
デザイン面
JobPicks は2020年10月末にリリースされたサービスなのですが、サービス開発前にデザイナーの方と「JobPicks accessibility 方針」といった Document を共有*3させていただきました。 そこには具体的な「気をつけられる、デザイン面に関わるアクセシビリティポイント」をまとめています。 まだまだ対応できていない部分もありますが、実装者だけでなく、デザイナーの方と協業して気をつけられる環境を目指し、チームで取り組むことができました。
意外に大きかったのが、NewsPicks の開発メンバーからの反響です。 「気になってはいたけど、どう取り組むべきなのか」の疑問のヒントとして良いリアクションをいただきました。 今後 JobPicks だけでなく NewsPicks のプロダクト開発にも反映し、より良いプロダクトづくりの一つの道筋として向上を目指していきたいです。
社内やチーム内で、より考え方やトライしてる内容を広めたいとお考えの方は是非一度 Document 化してみてはどうでしょうか。 意外なところからリアクションをいただくこともあり、純粋にメンバーの考えを聞けることが楽しかったし、より「ちゃんとしないと」と身が引きしまるので、おすすめします！
おわりに
だいぶ駆け足になってしまいましたが、今回は HTML を軸にどういった思考で HTML の element tag の選定をしているかを紹介させていただきました。 少しでも現場の雰囲気が伝わると嬉しいです。
HTML が好きな方も、いったん Semantics の話をしたい方も、ユーザベースに興味がある方も、 是非ご興味がございましたら、UzabaseのCareerページをぜひご覧ください。「エンジニア」で検索してもらえればと思います。
心よりお待ちしております！
以下、個人的なおはなし
実は私も数年前まで、そこまでしっかりと HTML の仕様について深く理解していなかった頃がありました。 ある日、当時社内で開催されていた Web Accessibility に関する勉強会に参加しました。 「Web Accessibility に関する」と聞いていたのですが、フロントエンドエンジニアの先輩が HTML における Semantice（意味論）について少し SF チックな独自の路線（リスペクトを含んでいます！）の主張をされていました。
「いつか人が滅んだ地球に宇宙人がきて、HTML を何らかの方法で見れた時、その HTML がより（定義通りの方法で、Semantics 的にも）正しく書かれていた場合、滅んだ人類が扱っていたデータの内容を宇宙人にも伝えることができるかもしれない」
と、言葉は定かではありませんが、近しい内容を話されていました。 正直ちょっと笑ってしまったのですが、なんだかその後ワクワク感が止まらなくて、いつしか「宇宙人に伝わるぐらいの HTML を書けるもんなら書いてみたい」と思うようになりました。 それが私の HTML における Semantics 、HTML element tag に興味を持ったタイミングです。 もう何年も前の話ですが、その時お話してくださった先輩、ありがとうございました！
みなさんとも「宇宙人に伝わるぐらいの HTML」を一緒に模索できるとうれしいです！
謝辞
この記事を書く際に「 ちなみに、太字を b ではなく、 em とかに変更したりってできないんですかね？」と質問した時、担当者の方が爆速で「今追加しました！」とレスをいただきました。（em tag を使えるのかなと思って質問しただけだったので、まさか対応いただくことになるなんて…！ｗ）
迅速なご対応に、心より感謝申し上げます！
