CodeIQ MAGAZINECodeIQ MAGAZINE

これからのWebクリエイターに欠かせないスキル─アクセシビリティ・インクルーシブデザイン講座

2017.12.26 Category:勉強会・イベント Tag: , , , ,

  • 41
  • このエントリーをはてなブックマークに追加

一人でも多くの人にサービスを届けたい。そういう思いを抱いているエンジニアやデザイナーは多い。それを実現するための方法論がアクセシビリティとインクルーシブデザインだ。
11月22日に開催された「html5j Webプラットフォーム部 第18回勉強会」では、デザイナーと開発者のための「アクセシビリティ」と「インクルーシブデザイン」について語られた。
by 馬場美由紀 (CodeIQ中の人)

Webアクセシビリティは難しいモノではない

スマートフォンをはじめとするモバイルデバイスの普及により、子どもから高齢者まで、障がいのあるなしに関わらず、多くの人がWebを利用する時代が到来している。

欧米では電子機器や電子文書について、障がいを持った人でも使用できるような法律が整備されているが、日本ではまだまだその点で遅れており、誰もが使いやすいサービスやアプリが作られているとは言いがたい。

そこで「html5j Webプラットフォーム部 第18回勉強会」では、アクセシビリティとインクルーシブデザインをテーマに開催。誰もが使いやすいサービスやアプリを開発するための方法論が紹介された。

最初に登壇したのは、フリーランスのウェブデザイナー山本和泉さん。現在はデザイナーとしての活動よりも、中小零細企業のウェブサイトのコンサルティングや運用のアドバイザーとして活躍している。また、彼女が参画しているアクセシビリティの情報サイトAccSell(アクセル)では、アクセシビリティビギナーの案内役を担っている。

山本和泉さんウェブデザイナー/アドバイザー/トレーナー アクセシビリティゆるふわ部 山本和泉さん

今回の山本さんのセッションテーマは「なにからはじめたらいいかわからない人のための、これからはじめる『ウェブアクセシビリティ』」。

3年前の2014年12月4日に「アクセシビリティやるぞ!祭り」が開催されたとき、集まった人数は70人。それが今年11月11日に開催された「Japan Accessibility Conference」では、その3倍の230名が集まった。今、アクセシビリティは非常に勢いのある話題である。

アクセシビリティというと障がい者や高齢者対応と思われがちだが、アクセシビリティとは「Access(アクセス)+Ability(できること)」。つまり「できない・しづらい」から「できる・しやすい」状態へ持っていくことである。

WWWを作ったティム・バーナーズ=リーの言葉を引用すると、「障がいがあるか否かに関わらず、誰でもアクセスできることがWebにとって不可欠な特徴」なのである。

情報を受け取るのは人だけではない。今やWebの情報を取得するデバイスもどんどん増えている。スマートスピーカーもあればスマートウォッチ、冷蔵庫のような家電製品も含まれる。

人だけではなく、さまざまなデバイス、マーシンでも情報を読めるようにしておくこと、つまりマシーンリーダブルであることも重要になっている。

多くの企業がアクセシビリティの方針や試験結果を公開

現在、官公庁をはじめ多くの企業がWebアクセシビリティの方針や試験結果を公開している。

例えば中日新聞のアクセシビリティ方針についてのページでは、構造と表示スタイル、文字サイズと文章の読みやすさ、操作と入力、音・映像について掲載されている。

「文書構造に合わせてマークアップをする」「見た目はCSSを使って行間や背景色と文字色のコントラスト比をしっかりとる」など、Webページを作成するときの基本が中心。その他「文字サイズはユーザー側で変更できるようにする」「マウスだけでなくキーボード操作もできるようにする」など、ユーザー側の操作についてや、「動画コンテンツなどはページを開いたときに自動再生しない」などのコントロール方法についてだ。

このようにWebアクセシビリティは難しいと思われがちだが、どの内容もWeb制作の基本が中心で、意外と簡単に着手しやすそうだということがわかるだろう。

これらの例はあくまでも中日新聞のアクセシビリティの方針の例だが、その他の企業や自治体の多くで同じような内容を公開している。

アクセシビリティで意識すべきこと

それ以外に意識してほしいことがいくつかある。第一はテキストリンクの文言だ。

詳細はこちらをご覧ください」というように「こちら」をクリックさせるようなテキストリンクが多いが、クリックした先がどこなのかが分からず(PDFファイルが開いてしまうこともあるかもしれない)、ユーザーは不安でクリックしづらいだろう。

