制作者のためのHTML

アクセシビリティという文脈において、何のためにHTMLを書くかという話になると
マシンリーダビリティのため
スクリーンリーダーのアクセシビリティのため
というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています
もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています
僕がどういうものなのかというと、

参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter
ツイッターでは「全部入りHTML太郎」という名前でやっています

参照: シフトブレイン／スタンダードデザインユニット
仕事としては、株式会社シフトブレインという受託のウェブ制作会社で、フロントエンドエンジニアをやっているんですが、会社の中で、スタンダードデザインユニットという部署的なものを作って、普通のウェブサイトを真っ当に作りたいというスタンスで働いたりしています
要はHTML好きな実務者という感じなんですが、その立場から、制作者にとってのHTMLの有用性というものについてよく考える機会があります
さてここから本題に入ります
僕の中ではHTMLには2つの意味でのフレームワーク的な側面があると思っています

画面を実装するためのUIフレームワークとしての面
デザインを検証するための思考のフレームワークとしての面
ひとつずつ見ていきます

ウェブサイトを実装するためのUIフレームワークというと、BootstrapとかFoundationとかjQuery UIなどいろいろ有名なものが連想されると思います

それらのフレームワークは、ウェブサイトを制作するというときに、よく使われたり、便利だったりするコンポーネントをパターンとして提供しています、ということはみなさんご存知だと思います
パターンに則ってサイトを制作すると、効率的に作れたり、ある程度いい感じのデザインになったりするということで、賛否両論あったりしますが、ある程度市民権を得ていると思います
ですが、意外と意識されないのが、それらのフレームワークはHTMLの上に成り立っているということです

Bootstrapなど一般的にフレームワークと呼ばれるものはHTMLの上に成り立っている

Bootstrapを使って制作するときは、Bootstrapのパターンについては意識されますが、その前に、HTMLのパターンというものについて考えることがあまりなされていないのではないかと思います
HTMLのパターンと言うとイマイチ何を指しているのか曖昧な感じがします
よくある例ですがbutton要素を使うとどういう意味があるかという視点から説明してみます

button要素の特徴としてはマウスでクリックしたりキーボードで押したりできることです
マウスでクリックできるというのはいいとして、キーボードで押せるというのは、ウェブサイトを見てるときに、Tabキーを押してフォーカスを移動させたら、そのボタンがフォーカスされている、つまり選択させれている状態にできて、その状態でスペースキーかエンターキーを押すと、そのボタンに紐づけられている動作を実行させられるということです
こうしたキーボードのためのアクセシビリティは、JavaScriptなどを使って自前で実装することになると多少の手間がかかりますが、button要素にはそれがもともと組み込まれているので、button要素を使うということだけ考えていればうまくいきます
支援技術のユーザーに特有の対応としては、このスライドを見ていただきたいんですが、
今スライドに表示されているのはChrome DevToolsのAccessibilityというパネルなんですが、buttonとしてマークアップした要素を選択すると、こんな風にプロパティが表示されます
上から、Name: 送信、Role: button、Focusable: trueと出てます
Invalid user entryというのはこの話とあまり関係がないので無視してください
これはスクリーンリーダーなどの支援技術から読み取れる情報の一部です
支援技術から見ると、「送信」という名前で、ボタンというroleを持っていて、フォーカスできる、という意味になります
roleというのはそのUIの種類です
roleの値には、buttonの他には例えば「heading」「list」「menu」「note」「search」とか、結構いろいろあります
これを実際のHTML要素に適用するためには、role属性を使ってあげればよくて、例えば、div要素にrole=list（イコール）とかつけてあげると、支援技術からの見え方としてはその要素はリストであるという意味になります
ではlistというroleになると具体的にはどうなるかというと、スクリーンリーダーではその要素を選択したときにそれがリストであると読み上げられて、リストの項目数も教えてくれたりします
これがheadingだったら見出しジャンプという機能が使えて、Hキーを押すとページに存在する見出しだけを辿っていって拾い読みができるようになったりします
ただ、このbutton要素にはrole属性を指定していませんが、このようにbuttonというroleが割り当てられています
これを暗黙のWAI-ARIAセマンティックスと呼びます
それがbutton要素であるというだけで、暗黙的にそれがbuttonになります
暗黙のWAI-ARIAセマンティックスには他にも、body要素にはdocumentというroleが割り当てられたり、href属性を持っているa要素にはlinkとか、alt属性に中身があるimg要素にはimgとか、そういった定義が100個以上あります
このおかげで、必ずしもWAI-ARIAに関する知識がなかったとしても、普通にHTML要素を選んでいさえすればある程度のマシンリーダビリティが保証されるということになります
roleが定義されないものもたくさんありますが
ということで、button要素を使うということの裏で、ボタンをボタンとして利用できるようにするために手立てが講じられているという話をさせていただきました

