CSS Nite LP54「Coder's High 2017」フォローアップ（2）伊原 力也さん（freee）+太田 良典さん（ビジネス・アーキテクツ）

2018年1月31日（水）

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、伊原 力也さん（freee）+太田 良典さん（ビジネス・アーキテクツ）の『多様なユーザーニーズに応えるフロントエンドデザインパターン：ベーシック編』セッションのスライドなどを公開します。

  • Googleスライド 実際のプレゼンで使用したスライドです。プレゼンテーションモードにしていただくと、コード右下の再生ボタンからスクリーンリーダーの読み上げ音声を聞くことができます
  • スライド（PDF）
  • 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

ご挨拶

ご参加ありがとうございました！マークアップが体験に大きく影響するということをお伝えできたなら嬉しく思います。少し手を掛けるだけでも対象ユーザーの範囲を飛躍的に増やせる可能性があるのが、Webフロントエンドの醍醐味です。それこそ、divをbuttonにするだけでも。ぜひ「規則を守る」という考え方から、「コードで体験をデザインする」という考え方にスイッチしてみましょう！またお会いできる日を楽しみにしております。

スライド

  • Googleスライド
    • 実際のプレゼンで使用したスライドです。プレゼンテーションモードにしていただくと、コード右下の再生ボタンからスクリーンリーダーの読み上げ音声を聞くことができます。

告知

書籍　

  • インクルーシブHTML+CSS & JavaScript
    • 本セッションで取り上げた本です。11月5日夜の時点では、amazonの在庫状況は特に問題なく、すぐに発送されるようです。
  • コーディングWebアクセシビリティ
    • インクルーシブ本と同じ、ヘイドン・ピカリングさんの前著です。こちらはWAI-ARIAの入門書として、よりマークアップに特化した内容になっています。
  • デザイニングWebアクセシビリティ
    • 戦略、要件定義、設計、デザインといった、Webデザインのワークフロー全体でアクセシビリティに取り組むための具体的なアプローチを紹介しています。

イベント登壇

あのTシャツ

質問へのご回答

アンケートやTwitterでお寄せいただいた質問や感想に回答します。

インクルーシブデザインという言葉について

質問・感想

  • 「インクルーシブ」って言葉、単語に「？」と思いましたが、中身はアクセシビリティの話だったのでがっかりしてしまった…。（セミナーの内容に、ではなく、また「新しい名称」作り出したのか…という意味です）
  • インクルーシブデザインっていろんな立場や（身体的）能力の人と一緒になってデザインをしていこう……という話と思っていたけど普通にアクセシビリティなのか……

回答

「インクルーシブデザイン」という言葉の一般的な意味はその通りで、極端な立場に置かれたユーザー (リードユーザー) と一緒にデザインをしていくようなことです。とはいえ本書ではもう少し広い意味で使っています。このあたりの話はAccSellポッドキャスト第122回でお話ししていますので、興味がありましたらお聞きください。

また、原著者のヘイドンさんが、なぜわざわざインクルーシブデザインという言葉を選んだのかを説明しているブログ記事もあります（英語です）。なぜアクセシビリティではなく、UXではなく、バリアフリー的な話ではなく、ユニバーサルデザインではなく、インクルーシブデザインという言葉を選んだのか。より詳しく知りたい方はこちらを読んでみると面白いかもしれません。

グラフィックデザイナーの定義

質問・感想

  • グラフィックデザイナーのたとえは少し悲しいです
  • グラフィックデザイナーは、実装のことはまったく考えていない人種……（と、本の中で定義されているのか）

回答

すみません。><
本書では「グラフィックデザイナー」を「コードが書けるデザイナー」の反対概念として言っていますが、もちろん、グラフィックデザイナーと呼ばれる人の全てが実装のことを全く考えていない、というわけではありません。ビジュアルデザイン専門であっても、実装のことやアクセシビリティのことを考慮したデザインができる人はいますし、そうであることが望ましいです。

マークアップ以外の職種

質問・感想

  • エンジニアもさることながら、PM、ディレクター、デザイナーがちゃんと聞くべき内容だと思いました。
  • コーダーだけでなくデザイナー、ディレクターも考えていくべきと思いました。
  • そろそろ現場でがんばってなんとかするみたいなのは限界だと思うので組織として…みたいな話を希望します

回答

高津戸さんのCSSのセッションで、マークアップの現場に降りてきたときに手遅れになっているという例が紹介されていましたが、これはアクセシビリティにも良くあてはまる話です。上流からアクセシビリティに配慮しておくことが重要です。