そうではなく「みょうが栽培をご覧ください」というように、クリックする先の内容を文言で明らかにするのである。そうするとSEO的にも良いため、アクセス数、ページビュー数、サイト滞在時間も伸びるポイントにもなる。

第二はコントラスト比である。例えば薄い背景色に薄い文字色だと文字が読みづらく(コントラスト比が低く)アクセシブルではない。Web Content Accessibility Guidelines(WCAG)2.0ではコントラスト比は「4.5:1以上」と設定されている。コントラストチェッカーはさまざまなツールが出ているのでぜひチェックしてほしい。

コントラスト比画面

第三はテキスト。そもそもテキストはWebの基本。よりアクセシブルにするにはテキストが重要になる。文字は画像ではなくテキストで対応することで、多言語対応も容易にできるからだ。これもアクセシビリティの向上である。

小田原市のサイトでは、テキストでの多言語対応だけでなく、ソフトバンクテクノロジー社のWebフォントサービス「フォントプラス」を使っていることで、デザイン性もより良くなっている。

とはいえ、Webサイトでは画像で伝えないといけない場面もある。対応として欠かせないのが、画像にalt(alternative text:代替テキスト)を付けることである。

スクリーンリーダー(パソコンやスマホの画面を機械の音声で読み上げるソフトウェア)を使用したとき、画像の部分はalt指定したテキストが読み上げられる。また、ブラウザーで画像が非表示の場合、画像部分にalt指定したテキストが表示される。

ただし、その入れ方にも注意が必要だ。例えば下の画像のような、チョコレートケーキという見出しの下にチョコレートケーキ画像があり、その下に「厳選チョコを使用したほろ苦いオトナのチョコケーキです」という説明文が書かれている構成だったとする。

ハート型のチョコレートケーキ写真

その場合、次のようなaltが付けられることがよくある。

①alt=””
②alt=”チョコレートケーキ”
③alt=”画像”

これらはいずれも不適切である。たとえばスクリーンリーダーを使用したとき、

①の場合:画像自体の存在が読み上げられない。

②の場合:「チョコレートケーキ チョコレートケーキ 厳選チョコを使用したほろ苦いオトナのチョコケーキです」と、チョコレートケーキを2回読み上げてしまう。

③の場合:「チョコレートケーキ 画像 厳選チョコを使用したほろ苦いオトナのチョコケーキです」と読まれてしまい、画像がイラストなのか写真なのか、そしてどんなチョコレートケーキなのかがわからない。

とこのような具合だ。

しかし「写真:ハート型をしています」というaltをつけると、スクリーンリーダーを使用していても、ブラウザーで画像が非表示であっても「ハート型のチョコケーキの写真が掲載されている」と理解できる。

ハート型のチョコレートケーキ写真と解説

アクセシビリティは品質保証

アクセシビリティについてどうやって勉強すればよいのか。まず山本さんがお勧めしたのは、最後のセッションに登壇した伊原力也さんと太田良典さんが書かれた「デザイニングWebアクセシビリティ」という書籍を読むこと。

次に、WCAG 2.0をチェックすること。ただこのガイドラインは読みづらいことが多く、このガイドラインの読み方を解説した太田さんともんどさんのスライドを読むことをお勧めする。

そのほかにも「WCAGもくもく会」などアクセシビリティ関連の勉強会に参加する手もある。

注意したいのはアクセシビリティを一人でやると沼にはまりやすいので、一人で悩まないことだ。アクセシビリティ関連の勉強会も増えているし、TwitterなどSNSでもアクセシビリティ関連の情報交換が盛んに行われている。そういったところを普段からチェックすることもポイントだ。

また、メルマガとポッドキャストでお送りするアクセシビリティーの情報サイト「AccSell」もある。このAccSellでは2018年2月24日(土)にミートアップの開催を予定している。同会では、ロービジョン(弱視)の方とスクリーンリーダーを利用している全盲の方のユーザーテストについて紹介する予定だ。

アクセシビリティは人や機械に情報を正しくアクセスしてもらうためだけではなく、アクセシビリティは品質保証。Webサイト自体をよりアクセシブルにし、品質を向上させることで企業のイメージアップにもつながる。

アクセシビリティに強くなると、他社との差別化ができるため、案件数も増える。またエンジニアやデザイナーとしてアクセシビリティのスキルを身につけておくと、キャリアパスに非常に有利に働く。「今やらない理由はない、ぜひ、このビッグウェーブに乗っていきましょう」と山本さんは力強く訴えた。

