アクセシビリティの最近のブログ記事

メディア系サイトのページ送りナビゲーション

地下鉄でiPhoneで読んでたんだ。記事自体は面白かったんだ。

でもすごくストレス感じた。だって駅に着いたときしか電波通じないわけです。つながった時にリンククリックしてページダウンロードして、駅間の移動中に読むわけです。

ところがところが、ページが無駄に分割されているのです。ダウンロードした1ページを読んだら、次のページへ移動しなきゃならない。ところがつながらないのです。次の駅まで。結果、7駅移動しなきゃ最後まで読めないんですよ1つの記事が。

そうなんだよ。ナローバンド環境でこそアクセシビリティ大切なんです。

先日のリクリ関西のセミナーでもしつこいくらい強調したけど、みんなレイアウトのことだけ考えてて速度のことを考慮してないんじゃないか?

グーグルが検索結果での順位付けの要因としてページ表示速度を考慮するようになったとはいえ、その影響は微少だと言われています。それでも、やはりユーザーのことを考えるとページ表示は快適なほうがいいですよね。

そこで、Webページ制作を依頼するときに、RFP(提案依頼書)や仕様として、ページ表示のパフォーマンスを含めるようにしませんか?

以下のエントリーなんかも参考にしよう。

私は Media Queries に関する技術的な欠陥を指摘するつもりです。欠陥のほとんどは、モバイルにおいてスピードはより重要であるという私の信念に基づくものです。

デスクトップ上でなら、より遅いウェブページを許容すると言っているわけではありません。モバイルはより多くの状況で使用される可能性があるということです。アクセス速度がより重要であったり(急いで仕事探している)、速度が最適化されない環境(回線速度、デバイスの処理能力)といった場面です。

モバイル向けのデザインをするとき、パフォーマンスは重要な考慮事項です。

メディア系のサイトがページ分割しているのは媒体資料としてトラフィックを多く見せるためだろうけど(決して容量の問題ではないはず)、広告や関連記事へのリンクよりも「今俺はコンテンツを読みたいんだ」

ナローバンドは考えなくていい? なくなる? いや、なくならない。今までつながらなかった場所がつながるようになるわけだから、過渡期とはいえ一時的に回線が遅いシーンってのは増えていきます。ビルの高層階でのWiFi、iモード通信、新幹線N700系の無線LAN(←こいつは最近殆ど使いものにならん)...

ということで、もう一度貼っておきます。レイアウトだけ考えてても駄目だと思うよ。

追記:インターネットなんだから、日本だけの事情を考えていればいいってこともない。この視点も忘れないようにしないと、ね。

きっかけはTwitterでのこのあたりのやりとりと、今お手伝いしているコンクール絡みのイベントがあるっていうことなんですが、Twitterに声で投稿できるかというテーマがあって、ちょっとやってみた。らくらくホンでTwitter(モバツイッター(以下モバツイ))を使って気づくあたりの話も含めて少し紹介したい。

Twitter / aok mto: .@fshin2000 伝言です。らくらくホンの音声「入力」にも対応してほしい。私自身は未経験なため、何も差し挟む余地はありませんです。土曜日に弱視の人の集まりで、聞きました。

Twitter / Junnama Noda: おそらく音声メールなのでユーザー毎にメール経由のポスト可能ならいけるのでは? http://bit.ly/9Eco70 RT @fshin2000: @pinpain そんな機能があるんですか。なんかブラウザベースだと難しそうな気もしなくもないけど...

Twitter / えふしん: @junnama @pinpain じゃぁ「メール投稿」でできますね。

イベントはこちら。2月24日開催です。

機種はF884i(らくらくホンプレミアム)。僕の記憶ではこの機能(音声メール)はオプションで月々210円。興味あったので申し込んでおいたのです。使ったのは今回が初めて。有料である理由は、変換を行うのをiアプリからASP経由で行うため。つまり、流石にこの携帯の中にそれだけの処理が出来るものが埋め込まれているわけれはなく、音声認識からテキスト化は外部のサーバーを使っているのです。

このあたりについては少し前の記事ですが下記のページに紹介記事があります。

音声入力中の画面

尚、当然ながらただ音声で入力するだけでなく、ウェブの読み上げから投稿操作までは音声ガイダンスを通じて出来ます。まったく画面を見ることなく僕にも投稿が行えました。

手順は下記の通り。

  • モバツイへアクセス
  • メール投稿
  • メール作成(題名入力状態)
  • 本文欄へ移動
  • [カメラボタン]でiアプリ起動
  • 決定ボタン
  • バイブが振動(または音声ガイダンス)
  • 声で入力(30秒以内)
  • iアプリがサーバーに通信してテキスト変換
  • 確認>確定
  • 続きがあれば再度[カメラボタン]でiアプリ起動
  • 内容確定後、送信

一連の動き? を音声ファイルにしましたのでアップします。