Webサイト制作の全工程でアクセシビリティを考えてほしい、ということで書いたのが「デザイニングWebアクセシビリティ」という本です。これをデザイナーやディレクターの方に読んでいただけると嬉しいです。

組織にWebアクセシビリティの考え方を浸透させる取り組みについては、サイボウズの小林さんのお話（あなたの言葉で伝えるWebアクセシビリティ）が参考になります。

アクセシビリティとコスト

質問・感想

  • どこまでインクルーシブを考慮するか、クライアントにどう説明するか（お金をもらうか）
  • アクセシビリティのことをしっかり考えてマークアップした方がよいのは理解できるが、会社には「予算そんなにないから、そこまでやらなくていいよ」と言われるのが想像できる。案件によるのかな。
  • アクセシビリティは売り上げに直結しないし、説明したり勉強会をやっても「今回はそういう人対象外だから」と言われがちです。SEOに絡めたほうが興味を持ってくれる気がしますよー（やること似てるし）
  • アクセシビリティに工数が出せない場合がとても多いと思うのですが、どの程度の優先順位になるのでしょう？対象ユーザーが多い場合のみかなあ…
  • アクセシビリティ対応って実際に現場ではどれくらい対応されているのでしょうか。その場合、別で金額を取っている？んですよね。

回答

今回のセッションでは、divで実装された「賛成」ボタンに対して、アクセシビリティを担保しようとしてあとからさまざまな機能を付け加えようとする例をご紹介しました。このように、望ましくない実装に対して後からアクセシビリティを担保しようとすると、大きなコストがかかることがあります。

それに対し、最初からbutton要素を使えば、それだけでもうキーボードアクセスやスクリーンリーダーへの対応ができているということになります。この場合、追加の作業は何も必要ありません。

このように、後から対応しようとすると大きなコストがかかりますので、最初から考えておくことが重要です。

ただし、動画やPDFなど、明らかにコストがかかるコンテンツも存在しますし、試験を実施すればその分はコストがかかります。このあたりの話は、書籍「デザイニングWebアクセシビリティ」の1章で触れていますので、興味ありましたら参照していただければと思います。

アクセシビリティをやらせてもらえないという悩み

質問・感想

  • アクセシビリティについてはまだまだ実装されているサイトは少ないと思います。今後本当に普及するのですか？
  • ワクワクするけれど、今の仕事では求められていない、やりたい

回答

アクセシビリティへの取り組みが必要な案件は近年増加している印象です。特に大規模案件や公共系の案件については、現在ではRFPにアクセシビリティ要件が含まれていないことのほうが珍しいように思います。

小規模案件では求められないことも多いと思いますが、そのような場合は要件定義でこちらから「今回はこのレベルまでの対応をします」と提案してしまうのもありです。逆に、要件定義で「アクセシビリティ対応は行わない」と明確に決めることもあります。決めておかないと後で問題が起きた際に費用内での追加対応を求められ、トラブルになることがあるからです。

このあたりの話も、書籍「デザイニングWebアクセシビリティ」の2章で触れていますので、参照していただければと思います。

おすすめのサイトは?

質問・感想

  • お二人がインクルーシブデザイン的に一番いいと思うサイトを教えていただきたいです
  • インクルーシブデザインが上手にできているサイトが日本のサイトにあるなら教えてほしいです

回答

サイトによっては「ウェブアクセシビリティ方針」を掲げて、自らの取り組みをアピールしていることがあります。方針を掲げているサイトはアクセシブルであることが多いので、それを見ると参考になるでしょう。(ただ、自治体系のサイトは方針を掲げていても正直それほど良くないことが多い印象です。民間企業のサイトを見たほうが良いと思います。)

また、私たちが所属しているウェブアクセシビリティ基盤委員会では、公的機関や一般企業における、ウェブアクセシビリティ方針策定と試験結果表示の実態調査を定期的に行っています。こちらも合わせてご覧ください。

その他、私の周りでアクセシビリティ文脈でよく話題に上がる企業や団体のウェブサイトをご紹介します。これらの企業や団体はアクセシビリティに取り組んでいくことを明言しており、そのサイトやプロダクトの状況にも注目していきたいと思っています。

現場が大変

質問・感想

  • 視覚的に見えない部分までがんばるのは正直きつい…
  • ここまで考慮しつつ実装のスピードを落とさない方法に苦心しそうと思いました

回答