インクルーシブデザインが求められる理由

続いて登壇したのは、日本マイクロソフトの物江修さん。テーマは「マイクロソフトのInclusive Design」。

物江修さん
日本マイクロソフト パートナー事業本部 パートナー事業統括本部テクニカルエバンジェリズム本部 物江修さん

Inclusive Design(インクルーシブデザイン:包括的デザイン)とは、さまざまな製品やサービスから排除(Exclude)されていた人々を、企画・開発の初期段階から巻き込んで一緒に考えていくデザインの方法である。2014年頃から言われ出したが、最近になって注目されるようになった。

ではなぜインクルーシブデザインが必要なのか。現在、地球上には74億の人間がいるが、そのうち15%は何らかの障がいを持っている。その数1億人。その1億人がサービスから置き去りにされているということが第一に挙げられる。

次にグローバル化。国連世界観光機関の発表によると、昨年1年間に海外旅行した人は12億3500万人だという。12億もの人が、母国ではない国や地域を訪れているのである。

もちろん、日本にも多くの外国人が訪れている。厚生労働省の調査によると、日本で働いている外国人の数は108万人(2016年10月現在)。

この数字は届け出を義務化して以来最高で、年々増え続けている。さらに留学生や海外旅行者を含めると、国内には日本語がわからない人がたくさんいるということ。

第三は超高齢化問題。高齢化はいずれの先進国でも問題になっているが、日本は特に深刻だ。内閣府の調査「平成29年版高齢化社会白書」によると、人口の27.3%が65歳以上となっており、女性だけに限ると30.1%である。

あと数年で3人に1人が65歳以上という社会になるのはほぼ確実になってきている。歳を取ると細かい文字が見えないし、複雑なことも覚えられない。つまり、そういう高齢者にもやさしいデザインが必要になるということだ。

第四に法律の施行。欧米では電子デバイスや電子文書に障がいを持った人もきちっとアクセスできないといけないという決まりがある。そのため輸出をする、メーカーは対応している。

だが、間違ってはいけないのは、インクルーシブデザインはこれらのガイドラインを満たすためのものではない。インクルーシブデザインは対象となる全ての人に最適な結果をもたらすことである。

勉強会の会場風景

インクルーシブデザインで考慮すべきこと

インクルーシブデザインをする際に考慮すべきことは次の3点となる。

  • 誰のためにデザインするのか
  • 誰がexcludedされているか。
  • それが重要な理由

これらを考慮することで、作ったモノをより多くの人たちに届けることができる。製品のデザインがユーザーの社会参加を除外しないよう取り組むことは開発者にとっての責任であり、また大きなイノベーションを生み出すきっかけとなる可能性もある。

インクルーシブデザインの原則について説明する。まずインクルーシブデザインは除外/対象外を理解することから始まる。障がい者の定義も変わっている。

WHO(世界保健機関)によると、1980年は個人属性としての障がい、つまり肉体的ハンディキャップを障がいと呼んでいた。制限に対する理解が深まった今、WHOは「障がいは単に健康上の問題ではない。これは複雑な現象であり、人の身体の特徴と彼または彼女が住んでいる社会の特徴との相互作用を反映している」というように、状況に応じた障がいがあるとしている。

インクルーシブデザイン(障がいについて)

私たちが何か製品を作ると、ユーザーと社会に対して相互作用が発生する。その相互作用のミスマッチがどう発生しているかをきちんと把握することが大事になるということだ。

例えば腕や足を折った人は、足や手が使えない人と同じで、海外に行って言葉が通じない所に行った場合は、耳の聞こえない人と同じハンディキャップを負う。

つまりハンディキャップは健康、肉体的なものだけでなく、状況によっても発生する。除外は肉体的ハンディキャップを持った人だけではない。そこにヒントがある。除外を理解することでいろんな人のための製品が作れることになる。

次に共感と多様性から学ぶこと。具体的には、目の見えない人について研究するのに、目隠しや耳栓で異なる能力をシミュレートするだけで頼るのは間違いである。

インクルーシブデザインイメージ(共感から学ぶ)

実際にそういった人たちがどのように自分たちの周りの生活に対応しているかを観察することが大事になる。人間は多様性に柔軟に適応する達人である。