さて、感想等

「Twitter+モバツイ+らくらくホンが拓く新しい世界」なんていうタイトルを書いたわけですが、これやっぱり新しいコミュニケーションの世界なんだと思います。不思議な感じ。

実際僕が視力を失ってスクリーンリーダーのお世話になることを考えたらそれなりにかなり必死で取り組まなきゃならないと思うんですが、Twitterを使うだけなら実際自分で画面見ないでいけましたから。入力、確認といった煩わしさもなく、まさにTwitter的な世界観とでもいうのでしょうか。

昨日からの帰り道に練習がてらポストしてみたんですが、何ていうか電話で会話している感じ。タイムラインを読み上げて、アクセスキー[3]でメール投稿画面へ飛び(欲を言えばアクセスキー[3]でダイレクトにメールが立ち上がって欲しい。そうすればもっとシームレスに読み上げ>投稿へ移行できる)、そこから上記の手順でポストします。ひとこと程度のつぶやきなら30秒でいけるし、少し長いものは複数に分けて入れます。ただ、このあたりはいずれ技術が解決してくれると思う。

日常的に使うのであれば変換サーバーとのやりとりの待ち時間とかiアプリ起動の待ち時間とか気にならないわけじゃないですが、新しい可能性を十分に感じさせてくれます。

モバツイのアクセシビリティ

モバツイの[元]省エネモード、らくらくホンをも意識されたようなシンプルな表示モード、これで音声読み上げモードでは格段に使いやすくなります。理解もしやすいようにリンクのラベルも工夫されています。このあたりは仕方ないんだろうけど、慣れてくると少しラベルが冗長に感じられるようにはなりますが。慣れてしまうと「このつぶやきにリプライ@」→「リプライ」のほうがシンプルだし、上級者モードとかを作るのがいいのかもしれないですね。あるいは「ガイダンスモード」っていうのがあって、ガイダンスモードでは「このつぶやきにリプライ@」、通常モードでは「リプライ」とか。開発側の負担は間違いなく増えますが、こうなればもっと使い勝手が良くなると思います。

アクセシビリティ=アクセス出来ること、であれば冗長なラベルであってもクリアできてるわけですが、携帯電話、音声読み上げに最適化となれば、ラベルの長いのは少し気になります。

ただ、これはUA側で例えばa要素のtitleを読み上げるかどうか、とかいった実装が出来るようになれば解決する問題でもあります。アクセシビリティって結局最後はそういった話になるんだと僕は思います。

もう一点は既に書きましたがアクセスキー[3]でダイレクトにメールが立ち上がって欲しい。これはえふしんさんもそう感じてもらえたみたいだから、別に音声読み上げに限ったことじゃないですよね。

Twitterそのものが抱える(日本語環境での)アクセシビリティ

これはモバツイに関することじゃないんですが、一番読み上げていて気になるのは実は「ユーザー名」なんです。例えば「fshin2000さん」は、「えふえすえっちあい、にせんさん」です。「junnama」じゃ「じゅんなま」なんですが。英語圏なら名前が単語として登録されているケースが多いでしょうから読めると思うのですが、たとえば「にせんさん」てのは「2003」ともとれてしまうし(fshin2000さんすいません、特に取り上げた理由はないんですw)ユーザー名は本当にわかりにくいです。

ログイン名が表示されるのはTwitterの仕様だから、ここは「設定」画面の「名前」のほうを表示することで解決出来そうな気もします。但しTwitterは@ユーザー名っていうルールがあるので、つぶやきの本文の中にもユーザー名が頻繁に出てきます。とはいえ実際の読み上げ環境で利用しておられる方はさほど気にしておられないのかもしれませんが。とはいえ、絶対名前が日本語で扱えた方がわかりやすいと思う。これは絶対にそうだと思います。

それでもこれは新しい体験、新しい世界

例えばiモードブラウザのインプット要素やテキストエリアが同じく音声入力に対応してサーバーへの接続時間等の問題が解消されたら(またサイト制作者側がこういった用途を意識して構築を行えば)、あたらしい可能性が広がるんじゃないかって。そう思います。正直新鮮な体験でした。ケータイサイトやケータイWebサービスを構築している人には是非とも考えて欲しいテーマです。

それでは、次回はイベントでお会いしましょう。

関連エントリー

MTIfPreviewプラグインってのをカッとなってアップしたら、たくさん(@usualoma)から

@junnama <mt:IfPreview></mt:IfPreview> は、<mt:If name="preview_template"></mt:If> でもいいんじゃないかと思いました。

と来たもんだw

ときたらMT芸人の先輩としてはさらにカッとなるのが心情というもんで、書いた。プレビュー拡張してIMG要素のALTをチェックするプラグイン。

(追記)MTImgAltCheckブロックタグには、targetモディファイアとして[tag|src]のいずれかが指定できます。tagを指定した場合はtagsモディファイアに評価したいタグをカンマ区切りで指定します。下記の例はMTEntryBodyの中身のみチェックします。