現場の方にお勧めなのは、実際にスクリーンリーダーで一度アクセスしてみることです。そこまで時間はかかりませんし、これだけで多くの問題に気づくことができます。WindowsならNVDAが無料で利用できますし、iOSやOS XであればOS標準のVoiceOverが利用できますので、費用もかかりません。

最近はコンポーネント単位で実装することが多くなっていると思いますが、コンポーネントを実装するたびに、一度スクリーンリーダーでアクセスしてみると良いと思います。

スクリーンリーダーとその他の支援技術

質問・感想

  • スクリーンリーダーの利用率はどうやって調べられるのか？
  • スクリーンリーダー以外に考慮すべきツールはありますか？
  • 本セッションはスクリーンリーダーに特化していましたが、それ以外はどんなものがあるか知りたかったです

回答

さまざまな状況の方がWebを利用するために使うツールを「支援技術」と呼びます。支援技術の代表格はスクリーンリーダーですが、それだけではありません。画面を拡大するツール、点字ディスプレイ、マウス操作を支援するツールなど、さまざまなものがあります（ちなみに、茗荷谷にある東京都障害者IT地域支援センターというところでは、こういったさまざまな支援技術の常設展示を行っているそうです）。

スクリーンリーダーの利用率をサイト側で調査するのは難しいです。スクリーンリーダーはブラウザの表示結果を読み上げるため、サイト側のログには通常のブラウザのUser-Agentが記録され、スクリーンリーダーを使っているかどうかはわかりません。

SVG

質問・感想

  • 図版、表などもSVGで書いたほうがアクセシビリティ的にはよいのか？
  • SVGスプライトの運用方法は皆さんどうしていますでしょうか？
  • SVGスプライトにdisplay:noneを使うとグラデーションが反映されないので別の方法を使ったほうがよいと思いました

回答

SVGにすればアクセシブル、という単純な話でもありません。基本的には、テキストだけで必要な情報が伝わるようにする必要があります。そのテキストをSVGの中に入れるか、HTML側に入れるかという話になりますが、これは実際のブラウザやスクリーンリーダーの実装状況に照らして判断する必要があります。基本的に、img要素でSVG画像を参照しても、SVG内のテキストは読まれません。インラインのSVGであれば読まれることが多いですが、ブラウザやスクリーンリーダーによって処理が異なります。

表であれば、基本的にはHTMLのtable要素を使ったほうが良いでしょう。tableはアクセシブルでないという印象があるかもしれませんが、スクリーンリーダーは表を読むための専用のモードを実装していることが多く、行見出しや列見出しを読んでくれるなど、さまざまな支援があります。

SVGスプライトの運用は、アイコンの数が少ないときは良いのでしょうが、増えてくると管理がとても大変になります。illustratorのファイルを管理する必要もありますし、このあたりはみなさんそれぞれ工夫されているのではないかと思いますので、私も皆さんのノウハウをお聞きしたいところです。

参照される側のSVGスプライトにdisplay:noneを指定すると、Android4系の環境でグラデーションが反映されないという問題があるようです (他にも問題が起きる環境があるかもしれません)。ここで紹介したものは著者がおすすめする実装方法のひとつにすぎませんので、状況によっては別の方法を選択するほうが良いこともあります。

今回ご紹介した中には、VoiceOverでうまく読まれない事例もありましたね。さまざまな実装方法があり、どれかひとつが「正解」というわけではありませんので、状況によって適切なものを選ぶようにしていただくと良いと思います。

アイコンの実装

質問・感想

  • <i>タグでアイコンを置くのはどうでしょうか？

回答

i要素が支援技術で特別扱いされることはありません。つまり、divやspanと同じ扱いだと考えてください。i要素にテキストを入れればふつうに読まれますし、中身が空でもaria-labelをつけて読ませることもできます。CSSのcontentプロパティでテキストを追加した場合も読まれます。

アイコンをどのように実装するかがポイントで、さまざまな実装方法があり、それぞれにメリットとデメリットがあるのは今回お話しした通りです。i要素を使う場合、contentプロパティを使ってアイコンフォントを入れる実装になっていることが多いように思いますが、その場合もやはり、今回ご紹介した豆腐の問題が起きることがあります。

ボタンとフォーム

質問・感想

  • <button>はformタグが必要なので<a>とかそれこそ<div>でマークアップしていたのですが今後はbuttonを使うようにします
  • button type の初期値 submit だったはずなので、type=“button” 指定した方が良かった気がする

回答