よく提供する製品のエクスペリエンスが十分ではなかった場合、ユーザーはデザインをした人間が思いもしない使い方をすることがある。つまり適応からヒントを得るのである。

さらに肝となるのが、多くの人たちに有効なモノを開発することである。インクルーシブデザインは同様の状況下で、異なる人々に関連する能力のスペクトル(ペルソナスペクトル)に作用する。

テキストのキャプション(字幕)が生まれたのは、難聴のコミュニティの人のためだった。いまや字幕は騒がしいところでキャプションとして使われたり、こどもに読み方を教えることにも使われている。

また片腕の人の課題を解決するインクルーシブデザインは腕の怪我した人にも、子どもを抱いている人の課題も解決する。

永続的な障がいから状況的な障がいへの連続性を考えることで、より多くの人に役立つことを発見できるのである。それだけではない。今までサービスの対象とならない人たちがサービスの対象となるため、売上にもつなげることができる。

マイクロフトでもインクルーシブデザインに注力している。当社の原則は次の3つ。第一はexcluded(除外/対象外/排除)を認識すること。第二に多様性から学ぶこと。第三は一つの問題を解決し、多方面に拡張することだ。

マイクロソフトでは、インクルーシブデザインのためのサイトを立ち上げ、インクルーシブデザインを実践するためのツールキットを提供していることである。

同サイトではまずはマニュアルとアクティビティカード、ビデオを提供している。マニュアルはPDFで提供されている。どんなふうにインクルーシブデザインを考えていくべきか、かなり詳しく書かれている。

マイクロソフト インクルーシブデザインのためのサイト

現在は英語のみでの提供だが、日本語化も進めている。アクティビティカードもPDFでダウンロードが可能だ。除外を認識することで、プロセスに使えるツールとなっている。

インクルーシブデザインを考える上で、大事なのは除外を意識すること。障がいを持った方々のビデオが閲覧できるようになっており、除外について考えさせられる内容だ。

またマイクロソフトはアクセシビリティにも力を入れている。アクセシビリティガイドでは、マイクロソフト製品のアクセシビリティ機能を使用して、お客さま固有のニーズを満たすための情報とヒントを見つけられるような情報を提供している。

マイクロソフト アクセシビリティガイドイメージ

例えば、Windowsが搭載しているアクセシビリティの機能を紹介しているのもその一例だ。またマイクロソフトの製品が、法律をどのようにクリアしたか、製品の仕様なども紹介されている。

社内では、製品を出すときにMicrosoft Accessibility Standards(MAS)という基準をクリアしないとリリースできない。米マイクロソフト(本社)ではアクセシビリティのオンライントレーニングは必須となっている。インクルーシブデザインを実行するため、障がいを持った人たちを採用し、製品開発に取り組んでいる。

最後に「インクルーシブデザインはこの星のすべての人たちために行うこと。インクルーシブデザインを考えることで、イノベーションのヒントが得られるかもしれない。ぜひ、インクルーシブデザインに取り組んでほしい」と、物江さんは聴衆に熱く訴えた。

入力フォームのアクセシビリティのポイント

最後に登壇したのは、クラウド会計ソフトや人事労務ソフトを開発しているITベンチャーfreeeの伊原力也さん。

現在は情報設計とUXデザインを担当。社外活動としてはHCD-Net評議委員、ウェブアクセシビリティ基盤委員会の委員、国際ユニヴァーサルデザイン協議会 移動空間研究部会では副主査を務めるなど、アクセシビリティに関して発信している。

freee 株式会社 伊原力也さんfreee 株式会社 伊原力也さん

今回のセッションテーマは「多様なユーザーニーズに応えるフロントエンドデザインパターン~エッセンス編~」。

伊原さんと太田さんによる書籍「デザイニングWebアクセシビリティ」「コーディングWebアクセシビリティ」、翻訳本「インクルーシブHTML+CSS&JavaScript」で紹介されている、フォームのアクセシビリティに関する話が中心に語られた。

なぜ、フォームのアクセシビリティなのか。それはWebをインタラクティブにしているのは、リンクとフォームだからだ。中でもフォームは送信完了までの行程がすべてアクセシブルでないと、やりたいことにたどり着けたとはいえない。

フォームといえば、入力欄とラベル、エラー表示で構成されている。まず入力欄とラベルのポイントは6つある。

ポイント1:入力項目とラベルを明示的に関連付ける