srcを指定した場合は評価したいソースをSetVarBlock等で変数に入れてsrc属性に突っ込んでください。(追記ここまで)

ブログ記事アーカイブのテンプレート

<MTIfPreview>
<h3>
ALT属性のチェック結果
</h3>
<MTImgAltCheck target="tag" tags="MTEntryBody">
<MTImgAltCheckHeader>
<table border="1">
    </MTImgAltCheckHeader>
    <tr>
        <td>alt属性の値:
            <MTImgAltCheckImgAlt></td>
        <td><a href="<MTImgAltCheckImgSrc>" target="_blank"><MTImgAltCheckFilename></a></td>
        <td>
            <MTIf name="__error__">
            <MTImgAltCheckErrorMessage>
            <MTElse>
            チェックOK
            </MTElse>
            </MTIf></td>
    </tr>
    <MTImgAltCheckFooter>
</table>
</MTImgAltCheckFooter>
</MTImgAltCheck>
</MTIfPreview>

結果はプレビュー時のみ表示されます

プレビューでの画像のALT属性チェックの結果

ループの中ではMTImgAltCheckErrorCodeタグで以下の4種類の値が所得できます。

エラーコードエラーの内容
1ALT属性そのものがない
2ALT属性が空
3ALT属性値がファイル名と同じ(MTだとありがち?)
4ALT属性が(半角)スペースのみ

ALT属性が空でもいいときあるじゃんとか言うなよ。そういうのはちゃんと確認してチェックするんだ!

ダウンロード

ライセンス:Artistic License

既に公式サイトに審査についての考え方を掲載しています。また公表にあたってのコメントについても週明け早々に掲載させていただく予定です。

よって、ここ(私のブログ)に書いている文章については、私個人の考え方に基づく見解が含まれることについてあらかじめご了承ください。

一次審査基準について

今回、まず第一弾として「一次審査基準 - PC版ウェブサイト(案)」を作成、公開いたしました。

最初にお伝えしたいことは、今回公開したのは審査委員で考えた「案」であることです。

10月7日に行われた公開討論会 "だれもが使えるウェブサイト" の際に今回の審査に関する考え方をお話させていただいた通り「公平でオープン」に進めていきたいという思いから「案」の段階で公開しました。最終形ではありません。近日中に皆さまのご意見をいただく窓口についてお知らせする予定です。ご意見、ツッコミ歓迎です。よろしくお願いします。

もう一点、このコンクールは、標題にもある通り「みんなの声で選ぶ」コンクールであり実際にウェブサイトを利用する利用者(市民モニター)の方に評価していただくことが最大の特徴であると考えています。ですので、本来はこの審査基準に基づいた一次審査なるものは必要ないと思っています。

一次審査はあくまでも審査サイト数が多く、評価していただく市民モニターの数が不足することを前提として設けているものです。

よって、審査サイト数と市民モニターの数を勘案して、第一次審査は行わないことがあります。この点を特にお伝えしておきたいと思います。最終的な評価はあくまでもサイトを利用する利用者の方々が行います。

また、一次審査が行われた場合、一次審査の点数は二次審査には引き継がれません(現段階ではそう考えています)。

JISと審査基準について

項目のリストアップについてはJIS X8341-3(2004年度版)をベースにしています。JIS X 8341-3:2009原案ではありません。このことについては議論がありましたが以下の2点により2004年度版をベースにしました。

  • 2009年版はまだ原案段階であること
  • チェックツールが2004年度版をベースに作られていること

但し、一次審査対象ページの抽出についてはJIS X 8341-3:2009原案にある「8.1.2 ウェブページ一式単位 c) ヒューリスティックに選択する場合」を参考にしています。

一次審査基準について

客観的に評価する

一次審査基準の最後のツメ(配点あたり)を行っている時にTwitterでつぶやきながら作業進めていたので、そのあたり少し引用しながら紹介していきたいと思います。

Twitter / Junnama Noda:二次がメイン(人によるチェック)ってのが今回の特徴だから、一次は逆に人の評価をあまり入れたくないのです。二次審査の人が充分確保できたら一次はいらん、っていうのが基本スタンス。

Twitter / Junnama Noda:当然ながら代替テキストやラベルの妥当性はツールでチェックできない。

Twitter / Junnama Noda:title要素は機械チェックで済ましたくないけど適切なものかどうかは主観だし。

Twitter / Junnama Noda:ボタン画像にボタンクリックで起こるアクションを表すテキストが指定されていればOK。テキストの妥当性はチェックしない。

代替テキストが指定されているかどうか、フォームのラベルとコントロールが紐付けられているかどうかというのはツールでチェックできます。但し当然ですがそれが適切か、妥当なものかについては(現時点では)機械では検証できません。

