今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、どんな講演内容だったのか教えてください

「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」

「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」

「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」

「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」

「どのような実例でご説明されたのでしょうか？」

「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。

よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」

「先に知っておけば、そういう落とし穴には落ちないということですね」

「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」

「そうなってしまうのは、楽だからなんでしょうか」

「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」

「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」

「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。

アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」

「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」

「そのピンク本、ありがたいことに私の著書なんです(笑)」

「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」

「ディレクターさんにもすごくいい本ですよ」

「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」

「なるほど！読みます！」

「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」

「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」

「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」

「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」

「そうですね。それを解消するためにも、ぜひ！」

「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」

モダンなウェブとアクセシビリティは両立できますか？

「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」

「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」

「自然と優先度が下がっちゃう、というかんじですね」

「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」

「そういうことですか！」

「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」

「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」

「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」

ところで、普段はどんなお仕事しているんですか？

「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」

「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」

「企業の公式Webサイトですね」

「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」

「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」

「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」

「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」

「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」

「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」

「原さんは、どんなお仕事をされているのですか？」

「私は完全に開発者で、2004年からずっとアメーバブログを作っています」

「長いですね！」

「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」

「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」

「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」

「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」

「かなり」

「そうですね」

お二人の情報収集や勉強方法を聞かせてください

「お二人はどのように情報収集や勉強されているんですか？」

「今まさに勉強しているつもりです」

「そうそう。かなり勉強してます(笑)」

「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」

「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」

「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」

「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」

「もちろん、全部を読むわけではないですよ」

「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」

「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」

「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」

「なるほど！」

「簡単に希望したところに行けるかはわからないですけど」

「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」

「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」

「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」

「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」

「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」

アクセシブルなサイト設計・制作について教えてください

「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」

「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」

「はい。で、書きながら実行してるんですよ」

「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」

「完全に素のやつですよね」

「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」

「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」

「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。

それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」

「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」

「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」

「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」

サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？

「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」

「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」

「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」

「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」

「構造も何もあったもんじゃない(笑)」

「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」

「ある意味うらやましいですね(笑)」

「昔はありだったんでしょうか」

「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」

「あれはフロートがなかったからとかそういうことだったんでしょうか」

「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」

「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」

「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」

「モバイルが出てきてWebkitベースで確認できるようになって…」

「それ以前はもうぐっちゃぐちゃですよね」

「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」

「ピクセルパーフェクトってやつですね！」

「聞いたことあります」

「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」

「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」

「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」

「ぜひ、勉強します！」

「CSSが一番難しいですよね」

「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」

「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」

「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」

「CSSについても書いてありますか？」

「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」

「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」

「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」

「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」

UIを考える時に一番気をつけるべきことは何ですか？

「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」

「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」

「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」

「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」

「ありがとうございました！」

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、freeeの伊原力也さんと、ビジネス・アーキテクツの太田良典さんです。

お二人のセッション「多様なユーザーニーズに応えるフロントエンドデザインパターン〜書籍「インクルーシブ HTML + CSS & JavaScript」より」に関するスライド資料は、こちらで公開されています。

「インクルーシブ」に込められた意味とは？

白石: 今回は取材をお受けいただきありがとうございました！簡単に自己紹介をお願いします。

太田: ビジネス・アーキテクツに所属している太田です。大規模企業サイトの構築、ガイドライン策定などを行ってきました。

Webアクセシビリティ関連に昔から取り組んでいまして、「Webアクセシビリティ基盤委員会」の翻訳作業部会主査を担当しています。