例えばユーザー名とパスワードの入力欄を用意したとしよう。入力欄にラベルがないと、何の入力欄かわからない。だから明示的に関連付けることが必要になる。

<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>

なぜ関連付けが必要か。例えば先の例だと、スクリーンリーダーユーザーがパスワードフィールドにフォーカスを合わせると、「パスワードエディット、保護付き」というように読み上げることができるからだ。

もう一つ、スクリーンリーダーユーザーにとって重要になるのが、フォーム内をどのように移動するか。制作側がそれを理解することも求められる。散文的なコンテンツではユーザーは下矢印を使って要素間を移動するが、フォームではあるフィールドから次のフィールドへtabキーで直接移動する操作が行われる。

このとき、ラベル要素は飛び越されてしまう。つまりラベル要素とインタラクティブ要素が明示的に関連付けられていないと、そのラベルは見逃されてしまうことになる。フォームコントロールに関連付けられていないとラベルの存在そのものに気がつかない。

ポイント2:見た目でも入力項目とラベルの対応を明確に

見た目でも入力項目とラベルの対応を明確にする必要がある。入力項目は縦1列に並べた方がわかりやすい。

また、例えばよくショッピングサイトなどで並び替えるための項目欄「新着順 人気順 価格の安い順 価格の高い順 並べ変える」を作る場合にもlabelを応用できる。

ラベル応用例の画面イメージ

まず択一選択なので、次のようにラジオボタン+labelにする。

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

次に隣接セレクタで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);
}

ポイント3:何が起きるか明白なラベルにする

「メールマガジンを受け取らない」というラベルではなく、「メールマガジンを受け取る」というラベルにすることだ。また「やってみよう!」というような替わった言い回しを使うのではなく、単純に「送信」というラベルにする。

ラベル応用例 送信ボタンイメージ

サイトの雰囲気に沿ってNG例のようなことをしがちだが、これはやめた方がよい。

ポイント4:プレースホルダをラベル代わりにしないこと

スペースを節約するためにプレースホルダをラベル代わりにしがちだが、文字を打ち始めた瞬間にラベルが消えてしまう。そのため、ユーザーはそのフォームが何を入力する項目か覚えておかねばならず、認知負荷が高まる。

また、プレースホルダをサポートしないスクリーンリーダーやブラウザだと情報が失われて意味不明になる。

さらにブラウザのオートコンプリート機能で複数のフィールドが一気に埋められた際、適切に入っているか確認できないということもNGな理由として挙げられる。

入力を開始すると、ラベルの位置を動かして上に表示されるようにするなど、ラベルが常に表示され続けるようにしたい。

本当にプレースホルダとして使う場合も、文字色には注意しよう。弱視の方はコントラスト低いモノは見えないからだ。文字色を濃くしつつ、スタイルを変えるというアプローチを検討したい。

文字を濃くしつつ、スタイルを変えるコード例

::placeholder {
    color: #000;
    font-style: italic;
}
::-webkit-input-placeholder {
    color: #000;
    font-style: italic;
}
::-moz-placeholder {
    color: #000;
    font-style: italic;
}
::-ms-input-placeholder {
    color: #000;
    font-style: italic;
}

ポイント5:必須と任意を明示する

必須項目には必ず、「必須」というマークをつけること。次のように赤いアスタリスクなどで間に合わせているWebサイトをよく見かける。

<label for="email">メールアドレス <strong class="red">*</strong></label>
<input type="text" id="email" name="email">


この場合も、スクリーンリーダーに必須が伝わるよう、aria-requied=”true”を使うなどで対応にする。

<label for="email">メールアドレス <strong class="red" aria-hidden="true">*</strong></label>
<input type="text" id="email" name="email" aria-required="true">

さらに、アスタリスクを「必須」などの文字列に置き換えると、誰にとっても必須であることがわかりやすくなる。

ポイント6:入力条件は先に提示する

例えばパスワードを入力し、次へをクリックしてはじめて、「パスワードは8文字以上、半角英数大文字を含めてください」という入力条件が提示されることがある。こういったやりかたはユーザーにとってストレスが大きく、避けるべきだ。

これに対しては、入力フォームにその条件を提示する、もしくはフォーカスが移ったときにツールチップ的に出すようにするというアプローチが考えられる。適切に実装すれば、ツールチップ的に出しても、スクリーンリーダーでも読み上げることができる。

書き方は次の通り。