適切、妥当でないものは当然役に立たないかかえって理解の妨げになります。でも、今回は配慮しません。適切か妥当かってのには主観が入るからです。

ここでは「大切かどうか」は切り捨てる、ということです。例えばタイトル要素は大切。「例えば他のページ(HTMLファイル)をコピーして違う内容のページを作った」「タイトルの変更を忘れて内容が全然ページの内容と違う」。これは致命的だと思います。 でも、そこは評価しないのです。

ここ評価しようと思ったら国語のテスト、読解力を問われることになるかと思うのです。審査員を読解力で選んでいないから、ここに点数はつけられません。だからつけない。

この考えは採点は1/0(イチかゼロ)。という考えにも繋がります。配点5点のものは5点か0点。2点や1点はない、ということにしました。

配点のバランスをどうするか

主観を排除するということから「機械的にチェックできる」「人によって違う評価にならない」ものを中心に据えることになります。ただしそれだとJISの項目(満たさなければならないことが明示されている項目)が網羅できません。

どうしても審査員が判断していかなければならないことがあるからです。

一次審査基準(案)26.省略語、専門用語、流行語、俗語などの想定する利用者にとって理解しにくいと考えられる用語に解説があるか(5.9.c)。

そこで、その部分によって配点に差をつけました。主観的な評価は配点を低く[3点]。そして、審査はサイトにつき3名。平均ではなく、2人以上がつけた点を採用。採点は1/0(イチかゼロ)なので、5点、-5点、3点、-3点、0点のいずれかになります。

今回の項目はすべてJISの満たさなければならないことが明示されている項目で構成されています。配点の3点、5点については項目の重要度ではなく、この考え方に拠ります。

加点か減点か

加点か減点か。メーリングリストではFlashやPDFの話が出た時に議論になりました。

例えばPDFがアクセシブルもしくはアクセシブルな代替コンテンツがあれば[5点]とした場合(当初案ではそうなっていました)、PDFのあるコンテンツの方が有利になります。Flashも同じ。

なので、減点としました。じゃぁ、Flash使わない方が有利じゃないか。それは現時点ではその通りです。

でも分かった上でチャレンジはしてほしいと思っています。一般的でない技術(「一般的」の定義は? ってツッコミは当然あると分かった上で)、もしくは「アクセシビリティを確保することに対して敷居の高い技術を敢えて使うからには、そこはクリアして欲しい、でいいじゃない」というのが今回の考えなのです。

Twitter / Junnama Noda:title要素は加点じゃなくて減点にしたいところとか。でもそうすると矛盾が出る。いや、出ないか。これ感覚てか主観だな。

これは僕の感覚的なものですが、TITLE要素なかったら減点! 論外って思うわけです。感覚的には。

でも今回は一般的な技術(X)HTMLやCSSに関わる部分はクリア出来ればすべて加点、です。

ちなみに、TITLE要素がページの内容を適切に判断しているものはを主観的に審査員が判断して[3点]、とすることも検討しました。でもそこは「我慢」。限られた審査員のリソースでっていう前提もあるので、ツールでチェックできるものはそこで判断します。

Twitter / Junnama Noda:画像に代替テキストを提供しているか、ってのは、加点? 減点? だって、画像のないページもあるでしょ?

Flash/PDFは減点方式。であれば「画像」はどうなんだ、っていうつぶやきですね。もちろん画像のないページもあるかもしれませんが今回は「一般的」な技術として評価します。よって画像は評価対象で加点。

一次審査基準(案)15.画像に代替テキストを提供しているか(5.4.a)。

「[配点](すべて)提供している場合[5点] 」としています。(他の項目もそうですが)画像が何点あるかは考慮しません。1点でも100点でも「すべて」満たしていたら5点。ということは、画像が0点であれば無条件で5点となります。

そして、画像を使っているかどうかに限らず、ページ全体の背景色と前景色のコントラストについてチェック項目を入れました(加点対象)。

尚、この項目については aDesignerでチェックすることで客観的判断が可能ということで[5点]にしています。

一次審査基準(案)20.画像やページのデザインにおいて背景色と前景色に充分なコントラストが確保されているか(5.5.c)。

配点に関する各項目の考え方の例

各々の項目は審査基準のページを参照いただければと思いますが、配点に関する検討のプロセス(考え方)についていくつか例をあげます。

一次審査基準(案)1.ページのHTML(XHTML)が規格及び仕様に則り、文法に従って作成されているか(5.1.a)。

  • 一般的なページで利用される技術であることから[加点]
  • 機械的なチェックを行うことにより客観的な評価が可能[5点]
  • よって、+5点

一次審査基準(案)10.ページ内のフォームの入力欄に何を入力すればいいか理解しやすく、操作しやすいか(5.3.b)

  • フォームが使われていないケースも想定されることから[減点]
  • 機械的なチェックに加え、審査員の判断でチェックしなければならないので[3点]
  • よって、-3点