参照: Human Interface Guidelines - Design - Apple Developer
ここでちょっと、ウェブ以外のプラットフォームに目を向けてみます
例えばiOSとかmacOSを作っているAppleでは、サードパーティの開発者向けに「Human Interface Guidelines」というUIデザインの原則を定めたガイドラインを公開しています
ガイドラインはAppleが開発用に提供しているUIフレームワークと連動した内容になっているんですが、そのUIフレームワークの作法に則って素直に作るということが、結果的にそのプラットフォームらしい良いUIを実現するための手法となっているそうです
すると、画面のパターンを決めるときなんかには、デザイナーが独自の何かを考えるというより先に、既存のパターンから選ぶというのが来ます
つまりフレームワークがそのプラットフォームの慣習を決めているということになります
それによって、制作者が作りやすいように作ることで、自ずとユーザーにとってもすでに学習されていて、親しみやすいデザインというのが実現される構図ができるのだと思います
それらに近い意味で、HTMLらしいHTMLを書くということが良いウェブサイトを作るための手法として捉えられないかなと考えています
もちろんHTMLとそれを同じ毛色のものとして扱うには無理があるとは思いますが、伝えたいこととしてはそういう意図です

Bootstrapだけでなくその土台となっているHTMLもまたフレームワークである

さて、この話を踏まえると、Bootstrapなどのフレームワークより先にHTMLがあるという感覚がなんとなくわかっていただけるようになったと思います
Bootstrap以前に、HTMLがすでにフレームワークだと思います
Bootstrapのような一般的にフレームワークと呼ばれるものは、HTMLと協調する形で作られていますが、それに加えてサイト固有のパターンもまたHTMLと協調しなければならないと思います
フレームワークというのは、単に作る手間が減るというだけでなくて、一貫性のあるものを品質高く提供できる仕組みでもあります
ウェブデザインにおいても、HTMLがフレームワークであるという意識を持つことで、よりプリミティブなレベルでの一貫性があって学習しやすいものを作れるはずです
例えば先ほどのボタンにしても、キーボードでフォーカスできたり、スペースキーやエンターキーで押せたりという、一見取るに足らなそうな小さなインタラクションのひとつひとつが確実に実装されているということが、ユーザーが常に思い通りに使えるものを作るための土台になるのではないでしょうか

さてここからはHTMLがデザインを検証するための思考のフレームワークになるという話です

価値仮説シート：（ユーザー）XXXは、（欲求）XXXたいが、（課題）XXXなので、（製品の特徴）XXXに価値がある。

この場合のフレームワークとは、UIフレームワークとは違って実体がない抽象的な意味を指しています
といってもいまいちピンとこない感じがするので、具体例で説明してみます
新しい製品を作るための方法論について書かれた「リーンスタートアップ」という本があるんですが、この本では、製品を作り始める前に、このような価値仮説シートを埋めることを提案しているそうです
虫食いになっている一文があって、その4箇所を埋めるという形になっているので、今から読み上げます
まず、ほげほげは、ここにユーザーが入ります
ほげほげしたいが、ここにユーザーの欲求が入ります
ほげほげなので、ここにユーザーの課題が入ります
ほげほげに価値がある、ここに製品の特徴が入ります
この虫食いを埋めてシートを完成させるとすれば例えば、