<form>
<fieldset>
<legend>ログインフォーム</legend>
<div>
<label for="username">ユーザー名</label>
<input id="username" type="text" aria-describedby="username-hint">
<div role="tooltip" id="username-hint">ユーザー名には、あなたのEメールアドレスを登録してください</div>
</div>
<div>
<label for="password">パスワード</label>
<input id="password" type="password" aria-describedby="password-hint">
<div role="tooltip" id="password-hint">メールでお送りしたパスワードを入れてください</div>
</div>
</fieldset>
<button type="submit">サイトに入る</button>
</form>

フォーカス時にツールチップを出すCSSは次のように書く。

[role="tooltip"] {
    background: orange;
    color: white;
    padding: 0.25em;
    display: none;
}
input:focus + [role="tooltip"] {
    display: block;
}

+αのポイント:フォーカスインジケーターを消さない。

最後のポイントは、フォーカスインジケーターは消さないこと。ブラウザがタブキーを押したとき、インタラクティブな要素に対してフォーカスが出るが、フォーカスインジケーターを消してしまうとどこにフォーカスがあるかわからず、操作ができなくなるからだ。

これらのポイントを守るとアクセシブルになり、誰もが使いやすいものになる。

エラー表示のアクセシビリティのポイント

エラー表示にも様々なアクセシビリティのポイントがある。次はエラー表示に関する5つのポイントについて説明しよう。

ポイント1:エラーはフォーム内に出すこと

たまに見かけるエラーだけ書かれたメッセージが別に表示されるパターン。どこがエラーか覚えて戻って直さなければいけないので大変不便である。エラー表示はフォーム内に表示させよう。さらに戻ったパスワードが空欄になってしまと2回入力しなくてはいけなくなるため、その点も留意する必要がある。

フォーム内に表示されないエラー画面

ポイント2:エラー状態を伝わるようにする

以下のようなエラー状態がわからない画面も不親切だ。

エラー状態がわからない画面

例えば登録情報が間違っている場合は、「登録する」ボタンの上に、「登録情報が正しいことを確認してください」というテキストを大きく出すと良い。

正しい登録情報を促す画面

具体的なコードは次の通り。

送信を止め、送信ボタンの上にエラーを出す例

<div id="error" aria-live="assertive" role="alert"></div>
<button type="submit">登録する</button>
#error:empty {display: none;}
var form = document.getElementById('register');
form.addEventListener('submit', function(event) {
if (errors) {
event.preventDefault(); // 送信させない
document.getElementById('error').textContent = '登録情報が正しいことを確認してください。'
}
});

このように書くことで、スクリーンリーダーにも確実にエラーがあることが伝わる。アイコン画像とaria-labelでエラーを明白にする場合は、次のように書く。

アイコン画像とaria-labelでエラーをより明白に

<div id="error" aria-live="assertive" role="alert">
<p>
<svg role="img" aria-label="エラー:">
<use xlink:href="#error"></use>
</svg>
登録情報が正しいことを確認してください。
</p>
</div>

ライブリージョンでエラーの存在を宣言するメリットは、スクリーンリーダーユーザーがエラー箇所に移動せずとも、その場でエラー情報の注意を促せる点だ。

エラーになっている入力欄にフォーカスを移すことで、フォームエラーをユーザーに警告する方法もよく見られるが、これはかえってユーザーを混乱させる恐れがある。

●ポイント3:エラー箇所を明確にする

よく見かけるのが、エラー箇所を赤で表示させるケース。男性の5%は赤色の認識ができない。つまりそういう人だと、赤色で明示されても修正できないからだ。

エラー箇所を赤で表示させた画面例

ポイント4:エラーの修正を助けるメッセージを出す

例えば「不正な入力です」と言われても何が不正なのかわからない。

「不正な入力です」と表示された画面

このポイント3、4の改善方法は、以下のように「パスワードは6文字以上にしてください」といった具体的なエラー修正を助けるメッセージを提示するとよい。

●ポイント5:リアルタイム検証は慎重に使う

リアルタイム検証の有効性は状況にもよる。例えば、便利な使い方の代表例はTwitter。残り入力文字数を適切なタイミングで教えてくれるのは便利である。

問題ありなのは、メールアドレスの入力中にその都度、妥当性をチェックするタイプ。リアルタイム検証は便利だが、入力している間もチェックされると、最後の入力が終わるまで常にエラーだと言われ続けられることになる。

