LEMONADE THINGS (@nishino_chekhov)

主に技術関連のレポート、作成資料の配置など

2017/11/22 html5j Webプラットフォーム部 第18回勉強会 レポート(memo)

イベント詳細

html5j-webplat.connpass.com

※動画、スライド掲載あり

ハッシュタグ

#html5jplat

 

 

セッション①

  • なにからはじめたらいいかわからない人のための、これからはじめる『ウェブアクセシビリティ』 (山本和泉)

 

f:id:nishino_chekhov:20171231203822j:plain

 

アクセシビリティとは?

  • アクセシビリティとは「Access+Ability」、つまり「アクセス+できること」
  • ティム・バーナーズ=リー (WWWを作った人)の言葉「誰でもアクセスできるというのはWebに不可欠な特徴である」
  • そもそもコンテンツ以前にアクセスできないとダメ。どうしようもない 

アクセシビリティの公開

  • Yahoo!DoCoMo、Casio、Panasonic、どこの公式サイトにもアクセシビリティについてのページがあり、その内容を公開している
  • 記載されているのは、例えば構造と表示スタイルについて。ページ冒頭に見出しをつけていますとか、文字サイズは必要に応じて閲覧者が変更できるようにしているとか(メタタグとかで固定させているサイトもあるけど、それはユーザが変更できなくなっちゃうから、アクセシブルじゃないよね)
  • ほかにも、キーボード操作だけで閲覧できるようにしていることとか、音や映像が勝手に再生されないようにしている、なんてことも載っている
  • 色弱などのハンディキャップのある方でも閲覧できるようにすることがWebにとって必要なこと 。サイトというサービスの評価をもらう上で不可欠

これだけはおさえろ!ウェブアクセシビリティ10

  • 1)ページの内容がわかるページタイトルをつける(<title>タグ)
  • 2)見出しやリストなど文章構造をマークアップする
  • 3)構造をセクショニングする
  • 4)リンクテキストはリンク先がわかる文言にする
  • 5)情報を伝えている画像に代替テキストを入れる
  • 6)文字色と背景色のコントラストを確保する
  • 7)キーボードだけでも操作できるようにする
  • 8)音声や映像を自動再生させない
  • 9)再生ボタンとストップボタンをつける
  • 10)見た目はCSSで調整する 

読むべき書籍・サイト、フォローすべきアカウント

 

 

セッション②

  • 多様なユーザーニーズに応えるフロントエンドデザインパターン〜エッセンス編(freee 株式会社 伊原力也)

f:id:nishino_chekhov:20171231212036j:plain

 

”オレンジ本”について

  • 「インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン」(通称”オレンジ本”)の監訳を担当
  • アクセシブルの話って、「これはやっちゃだめ」って話が多い。この本は「こう実装するとアクセシブルだよ」という話をメインで載せている
  • 今日はそのエッセンスとして、入力フォームをテーマとして取り上げる。

入力フォームのアクセシビリティ

  • ウェブをインタラクティブにしているのはリンクとフォーム
  • フォームは「入力欄とラベル」「エラー表示」の二つで構成される。今日のテーマはこの二つ

入力欄とラベルのポイント

  • 1)入力項目とラベルを明示的に関連付ける
  • 2)見た目でも入力項目とラベルの対応を明確に
  • 3)何が起きるか明白なラベルにする
  • 4)プレースホルダをラベル代わりにしない
  • 5)必須と任意を明示する
  • 6)入力条件は先に提示する

ポイントピックアップ「1)入力項目とラベルを明示的に関連付ける」

  • まず、ラベルがないとその項目が何かわからない。じゃあ、関連付けってなんでしょう?
  • それは、<label for = "password">パスワード</label>のように、ラベル側はfor=で属性とし、入力側は<input id ="password">として紐付けるということ
  • そうすると、スクリーンリーダーというソフトのユーザーが助かる
  • 先の例では、パスワードの入力欄にカーソルがフォーカスしたときに、その属性を読み上げ文の中に入れて読んでくれる(「パスワードエディット、保護つき」などのように) 。これがないと、ラベルにはフォーカスしないので何の入力欄か知りようがなくなる
  • じゃあラベルが読めない場合だけのために設定するのか?そうではない。関連付けられていると、ラベルをクリックした際に対応するテキストボックスにカーソルがフォーカスしてくれたりする。ブラウザの機能で。そういう利点もある

その他のポイント抜粋(2~6)

  • プレースホルダ(注:[メールアドレス]のようなイメージで、カーソルをあてる前に、入力欄の中に項目名称を表示させておく手法。カーソルをあてると消える)をラベル代わりに使うサイトが多いが、これは避けるべき。カーソルをあてると何の項目かわからなくなるので、じわじわといらいらしてくる
  • 必須項目の表現に「*」を表示する例はよくあるが、普通に「必須」と書いたほうがアクセシビリティは向上するだろう。

エラー表示のアクセシビリティ

  • 1)エラーはフォーム内に出す
  • 2)エラー状態が伝わるようにする
  • 3)エラー個所を明確にする
  • 4)エラーの修正を助けるメッセージを出す
  • 5)リアルタイム検証は慎重に使う

1~5のポイント抜粋

  • 1)エラーが別画面に出て、戻るとエラー内容が書いていない。という仕様だと内容を覚えておかなきゃならないので困る
  • 2)Submitした後進まないけど、エラーだということに気づけない。上のほうにスクロールすると書いてあってわかるとか、そういうのは困る。触っていた場所のそば(送信ボタンの直上など)に出すべき。エラー個所に勝手に移動するようなデザインについては、わかりづらいとしてこの本(オレンジ本)の著者は非推奨としている
  • 3)および4)「赤色の箇所のみ変更してください」赤が見えない人もいる。「不正な入力です」どうすればいいのか。よい例は「パスワードは6文字以上で入力してください」など
  • 5)入力しながらチェックするような作りだと、入力中に正の条件を満たすまでずっとエラーだと表示されていたりする。「わかってるよ」となってしまう可能性もあるので、ケースバイケースだと理解しよう

 

総評

  •  アクセシビリティについて全く予備知識なく参加したのですが、普段の業務アプリケーション開発の中では意識しない非常に細部の使い勝手向上について話が聞けて、大変勉強になりました
  • アクセシビリティをやるためにサイバーエージェントに転職した人の話なんかも例に出されていて、そのスキルで結構食えるというのはなかなか興味深い。縁の下の力持ち的な開発を好む人にも活躍の舞台があるってのはいいよね
  • 本文では省略しましたが、アクセシビリティをやることで「ハンディキャップのない一般人にとってもわかりやすいサイトになる」「広く開かれたWebの世界で売り上げ向上などの利益つながる効果もある」といった利点についても触れられました。つまり、利益追求に対する純粋な活動の一環である、というメッセージを受け取れた(それこそが開発において最も健全な動機であると思います)のもよかったです

 

全く知らない分野について知ることで、また一歩総合力が身についた実感があります。運営、登壇者の皆さまありがとうございました。