シフトブレイン／スタンダードデザインユニットは、誰もが簡単に、快適に使えるウェブを作ることを目標として掲げている

「企業のウェブ担当者」は、「誰もが簡単に、快適に使えるウェブサイトを作り」たいが、「求める品質を提供できる制作会社が少ない」ので、「シフトブレインスタンダードデザインユニット」に価値がある
お仕事依頼お待ちしております
みたいな感じで、意味の通った一文ができます

で、この虫食いを埋めるのにどういう意味があるのかというと、ここに入る言葉を考えるということは質問に答えているということと同じです
誰が何をしたいのか、何が障壁になっているのか、それをどうやって解決できるのか、そういった部分が盲点になっていたときに、質問をきっかけにして言語化できるというフレームワークです
そして、HTMLを書くこともこの価値仮説シートのように質問を促すトリガーになります
HTML要素を選択したり、階層としての関係性を考えたり、そうした試行錯誤によってHTMLというアプローチから盲点を見つけ出すことができます

ウェブサイトを作るということになると、デザインカンプみたいなものをなんとか作って、そこに重点を置きながら実装を進めるという仕事の進め方がよくあると思います
カンプというのは、実際に実装される画面の描画結果のプレビューみたいなものを指してそう呼んでますが、それだけを見て作業を進めてしまうと、どうしても抜け落ちてしまうことがいろいろあります
実際の仕組みがどうなっているのかは意識せずに作れてしまいますし、プロジェクトの進行に応じて画面を構成する要素が増えたり減ったりする中で、複雑なビジュアルデザインを実現することに手いっぱいになってしまって、デザイナー自身も画面上の要素の関係性をうまく把握できていないということがあります
その混乱を解きほぐすための手立てとして、HTMLからの視点が有用だと感じることがあります
僕がカンプを見るときにはいつも、文書として妥当なアウトラインになっていて、視覚的な階層はそれに基づいて作られているか、というのを確認します
セクションはきちんと意味に基づいて入れ子になっているかとか、見出しレベルが同じになるべきところで別の表現になってないか、あるいは逆に違いがあるときに同じ表現になっていないか
そして見出しレベルが明確になれば、それに応じてあるべき量の余白があるか
実際にHTMLを書いてみることで、そういったところに矛盾がないかを簡単に見つけることができます
例として、このスライドに表示している架空の会社のサイトのトップページをアウトライン化してみます
この会社はお菓子を作っている会社で、トップページには上から、
お菓子のヒーローイメージ
広告
新商品
定番品
製造体験
問い合わせページへのCall to action的なリンク
が配置されています

上部の要素はmain要素としてセクショニングできて、問い合わせはそれと隣接する形でaside要素としてセクショニングできる

このうち、問い合わせページへのリンクはトップページに限らず毎ページに配置されていて、トップページに関連して存在しているという要素ではないので、main要素の外ということで最初に除外できます

お菓子のヒーローイメージ、広告、新商品、定番品はsection要素としてセクショニングできて、製造体験はそれと隣接する形で同じくsection要素としてセクショニングできる

次にmain要素の中を見ていくと、お菓子のヒーローイメージから、広告、新商品、定番品は、お菓子という括りでひとつのセクションとして見なせそうです
広告はお菓子とは関係ありませんが、実装上の都合で妥協してお菓子のセクションに含めてしまいます
残りの製造体験はそれだけで独立したセクションになるというのはわかりやすいと思います

visuallyhiddenクラスを付与したh1要素をページの見出しとして挿入して、同じぐお菓子に関係するセクションにもvisuallyhiddenクラスを付与したh2要素を挿入する。製造体験の見出しはh2としてマークアップする。