▲株式会社ビジネス・アーキテクツ 太田良典さん　　※写真提供：html5j [HTML5 Conference 2017事務局

伊原: freee株式会社の伊原です。Webサイトやアプリケーションの情報設計を行っています。私もWebアクセシビリティ基盤委員会に所属しており、「理解と普及作業部会」にて活動しています。

他には、HCD-Netという人間中心設計を推進する団体でも活動しており、UXデザインの普及に務めています。

▲freee株式会社 伊原力也さん　※写真提供：html5j [HTML5 Conference 2017事務局

白石: 本日は、HTML5 Conferenceでお話された内容を主にお聞きしたいのですが、このセッションは、今度出版される書籍を元にしてらっしゃるんですよね。

伊原: はい、11月4日に出版される「インクルーシブ HTML + CSS & JavaScript」という書籍の内容をベースにしています。

私たちは2年ほど前にデザイニングWebアクセシビリティという書籍を、その半年ほど前にはコーディングWebアクセシビリティという書籍を上梓しました。

今回のセッションの元になった書籍は、いわばそうした流れを組んだ最新のものだといっていいと思います。特にコーディングWebアクセシビリティとは、著者も同じヘイドン・ピカリング氏ですし、続編といって差し支えないかと思います。

白石: では、今回もWebアクセシビリティに関する書籍なんですね。

太田: そうです。「コーディングWebアクセシビリティ」では特に、WAI-ARIAの使い方について詳しく論じられていました。WAI-ARIAの基本的な知識はあっても、「なぜそう書くのか」「いつどう使うのか」を知らない方に向けて、具体的な例を挙げつつ語った本です。

白石: では、今回の書籍は「インクルーシブ HTML + CSS & JavaScript」となっているわけですが、これはどういう内容の本なのでしょうか？

伊原: 原著のタイトルは「Inclusive Design Patterns」と言うのですが、サブタイトルは「Coding Accessibility Into Web Design」（Webデザインの中にアクセシビリティをコーディングする）となっていて、こちらの方がわかりやすい(笑)。

ぶっちゃけて言えば、アクセシビリティに配慮したコーディング例を具体的に挙げていっているという本です。

原著者がなんで「インクルーシブ」という単語を用いたかというと、「アクセシビリティ」というと、「アクセシビリティガイドラインを満たしていくこと」とか、「特定の障害を持つ人に向けた配慮」というニュアンスが強く根付いてしまっているからだと言っています。

また、「アクセシビリティ」という言葉自体には、デザインや設計という意味は含まれていない。アクセシビリティとは単に「アクセスできる可能性の度合い」のことですから。

一方でインクルーシブというのは「包括的」とか「全てを包む」といったニュアンスを含む英単語で、「できるだけ受け入れる」とか「できるだけ含める」という意味合いがあります。原著者が「インクルーシブ」という単語を用いたのは、「できるだけ多くの人に使ってもらえる」「できるだけ多くの状況で使える」ものをデザインしていこう、という意図なんです。

太田: ただ、日本語版では元のタイトルにある「デザインパターン」という言葉は使いませんでした。Web制作の世界では、「デザインパターン」と言う単語からはWebデザインを想起してしまいがちなので…。

アクセシビリティにおいては、そういう（UI）デザインのニュアンスだけが強いわけではありませんからね。

白石: 「デザインパターン」という単語は、エンジニアの方であれば逆に馴染みはあるかもしれませんね。

しかし、「コーディングWebアクセシビリティ」や「デザイニングWebアクセシビリティ」という書籍がありながら、今回新しい書籍を出版されたのはどういう背景があるのでしょうか？

太田: ここ10年くらいで、JavaScriptを用いた動的なUIがすごく普及しました。Ajaxがその立役者で、JavaScriptを利用して非同期にUIを書き換えるような作り方が一般的になってきました。

おかげで、WebサイトのUXは全般的に向上しましたが、一方で、アクセシビリティ的には新たな課題を抱えることにもなったわけです。元々、HTMLはアクセシブルに設計されているのに、JSがそれを損なってしまうケースが散見されるようになったのです。

例えばフォーム送信などは良い例です。昔ながらのフォームで、「送信」ボタンを押したら次のページ…という流れであれば、アクセシビリティに問題はあまりありません。ただこれを、JavaScriptを用いてAjaxでデータ送信するようにした途端、アクセシビリティが低下してしまうことが多い。

伊原: そもそも、JSで「アプリ」を作ろうとすると、アクセシビリティへの配慮がされにくくなりがちです。ほとんどdivやspanでマークアップして、見た目上動けばOK…という場合が少なくありません。

それを、セマンティックなHTML要素とWAI-ARIAを活用して、アクセシブルでUXにも優れたWebアプリを作ろうというのが、この「インクルーシブ HTML + CSS & JavaScript」で述べていることです。

実践！アクセシブルな商品リストを作ってみる

白石: では、アクセシブルなマークアップの具体的なパターンを幾つかお話いただきたいと思います。

ただ、セッションの内容全体についてはスライド資料をご覧になってもらえればいいと思うので、ここでは、私が個人的に疑問に思ったことなどを遠慮なくツッコませていただきつつ、ポイントとなる部分をおさらいしていっていただけると嬉しいです。

伊原: わかりました。では一つ目の例として、商品リストを見ていきます。

このサイトは画像アセットを購入できるサービスという想定ですが、UIデザインについては、Amazonの検索結果のようなものを想像して頂ければいいと思います。

リストの項目それぞれは商品名やレビュー結果、そして「すぐに購入」ボタンなどがあります。

これが複数縦に並んでいるリストをイメージしてください。

白石: こういう一覧の実装方法っていろいろですよね。個人的には、単にdivを並べるときもあれば、表っぽければtableを使うときもあります。

伊原: まず、リストそのものはリスト要素（ulやol）を使ってマークアップした方がいいかなと思います。

ここでリスト要素をお薦めするのは、要素の意味合いがわかりやすいのと、スクリーンリーダーがリストを読み上げるのに特別な機能を持つからですね。

太田: 例えばスクリーンリーダーは、リストの項目数を先に読み上げたり、前後のリスト項目にジャンプしたりできるんです。項目数って結構大事で、項目数が多い場合と少ない場合では、ユーザーの行動も変わってきますからね。

白石: なるほど。

伊原: また商品名ですが、見出し要素を使用するのが最適です。スクリーンリーダーは見出しに直接飛んだり、直前の見出しを読みあげたりすることもできる。 リストと見出しを組み合わせることで、一覧の見出しを飛ばし読みしていくようなことが可能になるんです。

まとめると、以下のようなマークアップがおすすめですね。

<li>
  <h3>
  ガソリンスタンドにたたずむ裸の男 <a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
</li>

白石: liの中に見出し要素を置くと、リスト項目が全て個別のセクションということになりますが、それは問題ないんでしょうか。HTML5からは、見出し要素は暗黙的にセクションを構成するようになりましたよね。

太田: はい、確かにセクショニングアルゴリズムの観点から、liの中にh3を入れることを望ましくないと考える人もいるかもしれません。ここは意見が分かれるところでしょうね。 ただ、アクセシビリティの観点からは支援技術で実際に使えるかどうかが重要で、その意味では十分に実用的だと言えると思います。

「今すぐ購入」ボタンはボタンにする？それともリンクにする？

伊原: 次は、「今すぐ購入」ボタンをどうマークアップするかを検討してみましょうか。

白石: うーん、これはbutton一択じゃないですか？

伊原: それもアリです。buttonを使うケースとしては、JavaScriptと組み合わせて、購入処理をその場で行えるようにするような場合ですね。

でもこの例のサイトは一般的なプリント写真購入サイトをイメージしているものなので、「今すぐ購入」ボタンを押したら、写真の購入確認画面に飛ぶことになります。

白石: そうなると、写真の購入確認画面へのリンクとして実装したほうが良さそうですね。

伊原: はい、そのほうがJavaScriptがなくても動きますし、要素の意味合いも明確になります。ここではa要素を使いましょう。

以下のようなマークアップがまずは望ましいですね。

<a href="/product/naked-man-in-garage" class="button">今すぐ購入</a>

白石: このマークアップだと、class="button"となっていますし、CSSで見た目をボタンっぽくするイメージですね。例えばWAI-ARIAを使って、このリンクのロールをボタンにするというのはいかがでしょうか？

<!-- role要素でbuttonを指定 -->
<a href="/product/naked-man-in-garage" role="button">今すぐ購入</a>

伊原: あ、それはやめてください。これでは、元のHTML要素が持つセマンティクスが変わってしまい、この要素はリンクではなくボタンであるという意味合いになってしまいます。

白石: なるほど、ここでは見た目だけボタンにしておいて、セマンティクスは変えないのが望ましいと。

太田: そうなんです。WAI-ARIAって覚えると濫用されがちな技術でもありますが、基本的には「WAI-ARIAは使わない」のが正しい。

W3Cの「Using WAI-ARIA」という文書の先頭に書いてあるのは、「（HTMLでまかなえる場合は）WAI-ARIAは使うな」なんですよ(笑)。

例えばボタンや見出しがあったとしたら、素直に<button>や<h1>を使えば良い。WAI-ARIAを使う必要は必ずしもないんです。基本的にはHTML5の語彙を用いて、足りないところをWAI-ARIAで補う、という形が望ましい。

リンクテキストにも配慮しよう！

伊原: あともう一つ考えてみたいのは、リンクテキストです。このままだと全てのリンクが「今すぐ購入」になってしまいますが、それってアクセシビリティに優れていると言えるでしょうか？

白石: うーん…見出しに商品名はあるので、全くアクセシブルじゃないとは思いませんが。リンクテキストも読み上げられるんですよね？全部が「今すぐ購入」じゃ不親切かも？

伊原: そうです。「何を購入できるか」が、リンクテキストから分かると、よりアクセシブルですよね。

なので、非表示のテキストでリンクテキストをより詳細化すれば、UIデザインも損なわれません。

<a href="/product/naked-man-in-garage" class="call-to-action">
  <span class="visually-hidden">ガソリンスタンドにたたずむ裸の男を</span>今すぐ購入
</a>

白石: なるほど、不可視のテキストも利用してより説明的にするとは…！アクセシビリティへの配慮を真面目に考えてないと、まず出てこない発想ですね。

伊原:ちなみに他にもやり方はいくつかありますが、この本ではSEOにおける内部対策的な意味合いも込めて、このやり方が推奨されています。

検索結果ページ（SERP）にも配慮する

伊原: 最後に、検索エンジンの結果ページで商品（Search Engine Result Pages）がどう見えるか、についても配慮した方がいいでしょう。

白石: 検索結果ページですか？なんでですか？

伊原: 支援技術ユーザーの中には、目的のページに辿り着くために、検索エンジンのインターフェースを利用する人も多くいるんです。Google検索って、site:を前につけるとサイト内検索を行えるじゃないですか。

白石: ああなるほど。言われてみれば、ぼくもAmazonの中検索するのに、Google検索をよく使います(笑)。

伊原: 例えばマイクロデータとschema.orgを使えば、検索結果の表示をより充実させることが可能です。以下に、商品のレビュー結果を表すマークアップの例を示します。

<span itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
<span itemprop="ratingValue">4</span>つ星、
レビュー数<span itemprop="reviewCount">13</span>
</span>

白石: そうか、今までぼく、「マイクロデータ使っとけば検索結果ページで目立てるかな」くらいしか考えたことなかったんですが、アクセシビリティの点から考えても重要なんですね。あんまりちゃんと意識したことなかったです。

見た目ではなく機能でマークアップせよ！

伊原: では次の例に移らせてください。表示結果を絞り込んだり並び順を変えたりするUIを実装してみたいと思います。

白石: うーん、こういうの実装するんだったら、ぼくだったらどうするかなあ。ナビゲーションメニューみたいなものと捉えて、リストとa要素とかでやるかもしれません。

伊原: それも悪くないのですが、このメニューって、どれかが選択中の場合は他のメニューを選択できませんよね。それってどうします？

白石: …JavaScriptのお世話にならざるを得ないかもしれません。

伊原: そう、でも、標準のHTMLには、そういう「排他的」な選択を行うためのフォーム要素があります。

白石: …ラジオボタン、ですか？

伊原: そのとおりです！

このデザインだけからだと、見た目はラジオボタンとは似ても似つきませんが、ここではラジオボタンを使うことにします。マークアップの段階では、見た目ではなく機能に沿ってマークアップするのが重要ですから。

ラジオボタンのスタイリング…やりにくい！どうする？

白石: でも、ラジオボタンは「◎」みたいな余計なUIがくっついてきちゃいますよね？しかもあれがブラウザごとに異なる上、どのブラウザのデザインもあんまりカッコよくない(笑)。

伊原: そうなんです。ラジオボタンってスタイリングしにくいので評判が良くないですよね(笑)。だから、結局他の要素を使っちゃう…なんてことも起きちゃうんですが、そこは工夫次第です。

ここではlabel要素をうまく使って、目標とするデザインを実現しましょう。label要素は、それ自身をクリックすることで、対象となるラジオボタンやチェックボックスの状態を変更できますよね。

白石: ああ、なるほど！labelはクリッカブルな状態で表示しておいて、ラジオボタン本体は隠しちゃえばいいんだ。

伊原: そうです。labelさえあればラジオボタンのクリックは可能ですので、実際のラジオボタンは隠しちゃってもいいんですよね。ラジオボタンのフォーカス状態やチェック状態はCSSの擬似クラスで指定できますので、CSSだけで表示の切り替えが可能です。

例えばこんな感じになります。

<input type="radio" name="sort-method" id="most-recent" checked />
<label for="most-recent">新着順</label>

<input type="radio" name="sort-method" id="most-popular" checked />
<label for="most-popular">人気順</label>
...(略)...

[type="radio"] + label {
  cursor: pointer;
  /* その他、基本のスタイル */
}
[type="radio"]:focus + label {
  /* フォーカス時のスタイル */
}
[type="radio"]:checked + label {
  /* 選択時のスタイル */
}
/* ラジオボタンを見えなくする */
.sorter [type="radio"] {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding:0 !important;
  border:0 !important;
  overflow: hidden !important;
  clip: rect(1px, 1px, 1px, 1px);
}

白石: なるほど、これならHTMLのセマンティクスもわかりやすいし、JavaScriptもいらない。素晴らしい。

伊原: ちなみに、このCSSの!important連打は「とにかく扱いづらいラジオボタンを消し去ってやりたい」という原著者のジョークなので、真似しないでください(笑)。

無限スクロールはやっぱり×？「もっと読む」はどう実装するか

伊原: 最後に、検索結果が複数ページに渡る場合、どういう風なUXが望ましいかを考えてみたいと思います。昔よく使われていたのはページングですが、今は無限スクロールを採用するサイトも多いですね。

白石: はい、ぼくも自社で運営しているTechFeedというアプリで無限スクロールを採用しています。

伊原: ただ、アクセシビリティ的には無限スクロールは使わないほうが無難です。

白石: えっ！いろんなサイトが採用しているし、使いやすいとも思うんですが…

伊原: 理由はいくつかあります。

まず、スクロールという操作が読み込みを誘発することが、ユーザーにとって望ましいことなのかどうか。ユーザーは次のページ読み込みを望んでいないかもしれないですよね。

あと、スクロールバーを使っているユーザーは、新たなページが読み込まれた瞬間スクロールバーが勝手に上下するので、混乱します。

最後に、ページのフッターにたどり着けないことがあります。フッターに要素を置いているにもかかわらず、無限スクロールがあるものだから、フッターに触りたくとも触れない…という事態が起こりうるのです。

白石: ふむ、理由はわかります。では、代わりにどうデザインすべきだと思いますか？

伊原: ページ読み込みをユーザーが制御できればいいので、「もっと読む」ボタンを明示的に設置するというのは一つの解決策ですね。

白石: でも、いちいちそのボタンを押さなくちゃならないというのも結構面倒な気がします…。あと、サービス事業者側としては、無限スクロールでどんどん下に読んでいってもらうことで、ユーザーの滞留時間を伸ばしたいという気持ちもあると思うんですよね。

伊原: この本では、ユーザーが「もっと読む」ボタンをよくクリックするようなら、その時に改めて「続きを自動的に読み込むか」を尋ねるようにするというやり方が紹介されています。その質問に「YES」と答えるのなら、そのユーザーにとっては、先ほど挙げられていた無限スクロールのデメリットが気にならないという証拠でもあると。

白石: なるほど。確かにそのほうがユーザー本位でもありますね。

太田: あとこういう動的にリストを追加する場合、アクセシビリティの観点から一点注意点があります。

読み込みが完了したら、新しく読み込んだデータの先頭にフォーカスを移すことです。そうしないと、スクリーンリーダーのユーザーが、次にどこに行けばいいかわからなくなってしまいますから。

そのために、新たに読み込んだデータの先頭にtabindex="-1"を指定しつつ、JavaScriptでフォーカスを与えます。

...
<li>
  <!-- tabindexを指定して、タイトルをフォーカス可能にする -->
  <h3 tabindex="-1">
    ガソリンスタンドにたたずむ裸の男<a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
  ...
</li>
<li><!-- 新たに表示された商品の2番目 --></li>
...

白石: おお、こういう配慮は全く考えていませんでした。勉強になります。ちなみに、tabindexにマイナス値を指定することなんてできるんですね…知りませんでした。

太田: tabindexにマイナスを指定すると、ユーザーはそこにフォーカスを当てられないのですが、スクリプトでなら当てられるようになります。

「アクセシビリティは0点か100点っていう話じゃない」

白石: 本日は、いろんな例についてマークアップを考えられて面白かったです。

ただ最後に質問があります。

最近のWebアプリはどんどん動的になっていて、「UIのほとんどをJavaScriptで構築する」という場合も少なくありません。Single Page Applicationなんかはその最たるものだと思います。

こうしたサイトでも、アクセシビリティを担保することは可能なんでしょうか？相当の工数をかけないと難しいんじゃないかという気がしているのですが。

伊原: 確かに、SPAのアクセシビリティは面白いテーマです。ただ、SPAだからアクセシビリティの担保が難しいということはないと思います。

というのも、Google DocsやGoogle SlidesはWAI-ARIAにかなり対応していて、コンテンツの読み上げに対応しているんですよ。

白石: え、そうなんですか！それらのアプリ、SPAの代表格みたいなもんだと思ってました…。「SPAはスクリーンリーダーになじまないんじゃないか」なんて思ってましたが、それは単なる思い込みですね。

伊原: どんなサイトでもまずは一回、スクリーンリーダーで読み上げを行ってみることをお勧めします。SPAであっても、意外なほどスクリーンリーダーが綺麗に読み上げてくれることもありますので。

太田: 私はいつも言っているのですが、アクセシビリティって0点か100点かだけではないんです。全くアクセスできないサイトもなければ、全世界のすべての人がパーフェクトにアクセスできるサイトもありません。全てのサイトがその中間のどこかに位置していて、少しでもよくしていこうという考え方が大事だと思います。

伊原: 「アクセシブルかどうか」はちょっとした改善で大きく変わったりもするものです。

例えば先日、とあるサイトをスクリーンリーダーで読み上げてみたのですが、ほとんど問題なく使える。ただ一点、そのページで一番重要なラベルだけ読み上げてもらえないんです。こういう点を改善するだけで、アクセシビリティはぐっと向上する。

なので、まずはアクセシビリティ上の問題を特定し、問題の重要度を判断して、重要なところから対応していく…という現実的なアプローチが、アクセシビリティを向上させていく上では大事だと思っています。

白石: 本日は、いろんなお話を聞かせていただき、ありがとうございました。

3月14日に特定非営利活動法人Web Directors Forum（以下、WDF）とHTML5 Experts.jpの共催企画として、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」が金沢にて開催されました。この記事では、その勉強会のセッションの模様をレポートします。

アクセシビリティについて最近考えていることをざっくばらんに話すよー村岡 正和

イベント2つ目のセッションはエキスパートの村岡 正和さんです。村岡さんといえばIoTという方も多いと思います。HTML5 Experts.jpでも記事を執筆されています。

今回のセッションでは、タイトルの通りアクセシビリティについて考えていることをざっくばらんに語っていただきました。そのセッションの模様を紹介します！

まずは自己紹介

村岡さんのセッションはまずスライド10ページ分の自己紹介からスタート（笑）。本業としては神戸を拠点に、Webアプリケーション開発、IT業務システムの設計/開発、Webサービス導入/事業戦略コンサルティングなどをされているそうです。

それ以外にも…

薄い本の執筆

FirefoxOSの薄い本を執筆しているそうです。興味あれば。（あ、表紙に騙されちゃダメですよ、中身は文字ばっかりだとか）

本の監修

書籍「Webアクセシビリティ事例集」

html5jマークアップ部＆Markup Cafeを主催

また、村岡さんは、コミュニティ活動として、html5jマークアップ部を主催しており、マークアップ部の活動の一環として、Markup Cafeという参加型イベントを全国各地開催しています。Markup Cafeは予め与えられたお題に対して、どのようなマークアップが考えられるかをチームで考えるというものです。例えば、ページネーションをどうマークアップするか…（考え出したら1時間じゃ足りないらしいですよ）

最初のセッションで登壇された木達さんもMarkup Cafeには注目しており、インスパイヤされて社内マークアップ部を立ちあげられたとか。Markup Cafeに興味関心がある方は、イベントレポートが掲載されているので、ぜひご覧ください。

ということで、本題に入ります。

OnePageスクロールサイトのalt属性で喜ばれた件

はじめは、Webアクセシビリティへ対応でお客様に喜ばれた事例の紹介です。お客様は知財務株式会社様（情報コンサルティング業）です。

知財務株式会社様Webサイト（http://www.chizaim.com/）

このサイトにはOne Page ScrollというjQuery Pluginが利用されています。ワンページスクロールのサイトは、キャッチコピーや画像だけを印象に残るように配置したデザインが多いのですが、今回のサイトの場合、それだけでは、なんとなくテキストが不足していて視覚以外の閲覧で情報が不足するのではないかと感じていました。

そこで、情報不足を画像のalt属性に説明文を付け足すことで補ってみました。

この件について、後日お客様から「情報を扱う会社だからアクセシビリティに配慮しているというのは、お客様に対して良い話題になる」とお礼の言葉をいただきました。WCAG2.0では、alt属性の指定はimg 要素の alt 属性を用いるがあります。この実装例は印象、雰囲気のみを伝えるような画像には必要ないと解釈することもできますが、今回のように画像の説明があったほうが、好感度があがるケースもあります。アクセシビリティ対応を行うことで、ビジネス的メリットが発生する可能性を感じた良い事例です。

モバイルフレンドリーなサイトである必要性

次はGoogleの検索アルゴリズム変更についてです。アクセシビリティという観点で最近、こんなニュースが話題になっています。

http://internet.watch.impress.co.jp/docs/news/20150227_690424.html

このアルゴリズム変更により、ウェブサイトのモバイル対応度が、検索結果の表示順決定により大きく影響するようになります。マルチデバイスへの対応において、レスポンシブデザインフレームワークなどを利用したマークアップは自然とアクセシブルなマークアップになるケースがあります。このような点を含めて、Webアクセシビリティとモバイル対応の関係を注目しておくべきではないでしょうか。

Webフォントとアクセシビリティ

次は、Webフォントについてです。最近のWebサイトでは文字の表現の幅を広げる手段として、画像文字の代わりにWebフォントがよく利用されるようになりました。先ほどのalt属性の設定でもし悩むようなことがあれば、画像は極力排除してWebフォントを利用するのもオススメです。例えば、この画像にどうやってalt属性を当てますか？

1枚の画像としてではなく、Webフォントを活用して表現することでalt属性の心配はなくなりそうですね。とても、納得のいく事例でした。例えば、写真上の値段や写真下の説明書きをテキストにし、Webフォントで装飾すれば画像文字に比べてアクセシブルになります。さらに写真の料理の説明をalt属性で記述すれば、よりページの情報量が多くなりますね。

また、Webフォントはベクター画像なので、以下のように拡大しても綺麗に見えます。

日本語のWebフォントを利用する際は、料金的なコストが発生するなどトレードオフが必要になることも有りますが、使えるならば使ったほうが、Webサイトがよりアクセシブルになります。

Webアクセシビリティは習うより慣れろ！

次は、Webアクセシビリティに関するスキルをどう身に付けるかという話です。「Webアクセシビリティ技術は全てのWebクリエイターにとって必須の技術」と言っても過言ではありません。では、どうやって勉強したらいいのでしょうか？

必要な資料は全てWebで公開されている

• WCAG2.0実装方法集（http://waic.jp/docs/WCAG-TECHS/Overview.html）
• JIS X 8341-3:2010 解説(http://waic.jp/docs/jis2010/understanding.html)

無料ツールも結構ある

• Accessibility Developer Tools – Chrome Extension
• Webアクセシビリティ簡易チェックシートと検証ツール（村岡さんお手製）

事例集もある（再掲）

• Webアクセシビリティ事例集【2012年度版】

テストも出来る

• JIS X 8341-3: 2010 テストファイル 等級A

このように、その気になればWebで全部学習できるようになっています。しかし、ただ学習するだけじゃ意味がありません。中途半端な知識でも構いません、アクセシブルな実装は習うより慣れろ、が鉄則です。実際に作らないとアクセシブルなページを制作する技術が身に付きません。

また、実際の制作物のWebアクセシビリティ対応方法が、テストケースと完全一致するケースは稀です。過去の事例が使えない場合、達成基準やアクセシビリティの基本理論をもとに、自分で実装の妥当性をしっかりと検討し、根拠を持つ必要があります。

知識だけだとWebアクセシビリティの本質を曲解しやすく、ユーザの利便性を考慮していない頭でっかちな実装になり、結果的にお客様に迷惑をかけることになるので、気をつけて下さい。

ウェアラブルデバイスとアクセシビリティ

次は話題を変えて、ウェアラブルデバイスについてです。今年になって様々なウェアラブルデバイスが登場してきています。これらウェアラブルデバイスがWebに与えるインパクトはかなり大きいと考えています。

Myoというデバイスはご存じですか？このデバイスは、腕の動きを感知し、動きに合わせて様々なモノを操作できるジェスチャーコントローラーです。

Myo – https://www.thalmic.com/en/myo/

これらのデバイスは、ウェアラブルデバイスが一般常識化した頃には、Webページに対して入出力を行う新しいインターフェースとなっている可能性が考えられます。これからは、Webアクセシビリティは、マウス・キーボードに加えてこのような新しい入力デバイスへの配慮が必要になるかもしれません。

また、逆に、ウェアラブルデバイス上でWebサイトが動作するようになった場合は、どのようなWebアクセシビリティが適しているのか、ということも考えていかなければなりません。例えば、スマートグラス上で表示するのに適したWebデザインってどんなデザイン？というように。

ウェアラブルデバイスを軸にしたWebアクセシビリティの議論はこれからますます活発になります。私も参加している日本ウェアラブルデバイスユーザー会の中で、そのうちアクセシビリティWGを作りたいと考えています。

IoT/WoTとアクセシビリティ

最後は、IoT/WoTとアクセシビリティについてです。昨今様々なデバイスが登場しています。そして、それらはWeb技術を利用してWebを介してつながることができます。個人的には、IoTという言葉は抽象的すぎるため、WoTに注目しています。

デバイスがWebでつながる？と疑問に思われた方は、まずは、村岡さんの記事をご覧ください。

イベント当日は、WeIOというデバイスを例に取り上げられました。

WEIO – http://event.shoeisha.jp/eva/20150511

このデバイスは、例えば、以下のようにHTMLとJavaScriptでプログラムが書けてしまいます。

<!DOCTYPE html>
<html lang="en">

<head >
    <!-- import weioLibs and link css style -->
    <script data-main="www/libs/weioLibs" src="www/libs/require.js"></script>
    <link rel="stylesheet" type="text/css" href="myStyle.css">

    <script>

        // This fucntions is called when DOM is loaded and web socket opened
        function onWeioReady() {
            hertzs();
        }

        // init variable hertz
        var hertz = 0;

        function hertzs() {
            // update displayed phrase with variable hertz
            $("#phrase").html("FREQUENCY FOR TONE FUNCTION = "+ hertz);
            // get tone with "hertz" frequency on pin 23
            tone(23, hertz);
            // increment hertz variable
            hertz = hertz+50;
            // Reset hertz variable at 18000
            if(hertz > 18000){
                hertz=0;
            }
        }

    </script>

</head>

<body>
    <p id="phrase" onclick="hertzs()"></p>
</body>

</html>

これからはHTML5でハードウェア開発が可能になるため、つまり、開発されたデバイスもWebアクセシビリティに配慮する必要が出てくる可能性があります。この分野はまだ出てきたばかりなので、現行のWAI-ARIAで対応できないことが出てくるのか？そもそもWebページとの相互運用性を確保する必要があるのか？など、まだまだわからないことが多いのは事実です。

次回予告

次回のレポートでは、元山和之さんのセッション「ユーザーの期待に応えるクックパッドのUI/UX」をレポートします。お楽しみに！

3月14日に特定非営利活動法人Web Directors Forum（以下、WDF）とHTML5 Experts.jpの共催企画として、WDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」が金沢にて開催されました。この記事では、その勉強会のセッションの模様をレポートします。

これからのWebデザインに求められるアクセシビリティとの向き合い方ー木達一仁

最初は、株式会社ミツエーリンクスのCTOでありエキスパートの一人でもある、木達一仁さんによるセッションです。木達さんはWebアクセシビリティに関して、様々な取り組みをされている方です。別の企画でもロング・インタビューしているので、合わせてご覧ください！

今回のセッションでは、Webアクセシビリティの初心者向けに、そもそも「Webアクセシビリティって何？」というところから、Web制作者は今後どのようにWebアクセシビリティに向き合えばよいかを、丁寧に解説してもらいました。そのセッションの模様を書き起こしていきます。

Webアクセシビリティとは何か？

「アクセシビリティについて語るには、まずその定義、前提をシェアすべき」という語りかけから、セッションは始まりました。そもそもWebアクセシビリティとは何なのでしょうか？その答えをアクセシビリティの定義、ユーザビリティとの違いという2つの観点から解説されました。

アクセシビリティの定義

アクセシビリティという言葉は「アクセス」と「アビリティ」から成ると捉えることができ、対象にどれだけアクセスできるかの度合いを示します。Webアクセシビリティとは、さまざまにあるアクセシビリティの一分野という位置付けになります。

アクセシビリティとユーザビリティの違い

アクセシビリティに似た言葉にユーザビリティがありますが、あえて両者の違いを強調して表現するならば、次のようになります。

• アクセシビリティ　→　すべての人々にとっての利用できるかどうかの度合い
• ユーザビリティ　→　特定の人々にとっての利用しやすさの度合い

しかし、ユーザビリティが低すぎる課題は、アクセシビリティ上の課題として扱うこともでき、両者を明確に分けることは困難です。アクセシビリティはユーザビリティにとっての土台、前提のようなものと捉えることができ、ユーザブルである前にまずアクセシブルであるべき、と言えます。

これまでのWebアクセシビリティの捉えられ方

障害者・高齢者のためだけの対応？

WebアクセシビリティのJIS規格の名称に「高齢者・障害者等配慮設計指針」とあることからも、Webアクセシビリティと言えば、障害者や高齢者のための対として捉えられがちでした。確かにそのような側面はありますが、障害者・高齢者のためだけに必要なわけではありません。例えば、後述するWebアクセシビリティのガイドラインのWCAG2.0（日本語訳）に、ブロック・スキップという項目があります。これは、Webページ中のメインコンテンツより前にあるブロックをスキップできるメカニズムを指し、視覚障害者が音声でコンテンツを利用する場合に有用ですが、視覚障害者でなくとも、キーボードでコンテンツをユーザーにも有用です。

オプション扱い？

Webデザインという業務の見積もりにおいて、アクセシビリティ対応がオプション扱いにされてしまう場合がありました。オプション扱いでは、価格交渉（値引き）の材料にされてしまう可能性があり、結果的にアクセシビリティ対応の優先度が下がってしまいかねません。もしも、先に述べた「Webアクセシビリティは障害者・高齢者のため」という意識がWebデザインの発注者側にあったなら、なおさらです。アクセシビリティの確保は、Webのデザインプロセスと本質的に不可分であって、オプション扱いにすべきではありません。

デザイン上の制約？

Webアクセシビリティを確保することが、デザイン上の制約でしかないなどと考えている制作者がいます。しかし、あらゆるデザイン行為に制約なり条件は付きものであって、アクセシビリティを確保することで殊更にデザイン上の自由が奪われると考えるのは、バランスを欠いていると思います。そもそも、Webの閲覧環境はハードウェア、ソフトウェアともに多様化しており、あらゆるスクリーンにおいて制作者の意図した通りコンテンツを表示させることなど不可能です。それでもなお、コンテンツにある情報の伝達や機能の利用を担保できるのがWebの利点であり、アクセシビリティを確保すべき理由でもあります。Webデザインにおいては、その種の変幻自在さは制約であると同時に、大きなメリットでもあるでしょう。

アクセシビリティ＝品質

私は、アクセシビリティをWebに欠かせぬ「品質」であると考えています。そして品質であれば、それを測る基準なり一定の標準が必要になります。その一つが、Webアクセシビリティの国際規格としてW3Cより2008年12月に勧告されたWCAG 2.0（2012年にはISO/IEC 400500として標準化）であり、そのなかで4つの原則と12のガイドラインが定められ、都合61の達成基準や3つの達成等級（A/AA/AAA）が定められています。国内の規格としては、JIS X 8341-3という規格が2004年に公示されていましたが、WCAG 2.0と整合する形で2010年に改定されました（2010年版を「JIS X 8341-3:2010」と書き表します）。ちなみに、今年2015年にも改定の予定があり、現在それに向けた作業が進行中です。

Webアクセシビリティ確保の現状

次に、Webアクセシビリティの確保が昨今、どれだけ取り組まれているのか見てみましょう。総務省は「みんなの公共サイト運用モデル改訂版（2010年度）」という、公的機関のWebサイト向けにアクセシビリティ確保の具体的な手順をまとめたドキュメントを公開しています。その中には、以下のような目標や目標を達成する期限の目安が示されています。

• 既存サイト
  • 2014年度末までに JISX8341-3:2010の等級AAに準拠すること（試験結果公開）
• 新規構築サイト
  • 構築前に「ウェブアクセシビリティ方針」策定
  • 構築時にJISX8341-3:2010の等級AA（試験結果公開）

取り組みはまだ道半ば

Webアクセシビリティの確保・向上を図るべく発足したウェブアクセシビリティ基盤委員会（WAIC）では、ウェブアクセシビリティ方針の策定と試験結果の表示について、定期的に実態調査を行なっています。

公的機関におけるウェブアクセシビリティ方針の策定と試験結果表示の実態調査結果（2014年11月）

上記は主要な公的機関に対象を限定した調査の結果ですが、取り組みはまだ道半ばであることが窺えます。WAICは、一般企業に対しても同様に調査を行っており、結果は以下の通りです。

一般企業におけるウェブアクセシビリティ方針の策定と試験結果表示の実態調査結果（2014年8月）

一般企業においても、その取り組みはまだ本格化していないようです。今なおWebアクセシビリティ確保の取り組みが盛んではないように見受けられる背景として、以下のような要因が考えられます。

• Webデザインの発注側の意識がアクセシビリティに向いていない
  • 意思決定層に対する啓発や教育が足りない
  • WebアクセシビリティのROI（投資対効果）が計測しにくい
• Webアクセシビリティの確保が盛んな海外と異なり、日本では法制化されていない
• 受注側であるWeb制作者に向けた、アクセシビリティ関連の情報共有の場や学習機会が少ない

こと法制化に関連して、最近注目すべき動きがあります。アメリカの法律であるAir Carrer Access Act（ACAA）が、日本の航空会社にも影響を及ぼし始めているのです。そのような状況は今のところ航空業界だけのようですが、今後のグローバルビジネスの進展に伴い、他の業界においても同様の状況が生まれないとも限りません。そうなればますます、国際競争力という文脈においてWebサイトのアクセシビリティを重視せざるを得なくなるでしょう。

また日本でも、国連の障害者権利条約に批准したことに端を発し、障害を理由とする差別の解消の推進に関する法律（いわゆる「障害者差別解消法」）が2013年に制定されました。この法律には2016年4月に施行の予定で、2015年2月にはその基本方針が閣議決定されたばかり。基本方針には「情報アクセシビリティ向上」や「障害者による円滑な情報の取得・利用・発信のための情報アクセシビリティの向上」といったくだりがあることから、Webが障害者差別解消法の対象範囲に含まれることは確実と思われます。

今後ますます重要になるWebアクセシビリティの確保

法制化の動向はそれはそれとして、Webにアクセスする際に使われるデバイスの変化や、Web技術の高度化・複雑化という変化からも、Webアクセシビリティの確保は今後ますます重要になってきます。

マルチデバイス時代と機械可読性

今やPCのみならずスマートフォン、タブレット、さらにはウェアラブルデバイスに至るまで、さまざまなデバイスから自在にWebを利用する時代。そこで、Webコンテンツの機械可読性（ソフトウェアのような機械がコンテンツを読み取れるかどうか）という価値に注目が集まってきます。つまり、Web上のコンテンツをソフトウェアが読み取った結果を、ユーザに対しどれだけ便利に提供できるかが重要になってきているのです。機械可読性を確保することは、Webアクセシビリティを確保することとほぼ同義です。

Web技術の高度化・複雑化

Webの技術は日進月歩の勢いで進化し、改善され続けています。しかし、最新の技術が常にアクセシビリティに配慮されているとは限らない点に注意が必要です。アクセシブルにするための技術なり対応が「後追い」で生まれてくることは珍しくありませんが、Web技術がますます高度化・複雑化していくなか、それが社会に深刻な情報格差をもたらすことのないよう、アクセシビリティへの対応状況に常に注視する必要があります。

結局のところ、誰もがWebアクセシビリティを必要としている

誰もが、いつでも、どこでも、どんなデバイスでも、自分好みの設定でWebを使いたいと思っているはずです。加えて、誰もが一時的な障害者になり得ますし、また誰もが歳を取っていずれは高齢者の立場になるでしょう。Webが、障害者や高齢者を含む誰もが自由自在に使えるWebであるために必要不可欠な要素、それがWebアクセシビリティです。この先10年、20年経っても便利で「使える」Webを創るには、積極的にアクセシビリティを確保し続ける必要があります。

これからのWebアクセシビリティとの向き合い方

Webアクセシビリティを確保したWebデザインを実践していくための、いくつかの提案があります。

1. 想像力を働かせる

ターゲットユーザーばかりが、ターゲットブラウザーのみで、常に意図したコンテキストでコンテンツにアクセスするとは限りません。想像力を働かせ、さまざまなユーザーが、さまざまなデバイスで、さまざまなコンテキストからアクセスしてくることを意識してデザインしましょう。

2. WCAG2.0を読み理解する

とかく難解で分かりにくいと言われるWCAG 2.0ですが、文字量は恐れるほどではありません。日本語訳が公開されていますから、まずは読んでみましょう。あえて特定の技術に依存しないような書きっぷりゆえ抽象度がやや高いので、最初は書かれていることのすべてが理解できなくても当然だと思いますし、隅から隅まで全てを読み通す必要はありません。原則は4つ、ガイドラインは12しかありませんから、まずはそれらを知りましょう。

すべての原則とガイドラインをランダムでつぶやくTwitterアカウントがあります。たまにつぶやきを眺めることで、意識付けになるかもしれません。よろしければフォローしてみてください。

• Webアクセシビリティ・ファーストのTwitterアカウント、@a11y1st

3. 実現できることから着手する

Webアクセシビリティの確保に0点も100点もありません。自身にとって取り組みやすい、実現が比較的容易なことから、取り組んでみてください。欲張ってあれもこれもと手を広げなくても、Web標準の仕様に準拠するだけで、かなりアクセシブルにコンテンツを実装することができます。

たとえば例3に挙げたマークアップの妥当性は、W3Cの提供するバリデーターサービスで簡単に確認することができます。是非確認してみてください。

• The W3C Markup Validation Service

4. 継続できる取り組みを増やす

着手したWebアクセシビリティ確保の取り組みを、ワークフローの一部に組み込んでルーチン化しましょう。ルーチン化することが効率化につながり、対応のための時間的コストを下げることにもつながります。またWebアクセシビリティの取り組みに、周りの人たちを積極的に巻き込みましょう。さまざまなな立場の方からの協力が、より高いアクセシビリティ品質の達成に不可欠です。そして最終的には、WCAG 2.0のAレベル相当の対応を「当たり前」の品質にしましょう。最初は高すぎるハードルに映るかもしれませんが、継続的な取り組みを徐々に増やしていくうち、Aレベルであればそれほど難しくもないということに気づくはずです。

5. 足し算だけでなく引き算の視点ももつ

公的機関のWebサイトでは特に、文字サイズや色合いの変更ボタン、文字読み上げボタンなどが設置されているのを見かけます。しかし、そうした機能を提供しなければコンテンツがアクセシブルにならない、と考えるのは間違いです。もちろん提供してもよいのですが、提供するからには、それが本当にユーザーの利便を向上させる実装になっているか、しっかり検証すべきです。そもそもブラウザーのネイティブな機能や支援技術、ユーザーのリテラシーは進化し続けています。コンテンツを提供する側で用意すべき機能かどうかは、足し算の視点だけではなく、引き算の視点ももってWebアクセシビリティを捉えましょう。

6. 「守り」から「攻め」のWebアクセシビリティへ

Webはこれまでも、これからも進化し続けます。古くなった書籍や、Web上の更新されていない古い情報に惑わされたり、あるいは思考停止をしないでください。Webアクセシビリティ確保の大原則は変わらずとも、個々のテクニックのアップデートは随時必要となります。そうして積極的にWebアクセシビリティを確保することで、将来的に発生し得るコストやリスクを回避しやすくなります。例えば、iPhoneでFlash非対応が話題になった時、Webアクセシビリティの観点から代替コンテンツを提供していた制作者は慌てませんでした。似たような話で、レスポンシブWebデザインを採用しマルチスクリーンに対応すれば、現在と異なるスクリーンサイズが主流になっても、きっと慌てることはありません。徐々にでも「守り」から「攻め」に発想を転換し、今後も続く環境変化に耐えうる、アクセシブルなWebサイトをデザインしていきましょう。

最後のメッセージ：なぜWeb業界で働き、Webデザインに携わるのか？

Webには、社会をより良くするための変革をもたらす力があると思います。大げさに言えば、人類の発展に貢献することだって可能でしょう。Web業界で働き、Webデザインに携わるなかで、誰もがWebにアクセスし続けられるようアクセシビリティの確保に取り組むことは、より良い社会の形成、人類への貢献そのものだと自分は信じます。Webの創始者、Tim Berners Lee氏は次のように述べています。

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

アクセシビリティは、Webの提供する本質的な価値なのです。それを忘れることなく、Webアクセシビリティの確保を通じ、共により良い社会の実現を目指しませんか。

次回予告

次回のレポートでは、村岡正和さんのセッション「アクセシビリティについて最近考えていることをざっくばらんに話すよ」をレポートします。お楽しみに！

2014年12月4日、ヤフー、ミツエーリンクス、ビジネス・アーキテクツの合同によるイベント「アクセシビリティやるぞ！祭り」が開催されました。

アクセシビリティやるぞ！祭り

このイベントは、「来るべき近未来のために業界の認識をアップデートすべく」（イベントページより）企画されたとのこと。近未来ってどういうことか、ちょっと気になります。

また、先日の木達一仁さんに行ったインタビューでも、「『アクセシビリティが当たり前の社会』というビジョンを実現するために、HTML5 Experts.jpとしても、お手伝いできることは何でもします！」と言った約束も守らねばなりません。

ということで、タイトルからしてちょっと楽しそうなこのイベント、無理を言って取材させてもらっちゃいました。今回はそのレポート記事になります。

「アクセシビリティ＝高齢者・障害者対応」は大間違い！

最初のセッションはヤフーでマークアップエンジニア/フロントエンジニアを担当していらっしゃる（最近では「アクセシビリティエンジニア」と名乗っているそうです）福本翔さんによる「やはりお前らのWebアクセシビリティは間違っている」でした。

「やはりお前らのWebアクセシビリティは間違っている」

Yahoo! Japan 福本 翔氏

講演スライドはこちらからダウンロードできます（PDF）。

タイトルは少し挑発的ですが、内容はとても真摯な内容。一般的にアクセシビリティというと、未だに「高齢者や障害者への対応」という認識が一般的ですが、それが大きな間違いであると指摘。そのように考えてしまうことが、「自分のサービスは高齢者や障害者を主な対象とはしていない」といった考えに繋がり、アクセシビリティへの配慮をおざなりにするマインドにつながりかねません。

そしてそれだけではありません。これまでWebは、スクリーンを通じて視覚で認識するのが当たり前でした。でも今後は違います。スマートウォッチのように、非常に小さいスクリーンしか備えないデバイスもあれば、スクリーンを持たないデバイスでインターネットにアクセスするのも普通になるはずです。

利用者も様々。デバイスも様々。コンテキストも様々。組み合わせは膨大であり、コンテンツ制作者が全ての利用シーンをコントロールすることはとてもできません。

利用者は様々

デバイスも様々

コンテキストも様々

そこでアクセシビリティの確保が重要になります。高いアクセシビリティを備えたWebコンテンツは、デバイスにとってもアクセスしやすいため、ユーザーの利用シーンに合わせて自動的に調整するのも容易です。

入出力機器がコンテンツを利用者に届ける際、アクセシビリティが重要となる

アクセシビリティのポイントは「ヒューマンリーダブル」「マシンリーダブル」「利用、操作可能な代替手段が存在すること」の3つですが、前述したユーザーエージェントによる支援を最大限受けるためには、「マシンリーダビリティ」を確保することが非常に重要。

Webアクセシビリティ対応の3つのポイント

マシンリーダビリティを高めるには、HTMLの様々な要素を「正しく、より良く」使うこと、WAI-ARIAを使うこと、Microdata、Microformat、RDFaなどの構造化データを利用するなどが挙げられます。こうした手法を地道に実践していくことで、既存のデバイスだけではなくまだ見ぬ未来のデバイスも、Webコンテンツをうまく取り扱える可能性があります。「アクセシビリティは未来への投資」というわけですね。

そして最後に、Webの創始者ティム・バーナーズ＝リー氏の言葉を引用しつつ、「Webアクセシビリティを高めることは、Webの本質を実践していくことである」という印象的なメッセージを残してセッションは終了しました。

ティム・バーナーズ＝リーのおことば

Webアクセシビリティの現状 – アクセシビリティ対応が法律で義務化！？

次は、ミツエーリンクス取締役CTOの木達一仁さんによる「Webアクセシビリティの現状ダイジェスト2014」です。先日公開した、木達さんのインタビュー記事も合わせてお読みいただけると、いろいろ面白いのではないかと思います（宣伝）。

　　ミツエーリンクス取締役CTOの木達一仁さん

このセッションでは、Webアクセシビリティの現状について、海外動向と国内動向、そして標準化技術の動向などをわかりやすくまとめてくださいました。

まず海外動向ですが、オーストラリアやニュージーランド、アメリカなどでは法律による義務化が既に進められているそう。（詳しくは上のスライドか、「ウェブアクセシビリティ基盤委員会 障害者差別解消法の基本方針に関する意見書」の後半に、海外各国の動向がまとめられているのでそちらをご覧ください）。

特に航空業界ではACAA (Air Carrier Access Act）という法律によってアクセシビリティの取り組みが義務化されているのですが、その対象範囲が米国内の企業にかぎらず、米国に乗り入れを行う企業にも及ぶため、航空業界ではアクセシビリティの取り組みが非常に進んでいるとのこと。

海外で進む法制化（例）

そして我が国では、総務省が2010年に公開した「みんなの公共サイト運用モデル改定版（2010年度）」がガイドラインとして存在します。 とはいえそこはやはりガイドラインの限界、特に強制力があるわけではないので、公共機関や民間企業の自助努力はあれども、アクセシビリティへの対応は遅れている状態です。

アクセシビリティに積極的な企業はまだ多くない印象

そこで日本でも、法制化に向けて既にことは動き出しています。国連が定めた障害者の権利に関する条約への批准に伴い、障害者差別解消法が制定され（再来年2016年より施行）、Webコンテンツも法律の対象範囲になるのはほぼ間違いないとのこと。「アクセシビリティに配慮していないWebサイトは法律違反に当たる」という時代が、現実のものになるかもしれません。

障害者差別解消法の今後には要注目

HTML5がバラバラに！？ – アクセシビリティ関連技術の標準化動向

続いて、アクセシビリティに関連したWeb技術の標準化動向が次々に紹介されました。

WCAG 2.0

まずはWCAG (Web Content Accessibility Guidelines)。Web文書のアクセシビリティに関するガイドラインであるWCAGは、2008年に2.0が勧告されて以来一度も変更されていないそう。2012年にはISOの標準 (ISO/IEC 40500:2012)にもなっています。

WCAG2.0

ただ、WCAGは技術非依存が前提になっているため、抽象度が高く、ハッキリ言って「難しい」。なので、様々な関連文書がWCAGを補足する形で公開されており、それらも理解の助けになるそうです。

• Web Accessibility Tutorials
• Understanding WCAG 2.0・・・日本語訳もあります。
• Techniques for WCAG 2.0・・・日本語訳もあります。
• WCAG-EM・・・Website Accessibility Conformance Evaluation Methodologyの略で、WCAG 2.0に適合しているかどうかを評価するための方法をまとめたガイドライン。

WAI-ARIA

WAI-ARIAとは、W3C内のWeb Accesibility Initiativeによって策定された、WebコンテンツやWebアプリケーションのアクセシビリティと相互運用性を向上させる技術です（ちなみに読み方は「ウェイ・アリア」だそう）。こちらは勧告されたのは今年（2014年）の3月ですが、既に広く利用されていた技術でもあり、仕様書の日本語訳や、HTMLでWAI-ARIAを使用するにあたってのテクニックを紹介した「Using WAI-ARIA in HTML」にも日本語訳があります。

ちなみに木達さんは、2010年の段階ですでにWAI-ARIAに関するスライドを公開していらっしゃいました。

HTML5

次は皆さんおなじみのHTML5（日本語訳）。先日（2014年10月28日）勧告された際には、非常に話題になりましたね。

HTML5仕様

HTML5で導入された様々な要素は、アクセシビリティを高める上で重要な役割を担います。例えばHTML5 Accessibilityというサイトでは、各ブラウザにおけるHTML5のアクセシビリティ機能への対応状況をスコア化してくれています。

HTML5 Accessiblityによる、各ブラウザのアクセシビリティ対応状況。IE頑張れ！

HTML5仕様に関して気になる動きとしては、先日開催されたW3C TPACというイベントで、HTML仕様の（CSS3と同様に）モジュール化が話題に挙がっていたとのこと。この先の見通しはまだ不透明な段階ですが、もしかすると次期バージョンと目されていたHTML5.1は解体され、モジュールごとに進化していくようなことになるのかもしれません。

ほか、木達さんのセッションではデバイス非依存のUIを定義しようとする試みであるIndieUIや、動画に字幕やキャプションを追加するためのフォーマットであるWebVTTについても言及がありました。興味がある方は、木達さんのスライド資料や仕様書を参照してみてください。

実践！Webアクセシビリティ

最後は、BA 制作本部 シニアインフォメーションアーキテクト 伊原 力也さんによる「アクセシビリティ対応をプロジェクトに取り入れるには？」というセッションでした。実際の制作現場でアクセシビリティ対応を行っていくにあたって、プロジェクト計画の立て方、クライアントや制作メンバーとのコミュニケーション、そしてアクセシビリティに対するそもそもの心構えなどについて、実践的な話をされていたのが印象的でした。

現在、アクセシビリティ対応はその必要性や重要性が十分に認識されておらず、上流工程における考慮漏れが頻繁に発生しているとのこと。それを、現場で「誰かがなんとかしている」というのがよくある話。

（今回のプロジェクトで）アクセシビリティどうするの？

伊原さんは、プロジェクトの設計段階でアクセシビリティに対する配慮がきちんとなされていないことに大きな問題がある、と指摘。 UXの構成要素を表す3つの図（古典的なUXハニカム、それを再構成した浅野紀世さんの手によるUXピラミッド、さらにそれをWebサイトの評価軸という点から再構成したもの）を引き合いに出しつつ、「アクセシビリティはWebサイトのUXにおける一番土台となるもの」と位置付けます。

UXハニカム

UXピラミッド

UXピラミッド改

アクセシビリティの問題は、8割が設計に潜んでいる！

実際にプロジェクトにおいてアクセシビリティ対応を実践していくには、まず最初にアクセシビリティへの対応方針について、最初にプロジェクト内で意思統一を行うのが大事です。

アクセシビリティの対応を最初に明言したからと言って、制作メンバーから面倒がられることはない、とのこと。むしろ、明確な方針があることが制作にあたっての「よい手がかり」になるそうです。

アクセシビリティ対応を最初に宣言することが、制作者にとって疎まれることはあまりない。

また、アクセシビリティへの対応を行うと宣言することが、クライアントから問題視されることも実はありません。専門家が「やった方がいい」というものを否定するクライアントはいませんし、そもそも最初に話を合わせておけば、「アクセシビリティのための追加コスト」は不要になるはずです。

そして実際の方針決めですが、リニューアルの場合はまず現状調査から入り、「ウェブアクセシビリティ方針策定ガイドライン」を参照しながら進めるのがよいそうです。

「アクセシビリティ対応をやらない」と決めるのも、立派に「方針」。これは聞いているぼくも目からウロコでした。

伊原さんのセッションは、「問題の8割が『設計』に潜んでいる」というメッセージを残して終わりました。アクセシビリティはWebサイトの土台を支えるものであり、そこをないがしろにして工程を進めてしまうと、後から取り返しがつかないということでしょう。

アクセシビリティの問題の8割は設計に潜んでいる

楽しくてためになる「お祭り」でした！

今回のイベントは、何かとマジメな方向に振れてしまいがちな「アクセシビリティ」というテーマを、「お祭り」というかたちでまとめあげていて、聞いているこちらもリラックスして楽しむことができました。

グラフィックレコーディングをこの目で見れたのも、なかなかに収穫。次回の開催が今から待ち遠しいです！

HTML5 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ第二弾です。

株式会社ミツエーリンクスCTO、そしてエキスパートNo.40の木達一仁さんに、「UXとWebアクセシビリティ」について聞いてきました。 「UXとWebアクセシビリティって、関連あるのかな？」なんて、自分で企画したにも関わらず無責任な疑問を抱える中、そんな疑問を吹き飛ばすような気付きをいただける貴重なインタビューでした。

alt属性からWeb Componentsのアクセシビリティまで、たっぷり聞いてきました！皆さんどうぞ、お楽しみください。

Webアクセシビリティについての現状

白石: 今日は、「UXとWebアクセシビリティ」というテーマでいろいろお話を伺いたいと思います。どうぞよろしくお願いします。

木達: はい、よろしくお願いします。

白石: まずはちょっと「UX」というキーワードは横に置いておいて、アクセシビリティに関する現状についてお聞きしたいです。アクセシビリティに関する意識は、Web業界全体で高まっていますか？

木達: 私の感じるところでは、特に高まってはいないですね。アクセシビリティに関する意識の向上に繋がるようなイベントなども、まだまだ不足していると思います。

白石: そうですかー、まだまだって感じなんでしょうか。

木達: ただ、良いニュースもあります。今度、ヤフーさんやビジネス・アーキテクツさんと、アクセシビリティやるぞ！祭りというちょっと変わった名前の（笑）イベントを開催するのですが、あっという間に満員になりまして。これは少し追い風かな、と。でも参加者のリストを見ると、（イベント参加の必要がないほど）既にアクセシビリティに詳しそうな方も結構いらっしゃるんですよね。そういう方々はもしかすると、「アクセシビリティを盛り上げたい」という思いで申し込んでくださったのかもしれません。どちらにしても、ありがたいことです。

　▲HTML5 Experts.jpエキスパート木達一仁さん

白石: いいですね！タイトルもゆるくて面白そうです。

木達: このように、意識を高めるべく民間主導で取り組み始めているほか、国が主導してアクセシビリティ対応を推進していこうという動きがあります。 例えば、総務省は「みんなの公共サイト運用モデル」をガイドラインとして公開、公的機関に対しアクセシビリティ対応を推奨しています。しかし、これはあくまで手引きでしかなく義務ではないので、強制力は弱い。

もっと強い枠組みを求める、法制化に向けた動きもあります。
国連が定めた障害者の権利に関する条約への批准に伴い、障害者差別解消法が制定されました。この法律は来年が周知期間で、再来年から施行されます。その基本方針に対し、私が副委員長を務めるウェブアクセシビリティ基盤委員会は、「アクセシビリティへの対応を怠ることは障害者差別にあたる」との観点から、内閣府に意見書を提出しています。

白石:アクセシビリティ対応が、法律でルール化されるかもしれないということですか。

木達: はい。ただ、法律に定められているからアクセシビリティに対応する、やらないと罰せられるから取り組むというのは、正直言ってちょっと意識低いよな、と思います。
Web技術者たるもの、Webのアーキテクチャが持つ可能性を最大化するためにも、アクセシビリティ向上には積極的に取り組んでいきたいですね。

白石: 啓蒙や法制化の他にも、ビジネス的なメリットを打ち出すことができれば、企業にとってもアクセシビリティ対応の動機付けになるのではと思います。ビジネスの観点からアクセシビリティを見た場合、どのようなポイントがありますか？

　▲インタビュアーHTML5 Experts.jp 白石俊平編集長

木達: アクセシビリティという概念は、コスト意識やROI（投資利益率）といった話題と相性がよくないと感じます。ビジネス的なメリットは確かにあるのですが、具体的にいくら儲かるから対応しましょう、とは言いがたいです。

CSR（企業の社会的責任）という観点からは、例えば沖電気さんは、昔からアクセシビリティ対応を行っていらっしゃいます。

海外では日本国内と異なり、アクセシビリティに対する意識は高まっていて、法律で対応が義務付けられている国もあります（編集部注: ウェブアクセシビリティ基盤委員会 障害者差別解消法の基本方針に関する意見書の後半に、海外各国の動向がまとめられている）。 それゆえ、グローバルビジネスを展開されている企業は比較的、アクセシビリティ対応に積極的ですね。

海外展開を行う企業にとっては、アクセシビリティ対応が国際競争力に関わる可能性がある…とも言えるかもしれません。

UXとWebアクセシビリティ

白石: ではいよいよ、UXというキーワードについても触れていきたいと思います。UXとアクセシビリティは、どのような関連がありますか？

木達: Webコンテンツを中心として考えると、ユーザがコンテンツにアクセスする前、アクセス中、アクセス後のそれぞれにUXがあります。アクセシビリティはその中でも、コンテンツにアクセスしている最中のUXに紐付いていると言えるでしょう。つまり、コンテンツのUIと密接に関連があります。UIがどれだけアクセシブルか、それがUXとアクセシビリティを考える上で重要ですね。

白石: なるほど。そして、WebのUIといえばHTMLですね。

木達: はい。WebのUIをアクセシブルにするなかで、必然的に「マシンリーダブル」^[1]なHTMLマークアップを目指すことになります。かつて、マシンリーダブルなHTMLマークアップを推し進める原動力となっていたのはSEOでした。検索エンジンのクローラを視覚を持たないユーザになぞらえ、クローラにとって解釈しやすいコードを書くことで、検索結果上のランキングを向上させようとしていたわけです。

しかし今後は、別の大きなトレンドが、マシンリーダブルなHTMLマークアップを目指す原動力になっていくでしょう。

[1]マシンリーダブル…人間ではなく、機械やプログラムにも読み取り可能なこと。

白石: と、いうと？

木達: デバイスの多様化です。ユーザーは既に、一つのWebコンテンツに対して様々なデバイスから様々な方法でアクセスするようになっていますし、今後その動きは加速していくでしょう。Webは、基本的にコンテンツをアクセシブルに提供できるよう設計されていますが、そのポテンシャルを最大化するためにも、アクセシビリティの確保は今後重要になってくるだろうな、と考えています。

現代ビジネスに掲載されていた古川健介氏へのインタビュー記事で、ハッとさせられた言葉があるんです。それは、インターネットにおける次の大きなトレンドは何か？という質問に対し、古川氏が「画面がなくなることだ」と答えていらっしゃったんですね。この将来予測はとても面白い。

もし画面がなくなってしまったら、Webを視覚以外で利用することが一般化するはず。ぱっと思い浮かぶのは、Webコンテンツ音声で読み上げてもらうことでしょう。そうなった場合、Webコンテンツがマシンリーダブルであることが（スクリーンリーダーなどのプログラムがWebコンテンツを読み取る必要があるので）非常に重要です。

白石: 確かに、デバイスによってはWebコンテンツへのアクセス方法は全く変わってきそうですね。Google Glassやスマートウォッチなどの、画面の非常に小さなデバイスも出てきていますし、そうしたデバイス上ではWebコンテンツは全く違った消費のされ方をするかもしれません。

木達: そうですね。多様なデバイスからアクセスされることを前提とした場合、アクセシビリティに配慮したWebコンテンツのほうが、高いレベルのUXを提供できるのは間違いないと思います。

HTML5はWebアクセシビリティを変えるか？マイクロデータは？JavaScriptは？Web Componentsは？

白石: HTMLの話が出たので、ちょっとこのまま、HTMLやJavaScriptなどのフロントエンド技術と、アクセシビリティの関係についていろいろ伺いたいと思います。例えば、HTML5ではWebページのアクセシビリティ向上が期待できる新しい要素がいくつも追加されました。例えばmain要素やnav要素が挙げられると思います。こうした要素が増えたことで、アクセシビリティの高いWebページを、Web制作者が自然と記述するようになった…といった変化はありますか？

木達: 新しい要素は既に普及し始めてはいるものの、ユーザーエージェントや支援技術の対応状況からすると、それでアクセシビリティが劇的に向上したという印象はまだありません。ただ、今後に期待はしています。例えばmain要素については、2012年のHTML5 Advent Calendarでも取り上げたのですが、非常に重要な要素です。main要素の登場以前は、Webページ内の「主要なコンテンツ」にアクセスする手段は、スキップリンク（ページ先頭などに仕込まれた、「本文へ」のような隠しリンク）や、レベル1の見出しを主要コンテンツの先頭に置くといった方法が取られてきました。main要素が登場したおかげで、ユーザーの「主要なコンテンツに素早くアクセスしたい」というニーズを、よりスマートに満たすことができるようになると思います。

白石: マイクロデータなどの、メタデータを表す技術はいかがでしょうか？アクセシビリティ向上に役立つ可能性はありますか？

木達: はい、それはありますね。ユーザーエージェントが意図した通りにコンテンツを解釈し、ユーザーに伝えてくれる可能性が高まります。

白石: 日付を表すデータの通知をスマートウォッチ上で受け取り、それをそのままカレンダーに登録するといったこともできそうですね。

木達: HTML5で新たな要素が数多く追加されましたが、無限に増やしていくわけにもいきません。そうなるとマイクロデータなどの、既存の要素に新たな意味を付与していける枠組みは重要になると思います。

白石: 「要素を無限に追加していけるわけではない」というお話で思いついたのですが、Web Componentsなら、要素を無限に追加することはできそうですね。Web Componentsとアクセシビリティの関係はどうなるとお考えですか？

木達: Web Componentsによるカスタム要素は、ブラウザ内部では既存の要素群に展開・処理されます。展開後の状態がアクセシブルである限り、影響はあまりないのではないか…と思います。ただちょっと心配なのは、「アクセシビリティへの配慮に欠ける、でもUIがカッコいい」みたいなカスタム要素が世界的に流行して、Web全体のアクセシビリティが低下してしまうような事態が起こらないといいな、と。カスタム要素を使う側からすると、カプセル化されたマークアップの質にはあまり注意を払わないでしょうから。

白石: 確かにそれは心配ですね…でもまあ、そのカスタム要素がバージョンアップすることで、一気にアクセシビリティが改善するということもあるかもしれませんし、逆に言えばアクセシビリティの高いコンポーネント群が流通すれば、容易にアクセシビリティに優れたWebサイトを構築できるようになるかもしれませんね。ちなみに、JavaScriptなどを用いた動的なUIであっても、アクセシビリティは確保できるものなのでしょうか？

木達: WAI-ARIA[2]を適切に実装している前提においては、大きな問題は起こりにくいでしょう。たとえばaria-liveプロパティを使って、JavaScriptなどにより動的に変更される部分を明示することができます。野球のスコアボードをHTMLで作ったとして、その点数が動的に変更された場合、変更部分の情報だけをユーザーに伝えることも可能です。

WAI-ARIAはいいですね。アクセシビリティを明らかに改善する技術です。正直なところ、大昔はWAI-ARIAの効果については懐疑的だったのですが、今は改心しました（笑）。

[2]WAI-ARIA…W3C内のWeb Accesibility Initiativeによって策定された、WebコンテンツやWebアプリケーションのアクセシビリティと相互運用性を向上させる技術。roleなどの属性をHTML要素に設定することで、UIのアクセシビリティを向上させることができる。W3C仕様

白石: なるほど、それは知りませんでした。JavaScriptを用いた動的なページを作って、アクセシブルにするには、そうした分野の知識も学んでおく必要があるんですね。

受託制作とUX

白石: ここまで、たくさんの興味深いお話をどうもありがとうございました。最後にまたUXの話題に立ち戻りたいのですが、先だってインタビューさせていただいた長谷川恭久さんが、日本固有の「Web制作の受託」という業態が、UXのトータルな改善を難しくしているという問題提起をされていました。木達さんが取締役を務めているミツエーリンクスも、Webサイトの受託制作を数多く手がけていらっしゃると思いますが、受託という立場からUXを改善していくという点にあたっては、どのようなご意見をお持ちですか？

木達: 案件にもよりますが、確かに、受託として入り込める限界というのはあります。やはり、お客様との距離が近ければ近いほうが、WebサイトのUX改善については実現できることが多い。例えば弊社では、社員がお客様のオフィスに常駐するようなかたち（オンサイト）でお仕事させていただくこともありますが、UXのトータルな改善という点から言うとそのほうが理想的です。制作部分だけではなく、運営全体をお客様と一緒になってやっていけますから。

また、お客様のサイトを運用するためのチームをミツエーリンクス社内に設置しているケース（オフショア）もあります。制作だけではなく、運用面についてもお任せいただける場合のほうが、やはりUXの改善に深く取り組めますね。

白石: 制作だけのお仕事の場合、運用のことを全く考えないマークアップをしてしまうことも防ぎにくいですしね。

木達: 社内の人間がそんなマークアップをしていたら、怒っちゃいますけどね（笑）。典型的な受託制作案件であっても、「運用のことを考えて作る」というのは日頃から心がけているつもりですし、コードに対するレビューをワークフローに組み込むことで、品質の担保は心がけています。ちなみに弊社では、基本的なアクセシビリティ対応については追加コストなしで提供するようにしています（プレスリリース「ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）2.0への標準対応の開始について」）。Webページの品質という観点からすれば、最低限のアクセシビリティ確保は基本的な品質なので。

白石: UXについての、企業としての取り組みはいかがですか？

木達: 弊社にはUX部という専門の部署やユーザーテストスタジオと名付けた施設があり、ユーザビリティテストやユーザー調査を実施できる体制、環境を整えていますね。ユーザーテストスタジオでは、アイトラッカーを使ってユーザーの視線がどう動くかを調査したり、ハーフミラー越しにその様子を観察することができます。

白石: ユーザビリティテストのための専用の部屋があるんですね。見たい…（編集部注: この日はお部屋が終日使用中で、見せていただくことは適いませんでした。残念！）

「アクセシビリティが当たり前」の社会を作る

白石: 最後に今回のインタビューのまとめとして、一言いただけますでしょうか？

木達: 「いつ、誰が、どのようなデバイスを用いてWebにアクセスするかわからない」という時代は既に始まっています。そういう時代においては、アクセシビリティに配慮することが「いつでも、誰でも、どんなデバイスからでもアクセスしやすいWeb」につながり、ひいてはUXを向上させることにもつながります。

そして「アクセシビリティに配慮する」と言っても、難しく考える必要はありません。できることから確実に実践していけばよいと思います。例えば、まずはimg要素には適切な代替テキストをalt属性で指定するようにする…というだけでもよいのです。そうした個々人の行動が、「アクセシビリティが当たり前」の社会を作ることに繋がると思っています。

白石: 「アクセシビリティが当たり前の社会」、素晴らしいビジョンですね。HTML5 Experts.jpとしても、お手伝いできることは何でもさせてください！本日は、長時間に渡るインタビュー、どうもありがとうございました。

斉藤祐也の海外WEBテク定点観測＜Issue.10: 2014/01/01-2014/01/31＞

今月の定点観測は、CSS Regionsに対する問題提起、新picture要素仕様、Webスタンダードの新フェーズなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

CSS Regionsへの問題提起 – An A List Apart Blog Post

原題: CSS Regions Considered Harmful

タイトルからしてすでに議論を呼び込むようなタイトルとなっている、CSSの父であるHåkon Wium Lie氏によるCSS Regionsの仕様に対する問題提起。
時を同じくして、GoogleのBlinkチームがCSS Regionsを実装しないという議論も始まり、大きな議論に発展しています(関連リンクを参照してください)。
この記事でHåkon Wium Lie氏はRegionsはダミーのdivを使う必要がある、レスポンシブではない、テキストフローが分かりづらい、33行にもおよぶほどのコードで実現するしかない、コードの再利用性が低いという5つのポイントを問題点として挙げています。

関連リンク:

• CSS Regions in Blink: status, future work / CSS Regionの実装についての議論
• CSS Regions Matter – Flippin’ Awesome / CSS Regionsを実利的に利用した例を豊富に紹介

The picture Element

レスポンシブ画像に対する飽くなき議論の末、議論の始まりとなったpicture要素の新仕様が発表されました。これまでの議論をうまく集約した提案となっています。フォールバック要素としてのimgではなく、picture要素内に必須となる要素としてimgを利用している点が、以前のpicture要素との違いとなるポイントとなっています。

関連リンク: picturefill – Shawn Jansepar / 新仕様に合わせたPolyfill

2014年、Webデザインは死んだのか? – Jeffrey Zeldman Presents The Daily Report

原題: It’s 2014. Is Web Design Dead?

Jeff Croft氏による「Web Standards Killed the HTML Star」という記事を見かけた方も多いかも知れません。その記事へのJeffrey Zeldman氏からの反論がこの記事です。Zeldman氏は確かにChroft氏が言う通りの部分があることは認めつつ、Webスタンダードには2つのフェーズがあり、現時点ではその内の1つ目がようやくまともになってきたタイミングだとしています。
Zeldman氏はWebスタンダードは当たり前の存在であるべきとしつつ、さらにウェブサイトを構築することを簡易にし、その上でデザイン、コンテント、そして体験を生み出すことにフォーカスしやすくするのが次のフェーズであると主張しています。

関連リンク: Web Standards Killed the HTML Star – JeffCroft.com

フロントエンド開発における問題解決へのプロセス – CSS-Tricks

原題: Thought Process of a Front End Problem

海外の第一線で活躍するフロントエンド開発者であるChris Coyier氏が自身が実際に解決しようとした「Opera mobileでフォントのレンダリングがおかしい」という問題へのアプローチについて詳細を語っています。
共感できる点が多く、やはり第一線にいるCoyier氏でも環境が大きく異なるブラウザの世界では同じように苦労しているのだなというのが分かります。
彼自身がどのように問題に対峙したのかの記録は似た問題を解決する際の参考になるのはもちろん、フロントエンド開発における問題の多くの解決に参考になります。

アルゴリズムはフロントエンド開発者にも必要な知識か? – Aerotwist

原題: Algowhatnow?

フロントエンド開発者の面接に、アルゴリズムに関する問題を出す意味はあるのでしょうか？
フロントエンドに関わる多くの開発者コンピュータサイエンス関連の大学を卒業していないケースもあり、アルゴリズムそのものよりもクロスブラウザに対するアプローチや知見などのほうが優先度が高いという議論もありますが、コンピュータとの対話を行うためにやはりアルゴリズムは欠かすことができないのかもしれません。
ロジカルシンキングの指標としても利用できるアルゴリズムへの知見は持っていて損はしないという主張。

海外トレンドコラム

ボタン要素はいつ使うべきなのか? – CSS-Tricks

原題: When To Use The Button Element

a要素とbutton要素はどのように使い分けて行くべきでしょうか？ CSSを利用して、どんな要素でも自在にスタイリングできるようになったからこそ知っておきたいことです。

EMEの利点と欠点

原題: EME pro and con

W3Cが仕様を策定しようとしていることで話題になっているEME(Encrypted Media Extensions)について利点と欠点をコンパクトにまとめたGoogle Docs。
これまでに多くの議論が行われてきているので、今からその議論に追いつきたい場合に非常に役に立つ文書です。

アクセシブルなアイコンフォントの使い方 – Filament Group, Inc., Boston, MA

原題: Bulletproof Accessible Icon Fonts

アイコンフォントを利用するケースが徐々に増えてきています。しかし、アイコンフォントの利用に際して忘れられがちなのがアクセシビリティ。音声ブラウザがアイコンフォントに使っている文字を発してしまったりするのは避けるべきです。この記事では、アクセシビリティを考慮したアイコンフォントの利用について、詳細に紹介しています。

CSS Will Change Module Level 1

レンダリングのパフォーマンスを向上させるために、利用せざるを得ないtranslateZなどを活用したハック。有効でありかつ手軽である反面、ハックである事実は変わりませんし、それなりのコストもかかります。
このCSS Will Change Moduleはそのハックを必要とせずに済むように提案されている仕様です。

関連リンク: Bye Bye Layer Hacks – Aerotwist

Promisesガイド – w3ctag

原題: Promises Guide

Promisesの仕様を作成しているチームにより、どのようにPromisesは利用するのかについてのガイドラインが公開されました。ライブラリなどを作成する際に参考になるだけではなく、少々とっつきづらい文章ながら、既存のPromisesライブラリを利用する際にも参考になるはずです。

jQueryはもう必要ない?

原題: You Might Not Need jQuery

数年前までは、jQueryなしでのクライアントサイドの開発は想像できませんでした。しかし、レガシーブラウザへの対応の必要性が少しずつ減ってきた今、jQueryは本当に必要でしょうか？
このサイトでは、ネイティブJavaScriptでjQueryが提供しているAPIを代替するスニペットを紹介しています。

関連リンク:

• Why You Still Need jQuery / いわゆるモダンブラウザでもクロスブラウザの問題を解決するのにjQueryが行っているワークアラウンドを示しています。
• Twitter / jeresig: I keep writing and deleting … / jQueryのオリジナルの作者であるJohn Resig氏のコメントにも注目してください。

head要素内にCSSを入れるのは何故なのか? – Aqeel

原題: What’s with putting the CSS in the head?

これまで知られているベストプラクティスでは、CSSは外部CSSファイルから呼び出す。となっています。本質的には現時点でも間違いではありません。しかし、近年CSSをstyleタグ内に記述する例も増えています。なぜそうすることがパフォーマンス観点でプラスに働くかについて、ブラウザのレンダリングの仕組みなどを踏まえて詳細に解説しています。

Promise nuggets – Gorgi Kosev

なかなか理解するのに苦労するPromisesについて、コールバックとの違いを実例を通して解説してくれているのがこのサイト。コールバックを使ったアプローチとの比較のおかげで、Promisesの利点や実装イメージがわきやすくなるはずです。

HTML、CSS、JavaScriptを合わせたモジュールデザイン開発へのアプローチ – Techwraith

原題: Atomic Product Development

モジュールデザインというアプローチは、今ではウェブ開発において欠かすことができないものとなっています。近年はJavaScriptにおけるモジュールデザインが盛んに議題に上がっていますが、CSSについてはあまり言及がありません。この記事では、HTML、CSS、JavaScriptが持つ依存関係の低減に必要なアプローチについて、詳しく解説しています。

CSSOMを使ったCSSの機能テストについて – Ryan Morr

原題: Feature Testing CSS At-Rules

ブラウザでどのCSSのAPIが実装されているかを調べる手法の紹介。この記事では「@」を利用する機能のテストについて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

Promises/A+ 実装を通じて仕様について学ぼう v.1.1対応版 – Modern JavaScript

原題: Promises/A+ Understanding the spec through implementation v1.1

ネイティブでJavaScriptに実装される予定であるPromises。その元々の仕様であるPromises/A+と呼ばれる仕様が、昨年の8月にバージョン1.1に変更されました。その変更を踏まえて、実装と仕様を合わせて解説しているのがこのスライド。細かい部分についても分かりやすく解説してくれているのでおすすめです。

JavaScriptにおけるSOLID – Derick Bailey

原題: SOLID JavaScript In A Wobbly (World Wide Web)

オブジェクト指向における有名な5つの設計原則をまとめたSOLIDを、JavaScriptで実践する際に気をつけておくべきポイントについて、詳しく解説している動画です。スピーカのDerick Bailey氏はBackbone.jsのプラグインMarionette.jsの作者でもあります。

CSSの3D、アニメーションについてインタラクティブに学ぶ – Chris Ruppel

原題: Unfolding the Box Model

CSSの3D Transformsについて、インタラクティブに学ぶことができるサイトです。アニメーションはもちろん、3Dのコンセプトは実際に動いているものを見ることが一番わかりやすいので、初心者、中級者の方はぜひ。

JS: The Right Way

JavaScriptに関する優れた様々な情報を集めて紹介しているサイトです。Superhero.jsと同じようなコンセプトではありますが、記事だけではなくライブラリなどもコレクションしています。

Remote.js – Hage Yaapa

WiFiもBluetoothも使わずに、音を使ってスマートフォンからデスクトップブラウザを操作するためのライブラリ。
実際に動作する(試してみたところ、少々怪しげながら動作します)デモもあり、非常に興味深いツールです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年3月3日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.9: 2013/12/01-2013/12/31＞

今月の定点観測は、JavaScriptにおけるPromises実装について、CSSの変数(Custom Properties)、Quartz ComposerのプラグインOrigamiなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

JavaScriptにおけるPromises実装について – HTML5 Rocks

原題: JavaScript Promises: There and back again

これまでJavaScriptの『限界』であるシングルスレッドを解決するために、コールバックやイベントを利用してきました。そのJavaScriptにもう1つ、Promisesと呼ばれる機能が追加されます。
Q.jsやwhenなどのようなライブラリを使ってすでにPromisesを利用している人も多いことでしょう。
現時点ではChrome CanaryとFirefox Nightlyにて一部の機能が利用でき、Polyfillも存在しています。
JavaScriptネイティブのPromisesはrsvp.jsのAPIとほぼ同じとなっているようです。

CSSの変数(Custom Properties)で遊んでみよう – That Emil

原題: Playing around with CSS variables – “custom properties”

CSSに変数を追加することは開発者から長期にわたって要求されてきました。CSSプリプロセッサがまだない時代からのこの要求に対し、様々な試みがされてきましたが、ついにFireFox Nightlyに「CSS Custom Properties for Cascading Variables Module」という仕様に則り実装されました。
Emil Björklund氏による記事はその実装に対しての実験を行っています。
詳しい仕様についてはCSS Working Groupのメンバーの1人であるTab Atkins Jr.氏が昨年2013年にCSS Dayにて発表した『Variables & Conditionals』にて詳しく解説しています。

またTab Atkins Jr.氏が2012年に提案したドラフトの頃からCSSに変数が必要であるか否かについての議論が途絶えたことはありません。
それら反論についても知っておくとよいので、以下に関連リンクとして紹介しておきます。

関連リンク:

• About Variables in CSS and Abstractions in Web Languages – CSS-Tricks
• Sasstraction – Adactio

Quartz Composerを使ってのプロトタイプ制作プラグイン: Origami — Julie Zhuo

原題: Introducing Origami for Quartz Composer

Webでもアプリケーションでもデザインに求められることが表層にある見た目だけではなくインタラクションなども含まれるようになって来ています。
Facebookではそのインタラクションを含むデザインを行うのにQuartz Composerを利用してプロトタイプを作成しているそうです。
Quartz ComposerはMac OS Xの開発環境の一部として提供されているビジュアルプログラミング言語で、元々はプロトタイプを行うためのツールとして提供されているわけではありません。
Origamiはそのやや取っ付きづらいQuartz Composerをよりプロトタイプツールとして使いやすくするパッチを提供するオープンソースツール群です。
この記事ではFacebookのプロダクトデザインディレクタであるJulie Zhuo氏がツールの紹介をしています。

関連リンク:

• FacebookのOrigamiグループ
• How to Survive in Design (and in a Zombie Apocalypse)
• Go Big by Going Home

オフライン・ファーストでウェブアプリケーションをデザインする – A List Apart

原題: Designing Offline-First Web Apps

前回の本連載でもとりあげた、オフライン・ファーストというアプローチについての続報。
記事ではなぜオフライン・ファーストを重要視するべきなのか、オフライン・ファーストのアプローチを採用する上でどんな問題点があるのかについて詳細にわたり解説しています。 offlinefirst.orgを牽引するHoodieチームの一員である筆者のAlex Feyerke氏は以下のように述べています。

『オフライン状態のWebサイトやアプリケーションの利用に対する体験はよりよくならなければならないし、もっとがっかりさせないようにしなくてはならない。もちろんもっと便利である方がいい。接続されていない、マルチデバイスの世界についてのガイドやパターンのカタログ、レスポンシブウェブデザインが築いてきたようなUXがオフライン・ファーストを行うためにも必要だ。』

関連リンク:

• Offline First: Learning from native experiences — Dion Almaer
• ServiceWorker & the offline web – Tom Ashworth

ベンチマークに関する注意点について – Aerotwist

原題: Bad Benchmark, Right Result

Googleの中でもパフォーマンスに関するすばらしい記事を常に提供してくれるPaul Lewis氏によるベンチマークに関する注意点。
結論から言うと、現時点では3D Transformsを扱うために非常に便利なCSSMatrixを使うと結果的に（少なくとも）toString()を利用して処理するため、パフォーマンス観点ではあまりプラスにはなりません。
しかしこの記事ではその結論よりも、彼がどのようにAPIを使ってよりパフォーマンスを向上させているのか、そしてそれをどのようにベンチマークしているのか。JSPerfを使ったベンチマークにおける注意点なども含め、一連の流れについて着目していただければ。

海外トレンドコラム

ブラウザへの12個のパフォーマンス要望リスト – Performance Calendar

原題: Browser Wishlist 2013

2013年の年末にSteve Souders氏がまとめた12項目からなるブラウザへのパフォーマンス観点での要望リスト。
この時点で要望されるということは気をつけておく必要があるリストでもあるので、各項目をしっかりレビューしておくとよいでしょう。

Chromeの開発者ツールをFirefoxで使えるとしたら? — Kenneth Auchenberg

原題: What if you could use Chrome DevTools with Mozilla Firefox?

先月の本連載で紹介したremotedebug.orgの中心的人物であるKenneth Auchenberg氏によるFirefoxでChromeのDevToolsを利用する様のデモ。こうして実際に動作するものを見ると、remotedebug.orgが進めるBridgeという概念がいかに強力なものであるかが分かります。

アクセシビリティに合わせたコーディングをしよう – 24 ways

原題: Coding Towards Accessibility

アクセシビリティが重要であることはことさら今改めて伝えることではありませんが、どうしても難しいものというイメージがつきまとうものです。この記事ではそのアクセシビリティについて、習慣化しやすい実利的な手法について詳しく紹介しています。

Chrome開発者ツールを使って60FPSを実現するためのワークフロー – Wingify Engineering

原題: Getting 60 FPS using Chrome devtools

パフォーマンス改善はルールを覚えることより、ツールを使って実測しながら行うのが鉄則です。この記事ではそのツールの中でも最も優れた機能を有しているChrome DevToolsを使って一連の改善に関するワークフローを紹介しています。スクリーンショットも多く非常に分かりやすいです。

Position: fixedに関する最新情報 – QuirksBlog

原題: position: fixed update

モバイルWebサイトやアプリケーションの制作に携わったことがある人であれば、必ず遭遇する問題の1つであるposition: fixedにまつわるバグについての現状を、Peter-Paul Koch氏がまとめています。実際の動作を動画で表示しているので、ぜひ自分の目で確認してください。

MEANスタックをYeomanで素早く構築する方法

原題: Full-Stack JavaScript With MEAN And Yeoman

MongoDB、Express.js、Angular.js、Node.jsそれぞれの頭文字を取ってMEANスタックと呼ばれるフルスタックJavaScript開発フレームワークをYeomanを使って素早くセットアップする方法について紹介。
そもそものMEANスタックとは何かについても理由を含めてきちんと紹介してくれています。

JavaScriptでキネティクス・スクロールを実現するためには – don’t code today what you can’t debug tomorrow

原題: JavaScript Kinetic Scrolling

EsprimaやPhantomJSの制作者として知られるAriya Hidayat氏による、パート4(パート5もあるそう)にまで及ぶキネティクス・スクロールについてのJavaScript実装に関する記事。iOSに見られるような自然なスクロールを実現するために必要な事柄を分かりやすく解説しています。

WalmartにおけるNode.jsセットアップ

原題: Walmart Mobile node.js Setup

PayPal社がバックエンドをJavaからNode.jsに移行したという記事が話題になっていましたが、この記事はアメリカ最大のスーパーマッケットチェーンであるWalmartにおけるモバイルサイトでのNode.jsのセットアップについて触れられています。ブラックフライデーを乗り越えたWalmartのセットアップは今後のNode.jsの可能性を感じることができるすばらしいリソースになるはずです。

クローズアップ“ビデオ/スライド/ツール”

The Need for Speed – Guillermo Rauch at dot.js 2013

今ではWordpressを運営するAutomattic社に買収された、クラウドシェアリングサービスのCloudupのGuillermo Rauch氏による、シングルページアプリケーションにおけるパフォーマンス改善のティップス集ともいえるスライド。

Faster JavaScript web apps – Alex MacCaw at Fronteers 2013

こちらはAlex MacCaw氏による、シングルページアプリケーションにおけるパフォーマンス改善に関する発表の動画。よくあるボトルネックについて丁寧に解説しており、シングルページアプリケーションに限らず利用できます。

CSS module system in Google+ – Shubhie Panicker at CSSconf.eu 2013

Google+は、どのようにCSSをモジュラー化しているのか。2013年の9月に、CSSconf.euにてShubhie Panicker氏により発表されたプレゼンテーションの動画。
単純に1ファイルにまとめるだけでは無駄が多いCSSのこれからの課題がここにあると思っているので参考に。

関連リンク: Your CSS needs a dependency graph – Techwraith

Project Hubs: デザイン・プロジェクトをどう管理するべきか – 24 ways

原題: Project Hubs: A Home Base for Design Projects

プロジェクト管理のツールは多く存在しているが、デザインに関しては便利なツールが存在しません。そこでBrad Frost氏は、Project HubsというシンプルなHTMLベースのツールを作りました。この記事ではそのProject Hubsが解決しようとしている問題とその解決方法について紹介しています。

関連リンク: bradfrost/project-hub

Web Browser Compatibility Tables – Cody Lindley

1％以上のマーケットシェアを持つブラウザについてどの機能が実装されているのかを一覧できるWebツール。
類似のツールは多くありますが、幅広い機能とブラウザについて一覧できるので非常に便利です。

SpinKit – tobiasahlin

Ajaxでコンテンツを取得する際や、巨大なテーブルデータをソートするような場合によく利用するローディングをCSSアニメーションで実現し、例示しているGitHubのレポジトリ。
現時点で7種のローディングのデモをこちらから閲覧できます。

Poly Maker – Aerotwist

ポリゴンシェープを生成するPoly Makerというツールの紹介。
今となってはややローファイさを感じるポリゴンを美しいカラーで表現しているツール。ツールそのものもすばらしいがどう作るかについての紹介のほうが興味深いです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年2月3日にお届け予定です。★

いまやマルチデバイスの時代。PCやタブレット端末、スマートフォン、将来的にはメガネ型デバイスも登場しつつある。「今はこのような時代。Webは特定のデバイスや環境のものではない」

こう語るのはミツエーリンクスの黒澤剛志氏だ。黒澤氏は同社のアクセシビリティエンジニア。顧客のWebサイト診断やコンサルティング、社内制作物のチェック業務のほか、同社が運営しているアクセシビリティBlogの執筆などを手がけている。またW3C UAWG（User Agent Accessibility Guidelines Working Group）のメンバーも務める。

マルチデバイス時代のWebアクセシビリティとは

先述したようにマルチデバイス時代では、Webはいろいろな環境から操作できること重要になる。「これはWebアクセスビリティそのもの」と黒澤氏は言う。Webアクセスビリティとは特定の環境に依存せず、多くの環境からWebを利用できることだからだ。

現在、登場しているデバイスは冒頭で紹介したものだけではない。テレビのリモコンのような細かな操作が難しいデバイスもあれば、キーボードがないデバイス、音声入出力、電子ペーパー（ディスプレイがモノクロやグレースケール）などのデバイスでも問題なくWebが利用できるようにしなければならない。

「考慮しなければならないのはデバイスだけではない。Webの使用環境もさまざまある」と黒澤氏は指摘する。

例えば屋外で直射日光の下に使う場合もあれば、音を出せない・聞こえない場合もある。またマウスを使うことが難しい場合もあるだろう。このようなさまざまな状況からアクセスした場合でも、「Webがきちんと利用できるようにすることがWebアクセスビリティに欠かせない条件」というわけだ。

また最近のOSには高齢者や障害者を支援する技術（支援技術）を標準で搭載されている。スクリーンリーダー（コンピュータの画面読み上げソフトウェア）、画面拡大やズーム機能、ハイコントラストモード（色を反転する機能）などは支援技術の一例だ。このような機能が「WindowsやMacOSだけではなく、iPhoneなどのスマートデバイスのOSにも標準搭載されだしたことで、これまで支援技術を使ってこなかった一般の人たちも支援技術を利用しつつある」と黒澤氏は言う。つまりこれらの支援技術の環境下でもWebが正しく操作できなければならない。

つまりさまざまな環境からWebにアクセスする時代において重要になるポイントは何か。黒澤氏が挙げたのは

• セマンティクス」
• さまざまなデバイス、環境でのインタラクション
• グラフィックスとマルチメディアの代替コンテンツ

の3点である。

ユーザーに合った環境で「セマンティクス」を可能にする

最初に取り上げたのは「セマンティクス」。セマンティクスとはプログラムが意図すること。どんなデバイス・環境でWebにアクセスしても「セマンティクスを正しく伝えられることことが重要になる」と黒澤氏は言うのである。

HMTL5ではユーザーや環境に合わせて情報・機能を提供される機能が実装されている。その一つとして黒澤氏が紹介したのは「progress要素」だ。ここで黒澤氏はprogress要素を使ったデモを実施。作業の進捗状況をプログレスバーで表示するというものだ。作業開始のボタンを押すと、進捗の領域が緑色に変わっていく。

「これをほかの環境で操作するとどうなるか」と黒澤氏が次に操作したのは、スクリーンリーダーを使った場合。
「progress要素に対応した画面には作業の進捗を音で表現することができる」

進捗音は欽ちゃんの仮装大賞の点数表示に使われるようなコミカルなものだったが、視覚障害者の方でも進捗がわかりやすく伝わると思われた。 「このようにHTML5ではユーザーの環境にあった形でセマンティクスが伝わり、情報がユーザーに正しく伝えられるようになっている。とはいえWebアプリケーションのセマンティクスをHTMLだけで表現するのは難しい」と黒澤氏は言う。

例えばHMTL5はWebアプリケーションのタブやツリーなどのUIコンポーネントや動的なコンテンツのセマンティクス、プルダウンメニューのようにフォーカスの制御が複雑なインターフェースなどはうまく表現できない。
「これらHTML5ではできないことを補足するための技術が、WAI-ARIA（Web Accessibility Initiative-Accessible Rich Internet Applications）である」（黒澤氏）

WAI-ARIAはWebアプリケーションをよりアクセシブルにするW3Cで策定をされた仕様である。ホスト言語と組み合わせ、専用の属性でセマンティクスを表現できる特徴を持っている。そしてHTML5をホスト言語にすると容易に扱える。というのも、「すでにHTML5にWAI-ARIAが取り込まれているので特別に用意することはない」（黒澤氏）からだ。

WAI-ARIAではロール（役割）、ステート（状態）、さらにプロパティ（補足情報）を表現する。ここで黒澤氏はWAI－ARIAのタブモデルを画面で紹介。さらにWAI-ARIAを使えば動的なコンテンツに対してもセマンティクスを指定することができることをデモで証明して見せた。

「WAI-ARIAはあくまでもセマンティクスを表現するもの。見た目はCSS、動作はJavaScriptで指定する」と黒澤氏。
このようにWAI-ARIAを使うことで、ブラウザや支援技術などの機能・制御をユーザーに提供できるようになるのだ。

さまざまなデバイス・環境下でのインタラクション

次は第二のポイント「さまざまなデバイス、環境でのインタラクション」である。ユーザーが利用する入力デバイスも多様化している。1つのデバイスが例えばキーボードやマウス、タッチスクリーン、音声認識というように、複数の入力デバイスを持っていることも多い。「そのインタラクションをHTML5のimput要素を使えば可能になる」と、実際にその記述の仕方をデモとともに紹介した。

例えばスライダーの操作。マウスでもキーボードでも操作でき、タッチスクリーンにも対応するには、HTML5のinput要素を使うと実装できるという。「カスタムUIを実装することもあるだろう」と黒澤氏。その場合はHTML5のDOMイベントのように特定のデバイスに紐づかないイベントを使えば、カスタムUIを実装する手間が少し削減できるそうだ。

クリックイベントとは、マウスクリックのように物理的なものだけでなく、要素が活性化したときに発生するイベントだ。具体的にはa要素やbutton要素などがそれにあたる。要素を活性化する例としては、マウスクリックのほか、キーボードであればフォーカスを当てた上体でEnterキーやスペースキーを押下した場合などである。

「これは今までにあったイベントだが、HTML5ではユーザーの入力を表すイベントが追加された。それがinputイベント。これはユーザーがマウスやキーボード、音声入力などいずれの入力デバイスを使ったとしても入力を活性化することができるイベントだ」（黒澤氏）

実際、どのようなインタラクションになるか、黒澤氏はデモを実施。ただinputイベントには「互換性にまつわる問題がある」と黒澤氏は注意を促す。それは。IE8以下ではサポートされていないからだ。しかし今後は多くの環境でサポートされるはずなので「インタラクションには欠かせないので、覚えておいてほしい」。

グラフィックスとマルチメディアの代替とは

そして最後のポイント「グラフィックスとマルチメディア」。グラフィックスとマルチメディアはリッチな表現でよいが、「あらゆる環境で利用できるわけではない」という。例えば視覚障害者や画像が読み込まれない状況下では、グラフィックス表現だと理解できない。またマルチメディアも、聴覚障害者や音が聞き取れない状況下だと理解はできない。ではどうすればよいのか。「代替となるコンテンツの提供だ」と黒澤氏は代替テキストのデモを見せながら紹介した。

HTML5ではグラフィックの表現にCanvas要素が使えるようになっているが、この要素に対しても代替コンテンツが提供できる。それがフォールバックコンテンツである。フォールバックコンテンツは画面上では非表示となっているが、Canvas要素を無効にすると、フォールバックコンテンツが表示される。もちろんキーボードフォーカスもフォールバックコンテンツに移動するというものだ。

またマルチメディアの代替コンテンツには「字幕とキャプション」がある。「HTML5のtracck要素を使うと簡単に設定できる」と黒澤氏。「WebVTT」というフォーマットファイル（実態はテキストファイル）に、キャプションを表示させる時間や内容を順番に書いていくだけで、文字の位置、大きさ、色などを指定することができるという。

「この機能はブラウザの対応状況によって使えない場合もあるので、注意が必要だ。ただこれも実装されていく方向にあるのは間違いない」そう力強く語り、セッションを締めた。

【講演資料・セッション映像】

昨今のWebアクセシビリティへの取り組み

Webアクセシビリティの確保、すなわちアクセスに用いられるソフトウェアやハードウェアによらず、誰もがWebコンテンツを利用できるようにすることは、関連するJIS規格（JIS X 8341-3）が2004年に公示されてからは特に、理解と普及のための取り組みが積極的に進められてきました。しかし、すべてのWebデザイナーや開発者がそれを当然のことと受け止め、関わるすべてのWebサイトで実践するようになったかと言えば、残念ながら現状そこまでには至っていないでしょう。

それはなぜか？　Webアクセシビリティを確保しようとすると、コンテンツで実現したい表現（特にビジュアルデザイン）や機能が制限を受ける、との誤解が根強く残っているためかもしれません。あるいは、Web関連業務の受発注において、アクセシビリティ対応がいまだオプションとして扱われ、値引き交渉の材料になりやすい（結果として要件から除外されやすい）ような状況が続いているためかもしれません。

はたまた、これまで障害者や高齢者への対応という文脈で語られることが多かったがゆえに、ターゲットとする利用者が障害者や高齢者で無い限り（あるいはコンテンツが極めて公共性の高いもので無い限り）、Webアクセシビリティを考慮する必要は無いなどと認識している人が、いまだに少なくないからかもしれません。

Webは誰でも、どんなデバイスからでも使えてこそ

真相がどうあれ、Webの利用者が右肩上がりで増加し続けているばかりでなく、スマートフォンやタブレット端末の普及に端を発し、アクセス手段の多様化に拍車がかかっている以上、すべてのWebサイトで一定のアクセシビリティが必要なのは明らかです。ここで、Webの創始者であるTim Berners-Lee氏の次の言葉を思い返してみましょう。

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

そう、アクセシビリティこそはWebのもつパワーの根源であり、Webの本質のいち側面。誰もがコンテンツを利用できてこそWebであり、それを担保するのがアクセシビリティである、とも言えます。いわゆる「マルチデバイス時代」を本格的に迎えた今となっては尚のこと、どんなデバイスからでもアクセスできるよう、コンテンツの種類や多寡を問わず、Webアクセシビリティを確保することは重要なのです。

Webアクセシビリティの意義と、今後の執筆予定

私は、従来からある障害者/高齢者対応としての意義に加え、マルチデバイス時代にコンテンツが備えるべき「品質」として、Webアクセシビリティの意義を広く喧伝したい。そして、先に述べたような誤った理解や認識を正し、最終的にはWebデザイナーや開発者の誰もがアクセシビリティの確保に当たり前のこととして取り組むような時代を切り拓きたい。大げさに聞こえるかもしれませんが、そのような目的をもって、今後私はこのHTML5 Experts.jpで不定期に記事を書かせていただこうと思います。

時事的な話題も取り上げるかもしれませんが、当面はW3Cの策定したWebコンテンツのガイドライン、Web Content Accessibility Guidelines (WCAG) 2.0の詳細や、その活用方法について解説していきます。Webアクセシビリティは、厳密にはコンテンツだけで確保できるものではなく、ユーザーエージェントや支援技術側の対応もあってこそ確保できるものですが、私の記事ではあくまでもWebデザイナー/開発者の立場でできることにフォーカスします。そしてまた、WCAG 2.0との協調を果たした2010年版のJIS規格、JIS X 8341-3:2010の使い方についても触れていきます。

html5j アクセシビリティ部のお知らせ

初回としてはだいぶ堅い内容となってしまいましたが、最後にちょっとしたお知らせを。近く、html5jにアクセシビリティ部が立ち上がります。私はその部長補佐として、活動を盛り上げていく予定です。年明け以降になりますが、キックオフミーティングを開催しますので、Webアクセシビリティに興味・関心のある方は、後日のアナウンスを楽しみにお待ちください。