また、同様に「フォーム」を含む項目ですが、

一次審査基準(案)9.フォームなど、すべてのページ内要素(Flashを含む)がキーボードで操作できるか(5.3.a)

  • キーボード操作対象となるハイパーリンクは一般的な技術につき[加点]
  • ツールに拠るチェックだけではチェックしきれないが、審査員によって審査結果に差が生じないと考えられるため[5点]
  • よって、+5点

といった考えで配点を決めていきました。

もちろん「どっちともとれる」項目があることは否定できません。

ツールによるチェックの限界

今回の審査には、Web Inspector 5.11aDesinerを活用します。当然ですがツールによるチェックには限界があると考えています。

JIS X 8341-3 5.5.b ウェブコンテンツの内容を理解・操作するのに必要な情報は、形又は位置だけに依存して提供してはならない。

これに対してWeb Inspector 5.11のチェック項目は以下の通りです。

  • 取消し線(<del>)を使用していないか?
  • 取消し線(<s>)を使用していないか?
  • 取消し線(<strike>)を使用していないか?
  • 「yy/mm/dd」という文字列で、日付を表現していないか?
  • 全角の¥と全角の$を使用していないか?
  • 全角の「yy/mm/dd」という文字列で、日付を表現していないか?
  • 「※」という文字列を、「注釈」の意味で使用していないか?

個人的には<s><strike>はともかく、<del>はいけないのか? と思います。但し現実的に例えば「イベントの中止」を取り消し(<del>)で表現したとして、取り消されたことが読み上げで伝わらないことがあります。それでも前後の文脈等によって取り消されたことが伝われば良いと思うのですが、そこまではチェックできません。そのあたりは常に悩ましいところです。

一次審査基準(案)18.形や位置に依存した情報提供をしていない(5.5.b)。

Twitter / Junnama Noda:「だって、形や位置に依存した情報提供をしていない」に対して「yy/mm/dd」が駄目? これって形なのか?

「yy/mm/dd」というのが(分数のように読み上げるブラウザがある)環境や文脈によっては理解しにくいというのは事実でしょうが、これが「5.5.b」に該当するかどうかは僕には疑問でした。

もちろん、画像や実際のレイアウト等を含めて判断しなければならないわけですが。 いずれにしても、各所で既に指摘されている通りツールによるチェックには限界がある、ということをいつも意識しておきたいと思います。

終わりに - まだ終わりじゃないけど

コンクールはこれからですが、本エントリの終わりに。基本的に今回の審査委員はボランティア参加です。審査基準についても時間やリソースに限りがある中での作成作業でした。ということを言い訳にするつもりはありませんが、私たち自身も色んな味方があるだろうし、ツッコミどころもあるだろうな、という点は分かった上で「案」として公開しました。ですので、是非建設的なツッコミをください。ツッコミ歓迎します。

それと、最後にひとつ。たくさんのご応募お待ちしています。

10月初旬に大阪と東京でセミナーやります。内容は違うものですが。いずれも参加無料です。

Power CMS for MT活用セミナー(10月10日 - 大阪開催)

東京ではランチ付きだったじゃねーか、ってのは言わんとってください。あれはその時間しかどーしても都合がつかなかったので。土曜日だし、終わって時間のある人は飲みにいけへん、ってのもありかと思いますし。

内容は実際に制作者の立場で構築、さわっていただきましょうというものです。以下ちょっとまじめに告知メッセージです。

関西の案件、やっぱり東京の案件より全体的に予算が足りないっていうか、そういうところあると思うんです。そんな中で20万円〜ってのが導入になかなか踏み切れないってそういう会社さんもあると思います。私からのメッセージは「まずは触ってみてくれ」ってこと。CMSとしての使いやすさだけじゃなくて、サイト構築を楽にする、時間を短縮するという一面ももっているCMSです。はっきりいって、強力です。

しかも、ベースがMTです。MTのお作法で拡張されています。テンプレートタグでああしてこうして、ってのが出来る人ならすぐ使えます。で、これまでは苦労して力技で構築していたのが、こんな風に出来るのか、ってのを感じていただければと思います。

逆に、今ウチの会社ではサイト構築のパートナーも探しています。Power CMS for MT、結構なペースで導入いただいてます。構築に関しては正直ウチだけでまわらない。MTが得意な方、フットワーク良く対応いただけるかた、弊社が全力でサポートしますので、制作会社の方、フリーランスの方、是非マスターしてみませんか。仕事はウチがつくります。

会場はウチの会議室です。PCは持ち込みいただきたいのですが、何台かは貸出し出来ます。

アルファサード会議室

Movable Type 5 最新情報 & 圧倒的コストパフォーマンスのハイエンドCMS体感セミナー(10月6日 - 東京開催)