ライブリージョンのエラーメッセージが繰り返し更新される実装になっている場合、スクリーンリーダーは80年代のリミックスモードに入る。「パ・パ・パス・パスワ・パスワードは6文字以上にしてください」などと読み上げられることになるため、ユーザーはミスにつながりやすくなる。

この対応策としては次の3つ。

  • 第一はキーストロークがあいたら発動するよう制御すること
  • 第二はそもそもリアルタイム検証が必要か再考すること
  • 第三は必要な場合でも、送信時エラー後にリアルタイム検証を発動させるようにすること

フォームがアクセシブルになると、多くの人のユーザビリティも向上する。フォームにおいては特に如実にこの効果が実感できる。つまり、アクセシビリティを改善することは、コンバージョンレートを上げ、売上につなげることができるのだ。

アクセシブルになると、Webをインタラクティブに使える人が増える。サイトの集合体としてWebでやり取りをする人が一人でも増えることは重要だし、Webの発展にも欠かせない。アクセシビリティを理解していると、エンジニアとしての価値も高まる。

誰もが使いやすいモノを作る。こう書くと当たり前のことだが、本当にそれができているものはまだまだ少ない。特にWebに関して言えば、今はまだ黎明期とも言えるだろう。

いち早くアクセシビリティやインクルーシブデザインに関する知識を身に付け、それを意識したWebサービスやアプリづくりをする。そうすることが、社会に貢献する新たなイノベーションを生み出す一歩となりそうだ。

今回の勉強会は動画でも公開されているので、もっと詳しく知りたい人はチェックしてみよう。

⇒html5j Webプラットフォーム部が主催する「Webをプラットフォームとする技術」に関する勉強会情報はこちらをチェックしよう!

  • 41
  • このエントリーをはてなブックマークに追加

■関連記事

【鹿児島の熱量を感じろ!】モバイルの未来は地方こそ主役「MOBILE CONFERENCE 2017... エンジニア・デザイナーのためのカンファレンスが鹿児島で開催 ウェブやモバイルのエンジニア・デザイナーのためのカンファレンス「MOBILE CONFERENCE 2017」。鹿児島キャリアデザイン専門学校マルチホールを会場に開催された。 この日はあいにくの雨天にも関わらず、会場はウェブ・モバイ...
Alex Kipman氏も注目した日本のHoloLens盛況――日本上陸3か月記念「HoloLens... HoloLens販売国の中で突出した盛り上がりを見せる日本 日本マイクロソフトの製品担当メンバーが企画した、日本上陸3か月記念「HoloLens大感謝祭」。3月に開催したCodeIQ感謝祭にブース出展していただいたことを縁に、リクルートキャリアを会場としてイベントが開催された。 さすがは、H...
Webで簡単・効率的にアニメーションを実現できる最新フレームワーク・CSS3アニメーションを紹介... MozillaでWebアニメーションの機能の開発者が登壇 Webでアニメーションというと、数年前まではFlashコンテンツが当たり前に使われていた。 しかしスマートフォンの普及と共に、Webから駆逐され、今はHTML5でアニメーションを表すには、setInterval関数やrequestAnim...
澤円&ちょまどのまどか☆まどかスペシャル対談! ─自分で創る「エンジニアのキャリア」とは... 澤さん、ちょまどさんの相違点とは? 澤:僕、こう見えてもサラリーマンで、ミュージシャンではありません(笑)。 エンジニアとしてのキャリアはCOBOLのプログラマとしてスタートしました。ちょうどWindows3.1が出るか出ないかの頃ですね。 現在はマイクロソフトテクノロジーセンターのセンター長と...
Microsoft HoloLensが実現するMixed Realityの世界とは?─エバンジェリス... Mixed Realityはフィジカルとバーチャルの情報を重ね合わせたもの Mixed Reality(ミックスドリアリティ/MR)は、Virtual Reality(バーチャルリアリティ/VR)やAugmented reality(AR)と何がどう違うのか。 まずはフィジカルリアリティ。これは...
【CodeIQ感謝祭】落合陽一さん・伊藤直也さん・澤円さん&ちょまどさん・高橋忍さんが登壇!――聞い... 今回は豪華ゲストに加え、VR/MRが体験できるブースも 2017年3月11日に開催したCodeIQ感謝祭は、豪華ゲストに加え、VR/MRが体験できるブースも開設。300人以上の方にご参加いただき、大いに盛り上がりました。 今回も司会はきゃんちこと、CodeIQ MAGAZINEの公式アイドルレポ...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