実は、button要素はform要素のないところでも使えます。今回ご紹介した本の前著にあたる「コーディングWebアクセシビリティ」の2章で説明されていますので、興味がありましたらご覧いただければと思います。

buttonのtypeの初期値はsubmitです。フォーム送信をしない場合は、type=buttonを明示的に指定したほうが良いですね。

buttonとinput要素

質問・感想

  • <input type="button>と<button>でも使い分けたほうがいいものでしょうか？
  • buttonタグを積極的に使ってると、プログラマーから、アンカーか input type=“button” に変えてってよく言われてた

回答

button要素はHTML4で登場した比較的新しい要素です (といっても、20年の歴史がありますが……)。

昔はbutton要素がなく、<input type=button>を使っていましたが、ボタンの見た目が制御しにくいという問題がありました。ボタンの見た目を変えたい場合には<input type=image>を使って画像をボタンにするということも行われていました。button要素であれば、中にさまざまな要素を入れることもでき、スタイルの制御も自由が利きますので、最近はbutton要素を使うことが多いかと思います。

ただ、バックエンド側のフレームワークを使っている場合、リンクやフォームコントロールをフレームワークの機能で動的に生成しなければならない場合があります。この際、フレームワークの機能がbutton要素に対応していないと、aかinputにせざるをえないことがあります。これはシステム側の制約ですね。

このような場合には、<input type=button>や<input type=submit>を使っても問題ありません。これらもれっきとしたボタンですので、キーボードでフォーカスが当たる、スクリーンリーダーで「ボタン」と読まれる、といったbutton要素と同じ特徴を備えています。

buttonとa

質問・感想

  • ボタンはdivより<a>で組んでしまうことがよくあるのですが、<a>もあまり良くないのでしょうか？
  • ボタンにbuttonではなくaタグを使うことに対してはどうですか？
  • カーソルがポインターになるので<a>タグをボタンに使うことがありましたが、<button>を意識して使ってみようと思います
  • 見た目buttonでもリンクの場合はa要素でお願いしますね

回答

今回はご紹介できませんでしたが、実は本書にはこの議論もあります（9章が該当します）。a要素はキーボードフォーカスが当たりますが、あくまでリンクですので、スクリーンリーダーにはリンクとして扱われます。見た目がボタンでも、機能がリンク（つまり別ページに遷移するもの）であればa要素を使ったほうが良いでしょう。なお、ボタンにマウスカーソルを載せた際にポインター（指）にすべきかどうか、という議論も同じ章で語られていますので、ご参考ください。

その他マークアップの質問

質問・感想

  • 見出しの前に出てくる（日付などの）マークアップのしかたが知りたかったです

回答

今回はご紹介できませんでしたが、本書では解説されていますので、ぜひご覧ください。個人的には、可能であれば純粋に日付を見出しの後ろに置く (マークアップだけでなく、見た目上も後ろに置く) のが良いと思っています。

質問・感想

  • aria-hiddenじゃなくhiddenなんですね

回答

aria-hiddenはWAI-ARIAの属性、hiddenはHTML5の属性です。似ていますが意味合いは異なり、aria-hiddenが見た目に影響しないのに対し、hiddenは見た目上も非表示になります (display:noneを指定した時と同じような挙動です)。

質問・感想

  • マークアップに正解がないのか……

回答

今回はご紹介しませんでしたが、本書で著者のヘイドンさんは以下のようなことをおっしゃっています。

HTMLの構造は、自然言語の構造と同じように、ニュアンスで判断するべきです。役立つのか、じゃまなのか、少なすぎるのか、多すぎるのかといった観点です。

あることを表現する言葉が一つでないように、ある構造をマークアップする方法も一つではなく、どれが正しい、どれが間違っている、ということはないというのが著者の考えです。ただし、わかりにくい、伝わりにくいということはあります。マークアップの方法によって、伝わりやすくなったり、より多くの人に伝わるようになったりするわけです。この点も言葉と同じですね。

その他

質問・感想

  • 八卦の「天」は、「乾」がベターな表現です（副業占いの観点より）

回答

ありがとうございます。勉強になります。占いには詳しくなく、八卦と言われても良くわからないというのが正直なところでした。よろしければ詳しく解説していただけると嬉しいです!

このセッションは「CSS Niteベストセッション2017」にてベスト・セッション20に選ばれました。

2019年、CSS Niteでは49回の関連イベントを通して123セッションが行われました。その中からベスト・セッション＋αを選びました。

2010年から2019年のベスト・セッション