こちらはシックス・アパートさんとの共催で、逆に大阪で先月やったものとほぼ同じ内容です。Power CMS for MTのほか、MT5の最新情報や、弊社のXtalkAltStyleといった他のソリューショについてもお話します。

特に最後のセッションでは、弊社の持田からCMSで実現するウェブアクセシビリティや、AltStyleの紹介、あわせてウェブアクセシビリティの最新動向等もお話させていただく予定です。是非ご参加をご検討くださいませ。

また、弊社のセミナーではないですが、翌日東京で開催される 公開討論会 "だれもが使えるウェブサイト" には私も参加します。生Junnamaと話してみたいとか、ウチの会社に来たいけど直接売り込んだれ、っていう人も歓迎です(笑)。

それでは、当日お会いしましょう。

少し個人的&会社で協力させていただいているイベントです。当日は私も参加しています。是非ご参加ください。

プレスリリース

利用者の視点で「だれもが使え、参加できるICT」を目指して活動しています、NPO法人ハーモニー・アイ&みんなの声で選ぼう!だれもが使えるウェブコンクール実行委員会と毎日新聞社ユニバーサロンとの共同企画のお知らせです。

「みんなの声で選ぼう!だれもが使えるウェブコンクール」を10月より開催するにあたりそれに先駆けて、10月7日(水)19時〜に以下の公開討論会の開催が決定しました!

ぜひ、皆様ご参加ください!

公開討論会 "だれもが使えるウェブサイト"〜企業サイトのアクセシビリティでビジネスチャンスをつかむ〜

詳細と無料お申し込み: http://daremoga.jp/

【概要】

ウェブサイトにとって大切な「だれもが使える」「多くの人に使いやすい」ということ。

このことは、ウェブの利用者に利便性を提供するだけでなく、ウェブサイトを提供する企業にも有効なビジネスチャンスをもたらします。しかし、多くの企業のウェブサイトは、使いやすさへの配慮が足りないために、ビジネスチャンスを逃しています。

シニアや障害者、パソコンに詳しくない一般の人々がどのようにウェブを利用し、どのようなウェブを望んでいるのか。使いやすさへの配慮がビジネスチャンスにつながるとは、どういうことか。企業ウェブサイトのアクセシビリティで、直接的なビジネス効果を出すためには、どのように取り組めばいいか。

毎日新聞社ユニバーサロン編集長の岩下氏をモデレーターに、パネリストが本音で討論します。

【登壇者】
モデレーター:
  • 岩下 恭士 氏 (毎日新聞社 デジタルメディア局 ユニバーサロン編集長)
パネリスト:
  • 馮 富久 氏 (株式会社技術評論社 クロスメディア事業部部長代理)
  • 安田 英久 氏 (株式会社インプレスビジネスメディア Web担当者Forum編集長)
  • 曽根 清次 氏 (社団法人長寿社会文化協会(WAC) 関東ネットワークセンター 事業推進部長)

他、アクセシビリティに積極的に取り組みをされている企業様にも出演依頼中。

【日時】

2009年10月7日(水) 19:00 から 20:30
(公開討論会後、会場にて軽い交流会を予定しています)

【場所】

毎日新聞社 東京本社 4階フリースペース
(東京都千代田区一ツ橋1-1-1 パレスサイドビル 4階)
地下鉄 東京メトロ東西線 竹橋駅 1b出口 直結

社員の誘導がないと入場できないため、18:50 までに4階の西エレベーターホールに集合してください。

なお 18:30 から 18:50 まで、竹橋駅 1b出口 改札にガイドボランティアを配置しています。

【参加費】

無料(交流会に参加いただく方は1000円)

【定員】

50名(お申し込み多数の場合、抽選になることがあります)

【詳細とお申し込み】

http://daremoga.jp/

【こんな方にお勧め】
  • 企業・団体・公的機関のウェブサイトの担当者
  • ウェブ制作会社・広告会社の方
  • ウェブサイトのアクセシビリティに興味のある方
【主催】
  • みんなの声で選ぼう!だれもが使えるウェブコンクール実行委員会
  • NPO法人ハーモニー・アイ
【後援】
  • 毎日新聞社
  • 株式会社技術評論社gihyo.jp
  • 株式会社インプレスビジネスメディアWeb担当者Forum
【「みんなの声で選ぼう! だれもが使えるウェブコンクール」とは】

インターネットの活用はすごい勢いで発展し、今や多くの市民もそのシステムを活用するようになってきています。その窓口ともなるウェブサービスは、みんなの可能性を広げてくれる大切な役割を担っています。

しかし、現在残念ながらまだまだ確実にだれもがアクセスできる、使いやすいウェブの広がりは発展途上です。

特に、高齢者や障害者、ITには不慣れなユーザなどは、おいてけぼりになりがちです。また、ウェブへのアクセス環境もここ数年で、携帯電話はじめとする様々な環境が 一般的に広がりをみせています。