次にお菓子のセクションと製造体験のセクションの見出しについて見てみます
このページにはお菓子のヒーローイメージ、新商品に定番品など、お菓子に関係する要素が配置されているんですが、実はそれがお菓子であるということを明示する見出しがありません
これはビジュアル的には自明であるということでなしにしたのかもしれませんが、ページ全体のアウトラインを考えるためには明示的にしておく必要があります
実際にHTMLを書いてみるという利点は、こうした要素同士の暗黙的な関係性をはっきりさせられるということです
見出し要素やsection要素などを使ってHTMLとしてアウトラインを表現すると、概念的で伝わりにくそうな階層構造を明確な形で表せるので、チームのメンバーにこのことについて説明する場合も役立てられます
続いてお菓子の見出しですが、ビジュアル的には自明だったとしても、HTML的にはあると良い情報なので、visuallyhiddenというCSSのハック的なテクニックを使って、要素としては存在するけど視覚的には見えない見出しにしてみます
visuallyhiddenのスタイルの内容についてはググってください
製造体験の方には見出しがついているので、普通に見出しとしてマークアップします
お菓子と製造体験はどちらかが親ということではなく、並列な関係なのでh2としておきます
ただ、そうするとh1にあたる見出しがありません
これはトップページあるあるで、トップページにあえてトップページと表示されることはほとんどないので、本来そのページのタイトルを表示すべきh1が行き場を失ってしまいます
なので、ここは先ほどのvisuallyhiddenを使います
こうすることで、制作者の立場からHTMLを読むと、ここには暗黙的なセクションがあって、お菓子に関係するセクションで、それは視覚的には自明なので省略している、みたいなことが誤解なく伝わるようになります

広告はaside要素としてセクショニングして、新商品と定番品はsection要素としてマークアップする

さらにお菓子のセクションをアウトライン化していきます
まず広告はお菓子に関係がないということを示すためにasideとしておきます
残るは新商品と定番品ですが、こちらも新商品には見出しがあって、定番品には見出しがありません

新商品の見出しは普通にh3要素としてマークアップして、定番品には見出しがないのでvisuallyhiddenクラスを付与したh3要素を挿入する

ということで傾向と対策に則って、定番品にはvisuallyhiddenで定番品という見出しをつけておきます
お菓子の見出しレベルが2だったので、その入れ子になっている新商品と定番品は3になります

main要素内にはホームという見出し、お菓子のセクション、製造体験のセクションがあり、main要素に隣接する形でaside要素として問い合わせがある

というわけで長々と説明してきましたが、これらの思考の手がかりにしたのはたったこれだけのHTMLです
こうした過程を経ることで、まずHTMLにした人自身がカンプで表現されていることについて深く理解できます
そしてその結果を共有することで、曖昧になりがちだったコミュニケーションが改善されることも期待できます
時間がそれほどかからない割には、効果的だと思うのでぜひ試してみてください
カンプをもとにしてHTMLを書くということは開発する上ではごくごくありふれた作業ですが、HTMLをカンプに合わせるというよりも、HTMLとしてのあるべき形を考えることをきっかけとして、結果として最終的なデザインを改善できるというところに僕は面白さを感じます
反面、ビジュアルを作り出すためのスピードを求めてカンプばかりが偏重されてしまって、HTMLの可能性をなかったことにしてしまうのはとても残念なことです
こうした視点をきっかけのひとつとして、より良い方向を目指すためにアプローチできればいいなと考えています

というわけで実は制作者のHTMLを書くという視点から、結果的にアクセシブルにする方法について語っていました
WAI-ARIAとかスクリーンリーダー対応とか、何から始めればいいのかわからなくて困ってるという方は、とりあえず普通のHTMLの書き方を考えてみるというところから初めてみるとよいと思います
ありがとうございました