そこで、このコンクールにおいて「おいてけぼり」になりがちな障害者、高齢者の市民モニターへも参加いただき、その意見も参考に、利用者視点を重視した使える、使いやすいウェブを審査し表彰させていただきます。

だれもが使えるウェブ発展のために!

【「公開討論会」および「だれもが使えるウェブコンクール」のお問い合わせ】

NPO法人ハーモニー・アイ 事務局
〒135-0042 東京都江東区木場3丁目14番11号205
メールアドレス: harmony-i@harmony-i.org

Twitterのキャプチャ

ハーモニー・アイさんのお勉強会に参加。NVDATwitterがテーマ。

NVDAについては、Parallels+Vistaへのインストールが時間がかかってかかってしょうがなく、インストールできたが音が出ない状態で何も書けないのだけど、改めて試してみたい。

さてTwitter。

zenichさんがTwitterって何? 何が面白いの? というお話をされて(これも中々話しでは伝わりづらいのですが)、じゃぁ実際に使ってみましょうということになった。

ところが...

アカウントが作れないのです。視覚障碍者だけじゃない。高齢者の皆さん、それでもネットはそこそこ使われている方々だし、逆に参加されている視覚障碍者の皆さんなんて非常にネットリテラシーの高い方々なんだが。

問題はこれ。CAPTCHA。とにかく一発二発で成功しない。視覚障碍者の方にはサウンドがある。でも「何言ってんのかわかんない」。

結局20-30分くらいだったかな? サインアップできない人多数(僕もCAPTCHAの入力お手伝いしたりしたのだが、それでも駄目。他の項目が駄目なのか? メッセージも英語でわかんない→不思議なもんで、昨日あれだけみた英語のエラーメッセージ、さっきあれこれやってみたんだけど再現できないんだよな)。

確かにスパマーやってくるし、エロアカウント増えるのかもしれんが、もう少しどうにかならんものかと思うのだ。

一点、具体的に提案したいのだが、キャプチャもサウンドも日本語化しない? これだけでも敷居が下がる筈。実装難しくないだろうし実際に検索すると出てくる

できればランダムな意味のない言葉じゃなくて、英語版Twitterのように意味のある単語であればもっと理解しやすいんじゃないかな?

あと、直接関係はないのでが、ウチのスタッフに教えてもらった。こういうアプローチ、好きだな。自分のスタンスにも近いのかな。“隙間を埋める”的な支援技術へのアプローチ。

僕はケータイインターネットのヘビーユーザーである。女子高生とメル友になれるくらいのスキルがあると自負しているw

先日親兄弟で集まった時に今年から大学生の姪にちょっと聞いてみたらmixiとリアルだった。そう、やっぱり流行ってるのかリアル。ちなみにマイミクになるのはやめておいた(あっちには結構きわどい?ことも書いてるから)。

話を元に戻す。利用しているのは主に外出中ではあるが、東京-大阪の行き来を含めて外にいる時間はかなり多いので、ケータイでWebっている時間は(同業の人と比較すれば)多い方だと思う。ちなみに今はN700系の無線LAN使用中。Macでこれ書いてる。

よく使うサービス、サイトは以下、というか殆どこれだけ。

  • Gmail
  • Mova Twitter
  • Mixi
  • Livedoor Reader
  • JRおでかけネット(エクスプレス予約のため)
  • 楽天トラベル(宿泊の手配)
  • Cerezo Osaka(セレッソ大阪の公式 - こいつは唯一有料会員になってる。テキスト速報が見られる)
  • Google(検索用)
  • Yahoo!(検索用)
  • Naked → Google(検索用)
  • Yahoo! プロ野球(但し携帯でそのまま見られないのでNakedで変換したものをBookMarkして利用)

その他、いくつか良く泊まるホテルのページや特定のページをブクマしているとかブログの管理画面をケータイ化してるのでその管理画面とか。はてブとかも時々見る。

あと東京ではモバイルSuica使ってるってのは直接関係ないか。とにかくケータイ手放せない。

仕事もかなりできる。メールの対応が出来れば、営業的なやりとりやスタッフへの指示も出来るし、ケータイだけで商談成立(金額のやりとりしてライセンスの発注OKになったとか)する場合もある。先日はTwitterで受発注? のやりとりまでしてしまった。

で、何となく感じたことだけど、例えばGmailでもLivedoor ReaderでもGoogleでもはてブでも最終的なコンテンツへのリンクはGoogle Mobile Gatewayなんかを通ることになる。Livedoor Readerだとモバウザーだっけ。はてなにしても「ケータイでみるために変換しています」とか出るよね(自社系のサイトくらいはちゃんとモバイル対応したらいいのにとは思うけど)。

GoogleはともかくLivedoorやはてなのGatewayは、変換元サイトの広告はぶった切って自社のモバイル広告を入れてるってあたりがちょっと複雑な気持ちになるが、それ置いておいて「これってテキストブラウザじゃね?」と思うのだ(画像変換とかもするけど基本はテキストベースだし)。

Lynxに代表されるような使い勝手の良い高機能? なテキストブラウザって確かにあるんだけどシェアはかなり低いだろうし、ウェブ制作の時にLynxでチェックしますってのはめちゃくちゃ小数派だろう。

それでもGoogle Mobile Gatewayなんかを通してウェブを閲覧する機会は増えている。テキストブラウザって意外とシェアを伸ばしている、と考えることもできるんじゃないかな?

関連するかも? しれない話題

WEDGE表紙

「不況でもモテモテの外国人労働者」だそうである。

さて、ウェブアクセシビリティが大切ってのがウェブ制作の現場(ビジネスの現場)で理解されにくいという話は以前からあって、JIS X 8341-3が誕生して知識としての理解度は深まったり普及したりしたものの、昨今の不況のあおりでまたそういう話が出て来ているらしい。

予算がつかない。わかりやすいビジネスメリットが無いという話。

ここに書いた話では、結局はHTMLというソースの再利用の話で、厳密にはイコール アクセシビリティの話ではない。

SEOの話もそう。検索順が云々ってのは所詮SEOの話であって、やはりイコール アクセシビリティの話ではない。

ところが、少しばかり状況が変わって来た(ように思う)。

本質的に一つのソースを様々なデバイスで利用可能にしたり、再利用可能なコンテンツ、という本来の「アクセシビリティ」の話である。SEOなんかの話ではなく。

  • 自動翻訳の質が上がってくることで、アクセシブルなウェブコンテンツは機械的に翻訳されやすくなる
  • アクセシブルなウェブコンテンツは、読み上げやルビによって日本語の語学力の低い人の助けになる*

例えば「漢字を読むのが難しい」日本語を学習中の外国人にとっては、翻訳出来るだけでなく、音声で読み上げたり、自動的にルビが振れることが理解を助ける役に立つだろう。

以前にも少し書いたことがあるのだけれど(時々ではあるけれど)、以前公開したPDFをテキスト化したり、コンテンツにルビを振れるサービスについていろんな人から感想やお礼のメールをもらうことがある。意外と「ルビ」が喜ばれているのだ。日本へ留学している留学生の人なんかに。

そしてiPhoneとか、今ここでMacBookを使ってネットにアクセスしている環境(@N700系、通信速度は速くない)とか。

障碍者や高齢者だけでなく、健常者にも、携帯電話ユーザーにも「iPhoneユーザーにも」「外国人にも」「子供にも」「プアなネット接続環境でアクセスしているユーザーにも」理解してもらいやすいコンテンツ。これをビジネスメリットといわずして何というのだろう。

もちろん、これは外国人労働者が日本で働きやすくなることで社会がどうなる、という話ではなく、単純に「より多くの人にリーチできるウェブコンテンツ」にはビジネスメリットがないと言えるのか? そこに価値はないのか?という話です。

インターネットが普及した社会、グローバル化する社会。情報は国境だけでなく言語やデバイスの壁を越えて人に届けられていく。

さて、それでもサイトのアクセシビリティは後回しですか?

ちょっと前の話題になりますが。

先月末にカラースターがリリースされて、特別なものを貰って嬉しいという気持ちを触発させるのに、とても良いサービスだなと思ったのですが、ひとつ大きな問題があります。

色弱の人には、色の違いが分からなくて、嬉しさや楽しさが分からない(伝わらない)場合があるという事です。

シミュレータを使った見え方がこちらで紹介されています。

「色だけで表現しちゃいけない」ってのはカラーユニバーサルデザインの基本だと思いますが、こういうときこそ使って欲しいのがこれです(Mac専用ですが)。

ColorQuestのキャプチャ

こんな感じでマウスポインタのある位置の色を表示します。

Windowsだとこちらが使えると思います。

カラーユニバーサルデザインについては埼玉県の資料がよくまとまっていると思います。Webに限らずグラフィックデザインの人にも是非一度みて欲しいと思う。

じつはこのソフトちょっと思うところあってアップデートしたいところがあるんですが久しぶりに当時のコードを見たらなんつーか分かんなかった。もう5年前だしREALbasic全然使ってないしw。実は先日英語でメール貰ってちょっと焦った。

Junnama,

I just downloaded your Color Quest application for the max and think it's wonderful. I am working on something similar on Unix. Can you please share with me the algorithm you use to translate the RGB values into a color name?

かなり怪しい英語で返事したけど、まぁコード貼付けといたから何とか通じたようだ(本当かな?)。

Junnama,

This is brilliant. Thank you so much!

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 5.04

このアーカイブについて

このページには、過去に書かれたブログ記事のうちアクセシビリティカテゴリに属しているものが含まれています。

前のカテゴリはごあいさつです。

次のカテゴリはプログラミングです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。