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

米大統領選挙の速報。色分けで両陣営の優勢状況を表現している。

米大統領選挙、僅差で最後まで読めませんでしたね。普段政治のこと書いたりしないですけど(政治と野球の話はオンラインでしない主義)、今日は Web Accessibility Advent Calendar 2016 の23日目の記事です。

Accessibility Advent Calendar といえば、sukoyakarizumuさんによるこんな記事がありました。

私は ColorTester の作成者なので、本題の前に少しだけ ColoerTester について触れさせていただきます。特にこのページで結果のバラツキについてネガティブな書き方をされているわけではないのですが、ColorTesterの色の比較メソッドは W3Cのページにある計算式のそのまま、ほぼコピペです。

Xojoという開発ツールで作成しています

Function GetL (C As Color) As Double
  Dim R,G,B As Double
  R = C.Red / 255
  G = C.Green / 255
  B = C.Blue / 255
  If R <= 0.03928 Then
    R = R / 12.92
  Else
    R = ( ( R + 0.055 ) / 1.055 ) ^ 2.4
  End If
  If G <= 0.03928 Then
    G = G / 12.92
  Else
    G = ( ( G + 0.055 ) / 1.055 ) ^ 2.4
  End If
  If B <= 0.03928 Then
    B = B / 12.92
  Else
    B = ( ( B + 0.055 ) / 1.055 ) ^ 2.4
  End If
  Dim L As Double
  L = 0.2126 * R + 0.7152 * G + 0.0722 * B
  Return L
End Function

なので、テキストフィールドに値を入れて計算している以上は正しい結果を返していると思っているのですが、ピッカーから色を拾う場合に正確な値が拾えす、誤差がでることがあります(これはmacとWindowsでも少々異なるかもしれません)。(久しぶりにコードを見て確認したのですが)、ColorTesterのピッカーは、マウスポインタ周辺の小さなキャプチャを生成して、そこから色を拾っています。実はあまり知られていない(ように思う)のですが、ColorTesterでは「OS標準のカラーピッカーを使う」という設定が選択できます。スポイトアイコンをクリックする「ひと手間」が余分にかかるのですが、より正確に色を拾いたい場合、こちらの設定も試してみてください。

ColorTesteの設定で「OS標準のカラーピッカーを使う」を選択した場合

また、画像をドラッグ&ドロップで放り込む簡易チェック機能もあります。このロジックについてご興味のある方は下記の記事で紹介しています。

米大統領選挙の速報サイトに見る「色で表現したらわかりやすくね? 」問題。

さて、ようやく本題に戻ります。米大統領選挙、まだ記憶に新しく、次期大統領の発言もニュースを賑わしていますね。

この記事では、米大統領選挙の速報サイトのデザインにおける色問題について取り上げます。 米大統領選挙の速報サイトについては、以下のページに様々なデザインが紹介されていますが、冒頭で紹介した画像もその一つです。

上記のページでも触れられている通り、色分け、色の濃淡もしくは大きさなどでどちらが優勢かが視覚的直感的に理解しやすいと紹介されています。

色分けされた地図は視覚的でわかりやすいので、ついやってしまいがちなパターンですが、次に示すようにグレースケール状態にすると民主、共和党優勢、同数あたりの区別が困難になってしまいます。

考えておかなければならないのは、色弱(色覚異常とも表現されます)の人や弱視の人のことだけではありません。いまどきモノクロ?、みたいな意見は kindle が一蹴してくれましたし、例えばこの速報を見ながら会議を行っている時、モノクロ印刷した紙資料で配布されても何がなんだかわからないですよね?

同じ米大統領選挙の速報をグレースケール表示にしてみた。

このような画像は、JIS X8341-3の7.1.4.1(WCAG 2.0 の1.4.1) に適合していないことになります(適合レベルは「A」)。上部の更新時間や「当選 優勢」などの画像内の文字のコントラスト比が不足しているという別の問題もあります。

これを適合させるためには、以下のような方法があります。文字を併用する、パターンを変えるなど。

このような配慮がなされない理由として、全体的に「デザインが"うるさく"」なってしまう点が挙げられます。以下の例は、色に加えてアルファベット1文字を追加し、若干全体のコントラストを上げています(文字の大きさも当選か優勢で分けています)。

色に加えて文字を追加した大統領選挙速報地図

モノクロになっても理解できますね?

色に加えて文字を追加した大統領選挙速報地図(モノクロ版)

この「デザインが"うるさく"」なってしまう問題を回避するには、例えば文字併記版と文字のない版を切り替えられるようにする、表組みでマークアップしたテーブルを地図の下に表記する、などの方法があると思います。いずれにしても画像の alt属性に各州の結果をずらずらベタ書きで格納するのは現実的ではありませんから、マークアップしたテーブルを併記するのが良いと思います。国内で次の選挙の際にでも、このあたりに配慮された表現が見られると嬉しいですね。

この手の問題につながりがちなものを覚えておこう

このような表現になりがちなもののパターンを覚えてしまいましょう。何事も「ツボ」が大事です。非アクセシブルなものになりがちなものには以下のようなものがあります。

  • 施設・図書館などの開館カレンダー
  • グラフ
  • 地図・路線図

こいつらが出てきたら、「来やがったな!」 と思って確認する習慣を持ちましょう。

関連するかもしれない記事

アルファサードでも共催しています アクセシビリティやるぞ!夏祭り2 ~俺たちにテストさせろスペシャル~ の開催中で、紀尾井町の Yahoo! Japanさんにお伺いしています。夏祭りってのにもう9月も末で、どういうセンスなんだろうって思わなくもないですが、秋風が吹いて無くてとりあえずよかったです。

ちなみに「俺たちにテストさせろスペシャル」ってイベントのサブタイトルは私のアイデアなんですぜ!

受付で「インターネットの歴史(History of the Internet)」の巻物いただきました!

インターネットの歴史 巻物の写真

今日は、パネルディスカッションに出させてもらうほか、関連会社のラボさんと一緒に進めている僕のブログ(つまりこのブログ)のリーダーアプリを実際に触ってもらうという企画もあります。

アプリ「Junnama Online」は Movable Type の Data APIを活用したブログのリーダーアプリ(iOS版)で、現在 Test Fright中です。

以下、アプリのキャプチャを数点

メイン画面 - 記事の一覧 記事詳細画面 シェア画面 検索画面


さて、結果は如何に?

9月3日(土) メビック扇町で開催された CMS大阪夏祭り2016の懇親会で ColorTester について Lightning Talk してきました。

CMS大阪夏祭り2016懇親会で Lightning Talk する筆者の写真

[Photo by NExT-Season]

スライドに補足入れてますが、JIS X8341-3(WCAG2.0)において、ロゴタイプにはコントラストの要件はありません。

1.4.3 最低限のコントラスト: テキスト及び画像化された文字の視覚的な表現には、少なくとも 4.5:1 のコントラスト比をもたせる。ただし、次の場合は除く: (レベルAA) … ロゴタイプ: ロゴ又はブランド名の一部である文字には、コントラストの要件はない。

なので、このLTについては、各CMSのロゴのコントラスを論じるのが目的ではなく、画像の中の主たる文字の色についてどのように推察しているのかのロジックを紹介するものです。過去にもこのブログで取り上げたことがあります。

私の会社(アルファサード株式会社)では、第13期から電子公告を始めました(ちゃんと定款変更もしました)。

電子公告を始めた経緯というか考えなどはまた別の機会に書こうと思いますが、ここでは表題の通り貸借対照表のマークアップを取り上げます。

「貸借対照表(B/S)」こそ「複雑なデータテーブル」ですね。

アクセシビリティ・サポーテッド(AS)情報:H43

見解としては「要注意(スクリーンリーダーによるサポートが十分とはいえない。)」

id属性とheaders属性を使わないですむように、できるかぎり単純な構造にしたほうがよい。

ということで、表を3分割することも検討したのですが、流動資産と流動比率を対比してみたい(流動比率とかを見たい)とかだと同じ表のほうがいいだろうかとか、でもそうなると空のセルをつくってセルの位置を調整したほうがいいんだろうかとか。そもそも経営指標って様々な切り口があるので「何と何を並べるのがいいのか」など、決算公告ってPDFで提供してる会社が多いですが「貸借対照表の公開について」みたいなのを国(法務省)や東証がガイドラインを示すとかしてもいいんじゃないかと思ったりした次第です。

資産の部、負債の部、資本の部を別のテーブルに分割する方法も検討した

現在のところ結論があるわけではないですが、結局は idとheaders属性によるひも付けを選択しました。ご意見などありましたらいただけると嬉しいです。今後のユーザーエージェントの対応に期待します。

ということで、以下マークアップ。

<table>
<caption>貸借対照表</caption>
<tbody>
<tr>
    <th scope="col" colspan="2" id="assets"><strong>資産の部</strong></th>
    <th scope="col" colspan="2" id="liabilities"><strong>負債の部</strong></th>
</tr>
<tr>
    <th id="asset-1">現金・預金合計</th>
    <td headers="assets asset-1">254,325,832</td>
    <th id="liability-1">仕入債務合計</th>
    <td headers="liabilities liability-1">5,768,438</td>
</tr>
<tr>
    <th id="asset-2">売上債権合計</th>
    <td headers="assets asset-2">37,361,649</td>
    <th id="liability-2">他流動負債合計</th>
    <td headers="liabilities liability-2">70,318,782</td>
</tr>
<tr>
    <th id="asset-3">棚卸資産合計</th>
    <td headers="assets asset-3">534,600</td>
    <th id="liability-3">流動負債合計</th>
    <td headers="liabilities liability-3">76,087,220</td>
</tr>
<tr>
    <th id="asset-4">他流動資産合計</th>
    <td headers="assets asset-4">523,689</td>
    <th id="liability-4">固定負債合計</th>
    <td headers="liabilities liability-4">84,331,000</td>
</tr>
<tr>
    <th id="asset-5">流動資産合計</th>
    <td headers="assets asset-5">292,745,770 </td>
    <th id="liability-5"><strong>負債合計</strong></th>
    <td headers="liabilities liability-5">160,418,220</td>
</tr>
<tr>
    <th id="asset-6">有形固定資産計</th>
    <td headers="assets asset-6">36,334,934</td>
    <th scope="col" colspan="2" id="capital"><strong>資本の部</strong></th>
</tr>
<tr>
    <th id="liability-6">無形固定資産計</th>
    <td headers="liabilities liability-6">7,163,609</td>
    <th id="capital-1">資本金合計</th>
    <td headers="capital capital-1">10,000,000</td>
</tr>
<tr>
    <th id="asset-7">投資その他の資産合計</th>
    <td headers="assets asset-7">18,205,477</td>
    <th id="capital-2">利益剰余金合計</th>
    <td headers="capital capital-2">184,031,570</td>
</tr>
<tr>
    <th id="asset-8">固定資産合計</th>
    <td headers="assets asset-8">61,704,020</td>
    <th id="capital-3">純資産合計</th>
    <td headers="capital capital-3">194,031,570</td>
</tr>
<tr>
    <th id="capital-4"><strong>資産合計</strong></th>
    <td headers="capital capital-4">354,449,790</td>
    <th id="assets-capital"><strong>負債・純資産合計</strong></th>
    <td headers="assets assets-capital">354,449,790</td>
</tr>
</tbody>
</table>

CMS大阪夏祭り2016 にて「オーサリングツールとしてのCMSとWebアクセシビリティ」というタイトルのセッションを持たせていただくことになりました。地元大阪で話す機会が最近あまりなかったので、ほぼ1年ぶりですね。

CMS大阪夏祭りビジュアル

去年も「祭り」のつくイベントにいくつか参加させていただいてお話させていただいたのですが、今年もお話します。お祭り男と呼んでください!

会社設立からもう13年、ずっとwebアクセシビリティのことに取り組んでいたんですけど、CMSを事業の中心に据えてからまもなく10年、ATAG(Authoring Tool Accessibility Guidelines (ATAG)) 2.0についても自分自身、再度見直す機会になればと思っています。

また、少し前になりますが、AccSellのポッドキャストに呼んでいただきまして、ツール屋目線でのwebアクセシビリティ語りをさせていただく機会をいただきました。参加いただく方は時間があれば(早送りででも)ざっとお聞きいただければバックグラウンドなどわかっていただけるかもしれません(長いですがw)。

この記事は Web Accessibility Advent Calendar 2015 の19日目の記事です。

職業柄 CMS を扱うことが日常になっているわけですが、私たちにはCMSから出力されるコンテンツのウェブアクセシビリティを確保することが求められます。

テンプレートをアクセシブルにすれば後はコンテンツ登録者に委ねられるというのは一見最もな主張に聞こえますが、アクセシブルなコンテンツ入力がしやすいよう、もしくはそこにコンテンツ登録者が注意を払えるように入力インターフェイスを設計するのはCMS開発者の義務だと言えるでしょう。

W3Cには Authoring Tool Accessibility Guidelines (以後ATAG) というガイドラインがあります。文字通り、オーサリングツールのアクセシビリティに関するガイドラインです。

このガイドラインでは、オーサリングツールそのものがアクセシブルであることはもちろん、オーザリングツールがアクセシブルなコンテンツを作成できるようにすること、そのためのガイドラインが前者(オーサリングツールそのものがアクセシブルであること)については別の機会に譲り(ここが難しくて、自分たちもできていないという認識はあります)、ここでは後者、「オーザリングツールがアクセシブルなコンテンツを作成できるようにする」部分、しかも一点、画像の代替テキストを指定するためのCMSの実装について少しだけ考察してみます。

ATAGには Guideline B.2.3: Assist authors with managing alternative (非テキストコンテンツの代替コンテンツを管理して著者を支援する) とあります。ざっくり紹介します(訳には誤りがある可能性があります)。

  • 不適切に生成された代替コンテンツは、ウェブコンテンツのアクセシビリティの問題を発生させ、アクセシビリティチェックを妨げる可能性があります。
  • 代替コンテンツが編集可能であること。オーサリングツールが非テキストコンテンツを追加するための機能を提供する場合は、コンテンツ作成者は、非テキストコンテンツのためのプログラムで関連付けられている代替テキストを変更することができます。
  • 非テキストコンテンツが、装飾、フォーマッティング、不可視またはCAPTCHAである時に例外を指定できること。
  • 代替テキスト生成を自動化する場合、例えば「画像」や、ファイル名、ファイル形式等であってはいけません。また、自動で生成されることをコンテンツ作成者が拒否できるようにしてください(勝手に自動生成しない、キャンセルできる)。
  • 指定した代替テキストは保存されており、同じ非テキストコンテンツが再利用された場合に代替テキストが自動的にオーサリングツールによって提案されています。そしてその保存された代替テキストを編集または削除するオプションがあります。

WYSIWYG リッチテキストエディタでは代替テキストを確認できない

WYSIWYGリッチテキストエディタ

CMSの多くで採用されている WYSIWYG リッチテキストエディタでは画像の代替テキストを視覚的に確認することができません。WYSIWYG エディタは ATAG の対象とされています。

WYSIWYG エディタにおける画像挿入の課題は以下の2点に集約されると思います。

  • 画像挿入時における代替テキストの指定インターフェイス
  • 画像挿入後の代替テキストの確認、修正方法

WordPress の画像の挿入フロー

WordPress のファイルアップロードインターフェイス

さて、ここではCMSへの画像の挿入フローの例として、WordPress と Movable Type を取り上げます。まずは WordPress。最新のWordPress(4.4)では、投稿画面からメディアの挿入を選択した後、ドラッグ&ドロップで画像をアップロードできます(もちろんファイル選択してアップロードすることもできます。ドラッグ&ドロップのみではそれ自体が非アクセシブルになってしまいます)。

WordPress のメディア挿入インターフェイス

メディア挿入のインターフェイスでは「代替テキスト」の入力欄があります。アップロードした時点では、値は入っていません。唯一残念なのはまとめての指定ができない点でしょうか。選択状態の画像の代替テキストを選択状態を変えながら一つ一つ指定していくことになります。

コントロールキー+クリックでエディタ上から画像のプロパティを編集できる

エディタからコントロールキー+クリックで画像のプロパティを編集できます。一度指定した代替テキストは保存されており、次回同じ画像を挿入する際にも初期値として指定されており、このあたりはATAGに沿っていると言えます。

ATAGに照らし合わせて唯一問題となっている点は、代替テキストが空の時にファイルのbasename(拡張子を除いたファイル名)が入ってしまう点です。つまり、代替テキストフィールドが空の時、タイトルフィールドの値が入ってしまうのです。タイトル欄を空欄にすれば、alt属性は空になりますが、これは少々わかりにくい実装です。代替テキストというラベルのついているフィールドが空なのに、自動生成された値が入ってします。これはガイドラインに沿っていない点かと思います。

<img class="alignnone size-medium wp-image-16" src="http://localhost/wordpress/wp-content/uploads/2015/12/banner-sample-02-300x100.gif" alt="banner-sample-02" width="300" height="100" />

それでも、WordPress の画像の挿入に関する機能よく考えられている印象でした。

Movable Type の画像の挿入フロー

Movable Type のファイルアップロードインターフェイス

最新のMovable Type(6.2)では、投稿画面からメディアの挿入を選択した後、ドラッグ&ドロップで画像をアップロードできます(もちろんファイル選択してアップロードすることもできます。このあたりはWordPressと同じですね)。

Movable Typeの画像挿入インターフェイス

問題は次のステップです。 Movable Type の場合、アップロード後に各画像の「編集」をクリックして画像のプロパティを指定していかなければなりません。1点ずつ指定しなければならないのは WordPressと同じですが画面遷移が伴うだけひと手間多くかかります。また、ここで「挿入」ボタンをクリックしてしまうと、画像の代替テキストを指定することができません。

Movable Type の画像挿入インターフェイスの次のステップ。代替テキストの指定ができない。

貼り付け後、HTML編集モードにして代替テキストを指定することはできます。尚、Movable Type の場合、ラベルを空にすれば alt属性値は空になります。ここはガイドラインに沿った挙動と言えます。

尚、WordPressにあった、貼り付け済みの画像のプロパティをコントロール+クリックで再編集する機能は Movable Type にはありません(これについては後述します)。

PowerCMS の場合

最後に、PowerCMS の場合です。PowerCMS のベースエンジンは Movable Type ですから、基本的には Movable Type の画像挿入フローを継承していますが、代替テキスト指定については独自に機能を追加しています。詳細は以下の記事をご覧下さい。

PowerCMS の画像挿入インターフェース

また、WordPress にあって Movable Type にないエディタ上で画像のプロパティを編集する方法ですが、システム >PowerCMS設定 >TinyMCE設定で advanced_buttons1 に「image」を追加することでできるようになります。Movable Type でも plugins に「advimage」を追加し、「image」を追加することでできるようになります(この機能から代替テキストを修正した場合、この値を次回同じ画像を利用するときの推奨値として利用してくれない点は課題として残りますが)。

TinyMCE設定画面

エディタから画像のプロパティを編集できる

PowerCMS / Movable Type のオプションプラグインである PowerCMS 8341では別途「画像の検証」ボタンがあり、画像と画像の代替テキストを一覧化して表示できます。画面キャプチャのように、不適切な値(例:ファイル名)は指摘してくれ、この画面から纏めて修正を可能にしています。

PowerCMS8341の画像の検証画面

尚、PowerCMSではサイドバーへのドラッグ&ドロップで画像をアップロードする際に、日本語ファイル名を指定しておくと、拡張子を削除した日本語のファイル名が代替テキストとして登録される裏技? があります。

Authoring Tool Accessibility Guidelines 目線で CMSを再評価する

今年は MTDDC をはじめとして CMS夏祭り(東京/大阪)とかCMSを比較したり座談会のようなイベントに本当に多数呼んでいただいたのですが、ウェブアクセシビリティに関する質問をされたことは一度もありませんでした。CMS は ATAGで定義されているオーサリングツールに他なりません。こういった視点で CMSを再評価するような場があってもいいのではないでしょうか。他の CMS のエバンジェリストの方の見解も是非おきかせください。現場からは、以上です。

駄文です。大した記事ではありません(何のお断りだよ)。 なんか、こんなこと(クライアントにウェブアクセシビリティの重要性を理解いただくのが難しいとか何とか)を議論していた記憶があるのですよ。10年くらい前。理解いただいて、予算化するのが難しいとか何とか。

コーディングWebアクセシビリティ(書籍)

書籍「コーディングWebアクセシビリティ」を献本いただいてすいませんまだ読んでなくてこの記事と写真は直接関係ないのですが。何でこんなタイトルで記事を書こうと思ったかと言うと、ウチの会社は何のために存在して、何をすべきかを今年になってずっと考えていて、本当にずっと考えている中で今朝勝手に腑に落ちたからなのです。

俺たちがウェブアクセシビリティを重要視しているのだから、俺たちが選ばれる会社になればいいじゃん。

という結論に至ったのでした。マルチデバイス対応の予算はみていただけるようになったのだから、マルチデバイス対応へのアプローチ方法の中にウェブアクセシビリティを確保するプロセスを入れればいいし、優れたCMSを提供することもコストダウンに繋げられるし、制作力、製品力、あらゆる努力をして自分たちがお客様に選ばれる会社になって、自分たちが携わるプロジェクトが増えればそのサイトはアクセシブルになるではないか、という単純なことを考えて取り組めばいいのではないかと。

この辺りのことは、ミツエーリンクスさんが言っていることと考え方としては近いんじゃないかと勝手に思ったり。もしくはこの間の「アクセシビリティやるぞ!祭り」の話しとか。

名古屋でもアクセシビリティやるぞ!

4月20日(月)、名古屋でアクセシビリティをテーマにしたセミナーやります。無料です。たくさんの方のご参加をお待ちしています!

あと、アルファサードではデザイナー、フロントエンドエンジニアを募集しています。こちらも宜しくお願いします。

この記事は、Web Accessibility Advent Calendar 2014、4日目の記事です。

私の会社(アルファサード株式会社)で今年、PowerCMS 8341と Crawl という2つの ウェブアクセシビリティチェックツール を作りました(ColorTesterというコントラストチェックツールも作りました)。PowerCMS 8341 は Movable Type / PowerCMS のプラグイン、Crawl は OS X用のチェック機能を内蔵したブラウザです(非公開)。
すべてのソフトウェアの企画・検討から実装までを私が担当しましたので、今日はそのチェックロジックについて紹介したいと思います。もちろん、ここはこうであるべきではないのか? なんかのフィードバックをいただければ幸いで、今後も修正やアップデートを随時行っていきたいと考えています。

Crawl については、まだ公開していないのですが、下記の記事を書く際に利用しました。

ウェブページに対するチェックツールのチェック結果には差異がある?

他にも有償のもの、無償のものなどがいくつか存在するかと思いますが、何の言語で作られているかはともかく「検査のロジック」が同じであれば、結果は同じになるはずです。基本的には各ツールとも、HTMLソースやHTMLソースのレンダリング結果に対してチェックを行います。

ところが、必ずしも各ツールの検査結果は一致しません。JIS X 8341-3:2010(WCAG2.0)が規格である以上、同じ結果になるのが望ましいのでしょうが、お墨付きのついた検査のロジックが公開されているわけでもないので、やむを得ないことです(とはいえ、そんなに差異があるようにも見えませんが、ロジックが公開されていない以上、差がないとも言えません。ソースが公開されているものもあるので、ソース読めばわかるんでしょうし)。

公開されているロジック(最低要求仕様)としては下記のWAICのサイトのドキュメントがあります。

文字通り「最低要求仕様」とある通り、本当に最小限のことしか書かれていません。また、HTML5の登場や、最近の JavaScript を多用した動的な Web や WAI-ARIA などの新しい技術に対応するにはどうすればよいかなど、このドキュメントもそろそろ改訂が必要な時期にさしかかっているように思います。

コントラストチェックツールの検査ロジックは明確でツールによる結果の差は(基本的に)ない

また、HTMLに対するチェック以外にも、以下のようなコントラスト比のチェックツールがあります。

後者(ColorTester)は私が作成したのですが、コントラスト比については計算式が決まっているため、ツールによる差異はありません(正確には色空間の設定が影響するため、例えば OS X と Windows OS 等の差により微妙に異なることがあります)。

WCAG 2.0(W3C勧告)日本語訳 [原題:Web Content Accessibility Guidelines (WCAG) 2.0]

相対輝度

色空間内のすべての点の相対輝度。最も暗い黒を 0 とし、最も明るい白を 1 とする。

注記 1: sRGB色空間においては、色の相対輝度は、L = 0.2126 × R + 0.7152 * G + 0.0722 * B と定義されており、RG および B は以下のように定義される:

  • RsRGB <= 0.03928 の場合、R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

  • GsRGB <= 0.03928 の場合、G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

  • BsRGB <= 0.03928 の場合、B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

そして、RsRGB、GsRGB、及び BsRGB は、次のように定義される:

  • RsRGB = R8bit/255

  • GsRGB = G8bit/255

  • BsRGB = B8bit/255

^ という記号は、指数演算子である(計算式は、[sRGB] 及び [IEC-4WD]を参考にしている)。

ColorTester は背景色と前景色の推測というユニークな機能があります。推測のロジックについては下記の記事で紹介しています。

ColorTesterの背景色前景色の推測機能

ウェブページに対するチェック

さて、話しを戻します。HTML(ウェブページ)を元にチェックを行うロジックですが、PowerCMS 8341と Crawl では、以下のルールを元に、DOM操作で HTMLタグをパースして、チェックを行っています。Crawl のほうは WebKit のレンダリング結果に対してチェックを行う分、より正確な結果となります。PowerCMS 8341 においては CMS用のツールであるため、純粋にコンテンツ部分に対するチェックを行うことができる、管理しているコンテンツに対してエビデンスを残していける、などの特徴があります。

尚、実装にあたって私が心がけたことが一つだけあります。それは、できるだけ既存ツールが無条件に「人の手による確認が必要」とする項目についても、何らかのロジックで判定を行い、適合、N/Aとなる項目を増やす(というより、「確認」を減らす)ことです。何故か? 既存のチェックツールではエラーや警告はともかく、ここは人の手で確認してね、という項目がページごとに数十個(場合によっては数百)並ぶのです。ウェブアクセシビリティに造詣の深い、一部のコンサルタントや実装者でないと、実装も修正も適合判断もできない、という現実があるのかないのかわかりませんが、そういう現状があるのだとしたら、ウェブアクセシビリティの普及にはマイナスだと考えました。ここは、難しいところでもありますが。何よりも、ユーザーが不利益を被ってしまっては意味がありませんし。もちろん、異論反論あるでしょう。こいつはバージョン1.0。実際の利用者からのフィードバックなども随時反映していくつもりです。

また、各箇条について、チェック対象外、つまり適用しない項目を設定で指定できるようにしてあります。一部の項目については、設定によって厳しさのレベルを変えられるようにもしました。サイト固有の何か? がある場合はチェック結果の表示前にコールバックプラグインを追加してカスタマイズが可能です。

各箇条に対しOK、エラー、警告、確認、N/A(対象外)のいずれかを返します。frameもしくは iframe要素が存在する場合は、常に別途チェックを促します。

PowerCMS8341のレポート(その1)

PowerCMS8341のレポート(その2)

凡例

適合について評価可能
対象外(N/A)について判別可能
何らかのエラー、警告を表示可能
×常に確認を表示

等級A、等級AAに対応するチェックの基本的なロジック

細分箇条題名等級試験自動試験のロジック
A
7.1.1.1非テキストコンテンツAフォームのコントロールにラベルもしくはtitle属性がない(エラー)、フレームが存在する(確認)、Img、Input(type=image)要素にALT属性がない(エラー)、ALTテキストが空(確認)、ALTテキストがファイル名と一致(警告)、Object要素かEmbed要素がある場合(確認)、フォームの中に画像がある場合、CAPTCHAかどうかの確認を表示、いずれも見つからなかった場合、確認を表示。ALTテキストが空の場合に確認を出す、出さないについては設定で選択可能。別途、画像のALTのチェック画面で一括チェック済みの場合は、問題が見つからなかったことを表示。
7.1.2.1収録済みの音声しか含まないメディア及び収録済みの映像しか含まないメディアAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.2収録済みの音声コンテンツのキャプションAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.3収録済みの映像コンテンツの代替コンテンツ又は音声ガイドAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.3.1情報及び関係性A非推奨、廃止要素のある場合エラー。テーブルがある場合確認。いずれにも当てはまらない場合、確認(リストであるべき、などは確認できないため)。
7.1.3.2意味のある順序A×常に確認を表示。
7.1.3.3感覚的な特徴A×常に確認を表示。
7.1.4.1色の使用A×常に確認を表示。
7.1.4.2音声制御AObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.2.1.1キーボード操作Aonmouse〜属性のある要素にonkey〜が無い場合(onmouseoverに対するonfocus、onmouseoutに対するonblur指定がある場合を除く)に確認、そうでない場合、OK。
7.2.1.2フォーカス移動AObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.2.2.1調整可能な制限時間AScript要素及びイベント属性の指定がない場合N/A、そうでない場合、確認。<meta http-equiv="refresh">が存在する場合エラー。
7.2.2.2一時停止、停止及び非表示AScript要素及びイベント属性の指定があるか、Object要素とEmbed要素があるか、Gifアニメーションがある場合、確認、そうでない場合N/A。
7.2.3.13回の閃光又は閾値以下AScript要素及びイベント属性の指定があるか、Object要素とEmbed要素があるか、Gifアニメーションがある場合、確認、そうでない場合N/A。
7.2.4.1ブロック・スキップA見出し、もしくはスキップリンクがある場合OK、そうでない場合、エラー。フレームが存在し、title属性がないか、空文字の場合エラー、そうでない場合、確認。
7.2.4.2ページタイトルAtitle要素が存在し、空文字でない場合、確認。そうでない場合、エラー。
7.2.4.3フォーカス順序Atabindex属性の有無を確認し、指定があれば確認、そうでない場合、N/A。
7.2.4.4文脈におけるリンクの目的AA要素の内容が空の場合、Area要素のALTテキストが空もしくは属性がない場合、エラー。そうでない場合、確認。target属性の指定がある場合、確認。オプション設定でリンクテキスト=URLの場合に警告を出す、出さない、target属性の指定がある場合、確認を表示する、しないを選択可能。
7.3.1.1ページの言語Ahtml要素にlang属性もしくは xml:lang属性が無い場合、エラー、ある場合に確認。
7.3.2.1オンフォーカスAonfocusイベント(属性)の指定がある場合、確認、そうでない場合、N/A。
7.3.2.2ユーザインタフェースコンポーネントによる状況の変化Aフォームがない場合、N/A。フォームコントロールにイベント属性の指定が無い場合、N/A。フォームに送信ボタンがない場合、警告。そうでない場合、確認。
7.3.3.1入力エラー箇所の特定Aフォームがない場合、N/A。フォームがある場合、確認。
7.3.3.2ラベル又は説明文Aフォームコントロールにラベルがない場合、確認(ラベルもしくは説明があるか)。そうでない場合、N/A。
7.4.1.1構文解析ADoctype指定があり、htmlである場合、OK、そうでない場合、確認、指定がない場合エラー。id属性もしくはaccesskey属性の重複がある場合、エラー。
7.4.1.2プログラムが解釈可能な識別名、役割及び設定可能な値AScript要素及びイベント属性の指定がある場合、確認、そうでない場合、N/A。
AA
7.1.2.4ライブの音声コンテンツのキャプションAAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.5収録済みの映像コンテンツの音声ガイドAAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.4.3最低限のコントラストAA基本的には常に確認を表示。別途画像のチェックですべての画像に適合フラグもしくはN/Aとなっている場合、OK。
7.1.4.4テキストのサイズ変更AA×常に確認を表示。
7.1.4.5画像化された文字AA画像がない場合、N/A、そうでない場合、確認。別途画像のチェックですべての画像に適合フラグがついている場合、OK。
7.2.4.5複数の到達手段AA×常に確認を表示。
7.2.4.6見出し及びラベルAA見出しがない場合、警告、そうでない場合、確認。
7.2.4.7視覚的に認識可能なフォーカスAA×常に確認を表示。
7.3.1.2部分的に用いられている言語AAhtml要素以外にlang属性が存在する場合、確認を表示。
7.3.2.3一貫したナビゲーションAA×常に確認を表示。
7.3.2.4一貫した識別性AA×常に確認を表示。
7.3.3.3入力エラー修正方法の提示AAフォームがない場合、N/A。フォームがある場合、確認。
7.3.3.4法的義務、金銭的取引、データ変更及び回答送信のエラー回避AAフォームがない場合、N/A。フォームがある場合、確認。

7.1.4.3、7.1.4.5については、別の画面(アイテムの管理)画面で人の手によりチェックを入れることができるようになっており、そこを経てからチェックすることで「適合」判定が可能としています。正確には機械チェックで判別可能な項目、とは言えないかもしれませんが、ソフトウェアとして適合するためのインターフェイスやフローを提供しているということで◎(適合について評価可能)としています。7.1.4.3については、ColorTester と同様の機能をウェブアプリ内に実装しており、自動及び手動でのコントラストチェックが可能です。

7.2.4.1など、いくつかの項目については、PowerCMS 8341ではテンプレート側で担保することが前提です。PowerCMS 8341ではウェブページや記事については検証範囲を限定してチェックするので、これらの項目はほぼすべてのケースで適合となります。

判りやすい突っ込みどころとして、applet要素であるとか、bgsound要素とか、そういうのがない、ってのはありますよね。これらに対応していないのは、単に「もういい加減えーんちゃう? 見たことないわ」という理由なんですが、必要なら組み込んでいこうとも思います。ちなみに、ページ内で使われているタグを一覧化する機能、使われているタグによってページを検索する機能があります。

また、「HTML5の登場や、最近の JavaScript を多用した動的な Web や WAI-ARIA などの新しい技術に対応する」チェックとしては、このロジックでは不完全です。とはいえ、ウェブアクセシビリティ対応が急がれる官公庁や自治体においてそのような技術が用いられることは現段階では稀であり、こういったシンプルなロジックで検査することで対応負荷を下げられるのなら、このロジックには相応の価値があるのではないかと考えます。ロジックさえはっきりできれば、Perlモジュール化するとか、オープンソースのライブラリ化されるかとかで、恩恵を受けられる人も増えるかもしれません。

何かくどいくらいしつこくなりますが、違った見方やこういうケースどうすんの? ってのはあると思います。建設的な議論のたたき台になれば嬉しく思います。

CMSならではの、工夫

PowerCMS 8341 においては、CMSならではのいくつかの面で工夫しました。長くなりますのでここでは割愛しますが、ご興味のあるかたは下記の記事をごらんください。

さて、未来に向けて

仮にも私は有償ツールの提供元でもありますが、クローズドに各社が開発してツールごとに異なる結果となるよりも、こういうドキュメントを公開することで各ツールの検証結果の差異がなくなっていくことで、サイト運営者も、制作者も判断に迷うこともなくなるのではないか。 いまだにこの手のツールの紹介セミナーで「競合他社お断り」というケースも見られますが、ここはオープンにやっても良いのではなかろうか。この記事は1人のツール開発者からの提案でもあります。

で、今度さ、「ウェブアクセシビリティチェッカー開発者バトル」ってイベントを企画して、是非呼んでください!

ってことで、アクセシビリティやるぞ! やるぜ! 会場向かうぜ! (まだ早いか!)宜しくお願いします。

追記(12月4日16:10)

実際に大量のページをチェックしてると、あ、これあかんやつや、ってやつが見つかるもので、例えばページ内にある複数のリンクテキストが同一で遷移先URLがバラバラなものとか、これは機械判別できるな、これ 7.2.4.4 だな、とか、そういうのが日常的に見つかっていくわけで、追加機能要望や気づいた点を開発者へフィードバックできる機能とか(PowerCMSには管理画面からサポートフォームへ投げる仕組みがあるけど)も有用ではないかな、と思ったりしました。

あと、先週の MTDDC Meetup TOKYO 2014 で話したツール開発の Making のスライドも宜しければあわせてどうぞ。

さらに追記(12月4日16:45)

という「エア」ツッコミがあったので、以下のような機能を提供していることを追記しておきます。

で、このツッコミで思い出したのですが、この手のツールをつくるときに「褒めて伸ばすツール」という考え方をしました。つまり、このリンクテキスト同一云々の件は、こんな箇所があるよ? 確認してね。というメッセージを出すとして、逆になかったら「こういう問題箇所は見つかりませんでした!」的なメッセージを入れるというものです。褒めてくれるツールの方が、さわってて心地いいやん。ということです。

チェックツールを作っていると、いかにエラーを見つけるか指摘するか、という思考になってしまいがちなんだけど、いいところは敢えて褒めてあげよう、ということです。俺も成長したもんだ(違)。

スライドできました。Making of PowerCMS 8341 というテーマにしました。ツール自体の紹介はセミナーがあるので、今日はその裏話的なものにします。

それは本当に実現不可能か?~Something Different for the Best Web Solution~

というタイトルが掲出されているんですけど。でもちょっとわかりにくかったかなセッションタイトルが、と思ってさ。

Webに関わる人、会社の立ち位置はそれぞれに違いますが「もっと上手くプロジェクトを回したい」「製品やサービスをヒットさせたい」「競争力を高めたい」「もっと利益を上げたい」といった思いは共通ではないでしょうか? 一方で「毎回同じことの繰り返しをしていないか?」「労働集約的にリソースつぎ込んで解決しようとしていないか?」「もっとスキルやリソースに余裕があれば...」といった課題・悩みを抱えている方も多いと思います。 普段、CMSの機能に関する企画から実装、提案・導入支援までを幅広く行っていますが、いつも頭の中にあるのは「もっと違うやり方がないか?」「"あたりまえ"を"あたりまえ"で終らせて思考停止していないか?」という疑問です。 本セッションでは、Movable Type や PowerCMS を素材として、機能をデザインした背景や現在開発中のいくつかの製品の管理画面をお見せしながら、製品企画の背景や考え方についてご紹介します。

スライドの一コマ。AppleやGoogleにできて、俺たちにできないってのか? そのうち、奴らに仕事奪われるぞ全部。

実現できる...

この記事はサイトの善し悪しやリニューアル内容の是非について述べたものではありません。また、筆者が所属するいかなる団体・会社の意見でもなく、あくまで個人の見解であることをのっけからでっかい文字で表明しておきます!

色々な方が所感を述べられていますが、アクセシビリティについての言及があって何だか物議を醸しているようなので、実際どうなのかを確認してみようと思ったのです。忙しいので、機械任せです。自分の所感はひとこと、ふたことにとどめます。とどめます。とどまるのか? とどめよう。

W3C Markup Validation Serviceの検証結果

Crawl というOS Xで動作する自作の検査ツールでチェックしてみた

以下の検証結果、レポートはすべて Crawl(サイト評価の機能を持った自作のWebブラウザ)を用いました。検査したいページを開いて、メニューまたはキーボードショートカットで様々なレポートを作成してくれます。検査のロジックは? 自分で決めて自分でコード書きました。なので、自作自演? です。結果が正しいことを保証するものではありません。

え、miChecker ? あ、ありましたねそんなツール。そっちでのチェックは誰か他の方がやってください。

Crawlの検証結果表示画面のスクリーンショット

Crawl によるアクセシビリティチェック(JIS-X 8341-3:2010に基づく検証結果) 等級A/等級AA

Crawl による画像評価

img要素のalt属性の一覧と、ウチの会社で公開している ColorTester による背景色と前景色の自動チェックの結果を一覧化したものです。色の抽出に関するロジックはこちらの記事で紹介しています。つまり、こいつも自作自演です。結果が正しいことを保証するものではありません(しつこい)。

Crawl によるリンク評価

リンクテキストとそのリンクのリンク切れチェック、遷移先のページの title要素を一覧化したものです。ひとつまえの画像評価とあわせてみるだけでも深刻な問題を見つけやすいのではないかと思います。

所感

細かな検証はしていません。すいません忙しいのだ。でも、画像の alt属性値を眺めるだけでわかることもあるよ。Data_data_panel_100とか、tags_thumb_asia2、tags_thumb_outreach2(このあたりはCMSなのかツールなのかが自動的に入れたテキストっぽい)とか、141114_早慶戦(これはまだマシか)とか、そういうのが残っている。

ってことは、つまり、あれだ。少なくとも JIS-X 8341-3:2010 の AとかAAとかに準拠させようとか、そういう意図はなかったと思われる。外野からの憶測にすぎませんが。画像の alt以外は何もいいません。細かく検証もしてないし、並べたのはあくまでも機械「しかも自作」のツールですから。結果が正しいことを保証するものではありません(超しつこい)。

画像評価レポートの一部スクリーンショット

ツールでどこまで検証できるのか

HTML5とか、JavaScript使いまくりで動的に altを突っ込んでるだ、とか、正直そこまでいくと現状のチェックツールはまだまだついていっていないとは思います。CrawlについてはWebKitがレンダリング済みのHTMLをDOM操作で評価していっているので、そんなにはずれはないと思いますが、空の見出し、空のリンクテキスト、ファイル名から生成された alt属性値なんかはわかりやすいアクセシビリティ上の問題になりますので(以下略)

ツールのロジックについては、Web Accessibility Advent Calendar 2014 - Adventarに登録しているので、その際に書いてみたいと思います。

宣伝

12月8日(月)、東京でビジネスセミナーやります。参加無料で、且つ、私はツールの話しをしますが、植木さんや長谷川さんの話しがきけるだけでも来ていただく価値があると思うので、ご都合あう方は是非お越し下さい。

現場からは、以上です!!

続きます。

前回は、「色の利用」について取り上げました。もう一つ、WCAG、JIS X 8341-3:2010には色(というよりも正しくはコントラストですが)に関する項目があります。

1.4.3 最低限のコントラスト: テキスト及び画像化された文字視覚的な表現には、少なくとも 4.5:1 のコントラスト比をもたせる。ただし、次の場合は除く: (レベルAA)

  • 大きな文字: サイズの大きなテキスト及びサイズの大きな画像化された文字には、少なくとも 3:1 のコントラスト比がある。

  • 付随的: テキスト又は画像化された文字において、次の場合はコントラストの要件は該当しない。アクティブではないユーザインタフェース・コンポーネントの一部である、装飾だけを目的にしている、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。

  • ロゴタイプ: ロゴ又はブランド名の一部である文字には、コントラストの要件はない。

AAAの場合はさらに厳しくて、7:1のコントラスト、大きな文字で4.5 : 1 のコントラストを確保すること、とされています。

この、コントラスト比の計算方法はWCAGのサイトで公開されています。計算方法をここでご紹介する意味はあまりないと思うので詳細はリンク先を参照ください。

チェックはどうするかというと、コントラストの計算を行うソフトウェアがありますので、そういったものを使うのが一般的です。最も有名なのはColour Contrast Analyser (CCA)でしょう。アルファサードでも、ColorTesterというフリーソフトを公開しています。

JR新大阪駅の新幹線電光掲示板

JR新大阪駅の電光掲示板

写真の撮り方によりますし、正確な数字ではないことをお断りしておきますが、写真から色を拾ってColorTesterのチェックにかけてみました。

ColorTesterのテスト結果

文字のどの位置かによって結果は異なりましたが、概ね 2.5 : 1 から 3.0 : 1。3.0 : 1 だと「大きな文字」でぎりぎり適合ということになります。ウェブの場合は(WCAGで)「18 ポイントのテキスト又は太字で 14 ポイントのテキスト」が大きな文字とされています。(WCAGで)「18 ポイントのテキスト又は太字で 14 ポイントのテキスト」が大きな文字とされています。JIS X 8341-3:2010では「日本語を含む場合、少なくとも22ポイント又は18ポイントの太字」と追記されています。

電光掲示板はリアルなサインですから、距離によって文字の大きさは変わってみえるので(遠くから見たら当然文字は小さく見えるし、確度によって太さの見え方も異なるでしょう)一概にどちらの数字を適用したらいいかを述べることはできませんが、少なくとももう少しコントラストを確保したいところです。ちなみに、「こだま」の青色は4〜4.5 : 1確保できていますので、大きな文字においては「適合」です。

ちなみに「のぞみ」は 10.0 :1以上のコントラストが確保されており、「適合」です。

新大阪駅の電光掲示板。のぞみの表示

参考 : このページに掲載されている写真だと、「こだま」はもう少し明るい色になってますね。「ひかり」は相変わらずに見えます。

間もなくクリスマスですね! (違)

少し涼しくなったと思ったら、街にはクリスマスツリーが出現したりして近頃は気が抜けませんね。ツリー、サンタといえば、グリーンと赤色。この組み合わせが識別しにくい人がいるよって話しは先のエントリーに書きましたが、以下の画像の背景色と前景色のコントラスト比は、1.1 : 1 / 2.2 : 1 で、これらは普通の文字、大きな文字ともに不適合です。但し、後者の写真は背景と文字の間に白い縁取り線があります。こうすれば「適合」となる例ですね(ちなみに、この写真は少し古い写真で、現在これがこのまま残っているかはわかりません)

自動販売機の上「本日分」の表示。グリーンの上に赤い文字が重なっている     同じく「本日」前売」の表示。同じ色合いだが、白い縁取りがある

ウェブの場合は、テキスト化することで配色を変えられる可能性がある

AAには、この項目と関連して、以下の達成基準があります。

1.4.9 画像化された文字(例外なし): 画像化された文字は、装飾だけを目的に用いられているか、その情報を伝える上でテキストを特定の形で表現することが必要不可欠である。 (レベルAAA)

注記: ロゴタイプ(ロゴ又はブランド名の一部である文字)は必要不可欠なものであるとみなす。

色を変更する方法と見え方については、OS XでもWindowsにも「アクセシビリティ」の設定があって、そこから変更できます。また、画像化された文字を使わなければ、ブラウザ上でテキストを選択したり、エディタにコピペしたりしても読むことができます(私は、表はExcelにコピペしてスクリーンリーダーで読むねん、という人を知っています)。以下のブログ記事もぜひお読みいただきたいと思います。

上記の記事をお読みいただくことでお感じいただけると思います。アクセシビリティは結構身近なものですよ。

他の箇条の話しで続けたかったのですが、今朝移動している最中にひとつ好例? を見つけてしまったので一昨日の続き。アクセシビリティの試験や評価をするとき、私は評価や試験はそんなに難しくはないという派?なんですけどね、事例の引き出しを増やしておくこと、経験しておくことが問題の発見を素早くするということは言えると思います。

御堂筋線、大国町の次は、何駅だ?

ちょっとコントラストを変えているのはインチキであることは告白しておきます。以下は大阪市営地下鉄の路線図をグレースケールにしたものです。縦、ほぼ中央の線が御堂筋線。新大阪から市内中心部へ向かう線です。ウルフルズが大阪ストラットで心斎橋行きの〜って歌にしている、あれです(よく考えると心斎橋行きの切符っておかしな表現ですな)。

大阪市営地下鉄の路線図をグレースケールで見た時

本町→心斎橋→なんば→大国町、と来て、次は何駅だ?何駅でしょうか?花園町?に見えるわな。これ。さて、正解は色のわかる人は下記のオリジナルの写真でわかることでしょう。正解は動物園前、となるのでした。

大阪市営地下鉄の路線図。通常のカラー表示

18時12分追記、改良案

最近イラレとかインストールしてないのでなんちゃってな線でごめんなさい。この大国町駅あたりに限って言えば、四ツ橋線をちょっと手前でくいっと曲げてやって、御堂筋線のX座標とちょいズラしてやればずいぶん理解しやすくなる筈です。もっと簡単な対応としては線の太さを変える、という方法もとれますね。

大阪市営地下鉄路線図-修正案

18時47分追記、もひとつ追記

中村さんにご指摘いただきました。Y16/M21(大国町)、Y17(花園町)、M22(動物園前)てのが併記されているので、正確には色だけには依存していないと。確かに。

カラーユニバーサルデザインという考え方

東京メトロの路線図をカラーユニバーサルデザイン(CUD)に対応させたものが、少し前に話題になっていました(良い例で)。東京メトロの路線図ではありますが、福島県のページによくまとまっていましたのでこちらを紹介しておきます。

カラーユニバーサルデザインガイド CUDの具体例(路線図)です - 福島県ホームページ

福島県ホームページのカラーユニバーサルデザインガイド
  • 各路線特有の色を保ちながら見分けやすい色相を選択
  • 線は太くして色の面積を充分にとる
  • 路線が交差する箇所に境界線を設ける
  • 色弱者が見分けにくい線に、一般色覚者が気にならない程度のハッチングを加える
  • 線上の路線名や凡例の色名などの情報を追加

カラーユニバーサルデザインに対応した路線図がこのページで紹介されています。

カラーユニバーサルデザインに対応した路線図の例(福島県ホームページより)

問題となりがちな箇所についての経験則を蓄積しておく

富士通のページ(7.1.4.1 色の使用に関する達成基準 : 富士通)では、グラフの凡例における問題の例が示されています。

地図、グラフには1.4.1に関する問題が混入しやすいので注意しようね、というお話でした。

ぼさっと歩いてんじゃなくて、街の中にも考えるヒントはいっぱいあるよ、と。

10月4日にCEATEC JAPANに行ってきました。目的はこれ。

セミナーの内容については主に社内にリアルタイムツイートしていたので、また機を見て纏められればと思いますが(最近筆が重くなっとる...)、幕張からオフィスへの帰り道中に見たもの、考えたものについてちょっと面白い? というかアクセシビリティを考える上でヒントになる出来事がありましたので書いてみます。

達成基準 1.4.1 を理解する | WCAG 2.0解説書

1.4.1 色の使用: 情報を伝える、何が起こるか又は何が起きたかを示す、ユーザの反応を促す、もしくは視覚的な要素を区別する唯一の視覚的な手段として、色だけを使用しない。 (レベルA)

注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的な表現のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3で網羅されている。

この説明、難しいなぁっていつも思ってるのですが、これは例がないということもあります。富士通さんのサイトの解説なんかは例示がされているため、よりわかりやすいと思います。

でも、街を歩いてるときにもヒントがあります。私はいつもここを通るたびに思うのですが、京葉線の東京駅から東京駅の中心部?地下鉄の駅に移動してるときに「歩く歩道」ありますよね?

京葉線の歩く歩道の上に表示されているカラーサイン

これ見てガイドラインの 1.4.1 ? とか思った人。職業病です!(笑)

そもそもが赤や緑って識別できない人が多い組み合わせでもありますが。

ただ、1.4.1 が示しているのは、何色かということではないです。

情報を伝える、(中略)もしくは視覚的な要素を区別する唯一の視覚的な手段として、色だけを使用しない

「緑」が通行可、「赤」が通行不可、ということを「情報を伝える唯一の視覚的な手段」となっているため、これは不適合ではないか、ということになるわけです。

色、+何か。

では、これをクリアするにはどうデザインすれば良いか。

MacOS Xのウィンドウのツールバーボタン

この画像はMacOS Xのウィンドウのツールバーボタンですが、色+形を併用しています。OS Xがリリースされたときは確かこの形での識別ができなくて後から追加されたように記憶しています(ちょっと検索してみましたが見つけられなかったのですが)。

京葉線東京駅のこの歩く歩道の上部のサインでは、赤い方に「×」を加えるか形を変えることで 1.4.1 へ適合することができます。もちろんWebにおいては画像の altテキストを正しく記述することを忘れずに。

そもそも「赤」が通行不可ってのはどこから来ているのか

ついでに、せっかくなのでもう少し深堀りしてみましょう。赤色が通行不可ってのはどこから来ているか。普通に考えると「信号」ですわね。青(緑)は進んで良い、赤は通行不可。

信号機の画像

そこから考えると、冒頭の京葉線のあるく歩道(京葉線じゃないけど、もう「京葉線のあるく歩道」で統一する(遅い! )の緑と赤の位置は左右逆ですね。 もし位置関係が逆だったら、色+位置で表現しているということであり、許容されるという解釈も成り立つのかもしれません。

東京メトロの路線を示すサインは、色+アルファベット

赤い丸=丸ノ内線、青い丸=東西線、このサインも昔は丸印だけでしたけど、丸の中にMとかTとかつくようになりましたね。これも同じです。色+文字ということです。

東京メトロの案内サイン

京葉線からJR東京駅構内を通り過ぎて地下鉄へ。これは1.4.1 とは関係ないですが、ふと足下を見れば階段の前後に視覚障害者誘導用ブロックがあります。

視覚障害者誘導用ブロック

意識しながら街を歩くことで、気づくことが色々あります。

でね、こんな感じで、1.1.1から全部シリーズ化して連載しませんか? (誰) わかりやすく理解が進むことで、JIS X 8341-3やウェブアクセシビリティが怖くない人が増えれば、と思うので。

昨日公開したColorTester、もうお試しいただけましたでしょうか? JIS X-8341-3適合の試験なんかをやっている方は是非お試しください。

ColorTesterスクリーンショット のサムネイル

同様のチェックを行えるツールとして、Colour Contrast Analyser (CCA) というソフトウェアがあります(有名ですね)。

もちろん、既にチェックソフトがあるのに作ったのにはわけがあるのですが、それはそれとして、せっかくなのでメモがてらに色の判別方法について記載しておきます。

W3Cのコントラスト計算アルゴリズム

達成評価についてはW3C(WCAG 2.0)の計算式そのままです。もう、コピペの世界ですね。

検証

チェックポイント

  1. 以下の公式を用いて、各文字(すべて同一ではない限り)の相対輝度を測る:

    • 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合のR, G 及び B は:

      • RsRGB <= 0.03928 の場合:R = RsRGB/12.92、それ以外の場合: R = ((RsRGB+0.055)/1.055) ^ 2.4

      • GsRGB <= 0.03928 の場合:G = GsRGB/12.92、それ以外の場合:G = ((GsRGB+0.055)/1.055) ^ 2.4

      • BsRGB <= 0.03928 の場合:B = BsRGB/12.92、それ以外の場合:B = ((BsRGB+0.055)/1.055) ^ 2.4

      また、RsRGB, GsRGB, 及び BsRGBは以下のように定義される:

      • RsRGB = R8bit/255

      • GsRGB = G8bit/255

      • BsRGB = B8bit/255

      "^"記号は指数演算子である。

    注意:エイリアス文字では文字の端から2ピクセルの部分の相対輝度の値を使用する。

  2. 同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。

  3. 次の公式を用いて、コントラスト比を算出する。

    • (L1 + 0.05) / (L2 + 0.05)

      • L1は前景または背景色の明るい方の相対輝度である。及び、

      • L2は前景または背景色の暗い方の相対輝度である。

  4. コントラスト比が4.5:1と同じ、又はそれ以上である。【訳注:この計算式を用いているチェックツールで、コントラスト比が4.5:1以上であることを確認すればよい。】

Colour Contrast Analyserについて特に不満がある訳ではないのですが、以下ことは思っていました。

  • OS X版ではOS標準のカラーピッカーを使うため、カラーピッカーを起動してからディスプレイの色選択まで、1アクション多い(Windows版では直接色を拾えるようになっています)
  • 画像から直接色を拾えないものか。その方が絶対楽だし、大量の画像を一点ずつ色選択してチェックって、数万ページの案件のチェックとかだと現実的に膨大な作業量になる

ColorTesterも標準設定ではOS標準のカラーピッカーを使うようになっていますが、設定→「OS標準のカラーピッカーを使う」チェックボックスをOffにすることで、直接画面から色を拾えるようになります。今のところマルチディスプレイには非対応であることと、Windows版では画面の解像度設定によってうまく色が拾えないことがあります。その場合Colour Contrast Analyserでもずれるんですよね。うまく拾えない場合、Colour Contrast Analyserでもカーソル位置からずれてしまう場合は、画面解像度の設定を変更して試してみてください。

お試しいただけるとわかるかと思うのですが、ブラウザからのドロップやファイルドロップでの色取得、それなりにうまく取得できているように思いませんか? でも、ドキュメントにも書いていますし最初の自動判別時にダイアログが出ることからもお分かりの通り、自動取得した色は正確ではない可能性があります。

色選択の際に最初に表示されるダイアログ

そもそも、2色しか拾えない訳ですから、前景色や背景色が明らかに複数の色で構成されている画像などでは取得に失敗します。明らかに拾い間違っているように見えるときは、あきらめてカラーピッカーから直接色を拾ってください。

ColorTesterはどうやって画像の背景色と前景色を判別しているのか

さて、本題です。
実際、トライ & エラーを繰り返しながら調整していったということなのですが、結果的に現在のバージョンでは以下のような考え方、アルゴリズムで判別を行っています。

  1. 一定以上の大きさの画像は画像サイズを小さくする(処理速度の問題)
  2. 近似色を丸める(グラデーションなどが用いられていると、不必要に色の数が多くなり判別が難しくなる)
  3. 画像のピクセルのカラーを調べて、どの色が何ピクセルを占めているかを調べる(keyに色(16進)、valueにピクセル数という形でマッピングしていきます)
  4. 一番面積の大きい画像が、背景色(これは、ほぼ問題ないかと思います)
  5. 問題は前景色です。まずは、二番目に面積が大きい色を前景色と仮定します。
  6. 背景色と、仮定した前景色のコントラスト差を求めます。これは、W3Cの計算式をそのまま使っています。
  7. コントラストの差が大きい場合(3以上としました)、仮定した前景色で決定です。
  8. コントラストが3以下の場合、面積の大きい順から色を調べて行き、一定のコントラスト差がある色を探します。但し、一定のピクセル以下の面積のもの(1ピクセルがその色だったとして、それが前景色ってことはないでしょう)は除きます。

というわけで上記の処理の結果、背景色と前景色を推測しているというわけです。色を丸めている点で、これはあくまでも近似色である、という見方もできるかと思いますが、どのみちディスプレイの色ってのはデリケートな要素が絡むものです。MacとWindowsでも違う値になるものがあります。Webセーフカラー! 何という懐かしい言葉の響き。ColorTesterでは16進の入力フィールドの背景色に取得した色セットしますから、試験の際に、もし自分の感覚とずれていたら念のためピクセルから取得した色で再チェックをお願いします。

その他のアイデア

正確さもさることながら、いかに効率よく背景色と前景色を判別するか、実装を考える上でいくつかのアイデアを試しました。

中央の1ピクセルを横になめていってはどうか?

上下中央のピクセルをなめる

横書きなら、これは有効なんですけどね。縦書きの画像だと、拾い損ねる可能性がありました。こんな画像だったらいいんですけどね。

斜めではどうか?

斜めにピクセルをなめる

縦書きでも横書きでも、これならクリアできそうですね。ただ、背景色についてはグラデーションかかってたりすると正確に取得できないのですね。また、上下左右の余白が広い場合にうまく行きません。もちろん、こんなべた塗り前景色一色の画像なら判別できるのですが。

他にも、隣接しているかどうかを判断基準に加えたり、ノイズを除去したりといったことも考えられますが、少なくとも「画像化された文字」の判別に特化するなら、あまり気にしなくても良いようです。 まぁ、単純にこういうのって面白いです。良いアイデアや良いアルゴリズムがあれば教えてください。

JSONを返すAPIチックなものを作ってMTのプラグインも作った。詳細は"あっち"のブログに書きました。

HTML Tidy Gateway トップページ

でことで、こっちのブログでは実装にまつわるメモ。

Perl CGIで書いた。CGIモジュールとHTML::Templateを利用。

MT以外のPerl自体何だか久しぶりだったのですが、MT利用なし、DB接続のないCGIがこんなに軽いものだとは...

#!/usr/bin/perl
use strict;

my $tmpl_dir = '/path/to/tmpl/';
my $this_url = 'http://altstyle.alfasado.net/html-tidy-api.cgi';

use CGI;
my $query = new CGI;
$tmpl_path = File::Spec->catfile( $tmpl_dir, 'html-tidy-api-bootstrap.tmpl' );
my $template = HTML::Template->new( filename => $tmpl_path );
print $query->header;
$template->param( FORMURL => $this_url );
print $template->output;

HTML::Template、MT3まではMTの管理画面で使われてましたね。非常にシンプルです。TMPL_VAR、TMPL_IF、TMPL_UNLESS、TMPL_LOOP が使えます。

<TMPL_VAR NAME="FORMURL" ESCAPE="HTML">

<TMPL_IF NAME="HAS_ERROR">
    <TMPL_LOOP NAME="ERRORS">
        <TMPL_IF NAME="FIRST"><ul class="list-group"></TMPL_IF>
            <li class="list-group-item" style="list-style-type:none"><i class="icon-pencil"></i> &nbsp; <TMPL_VAR NAME="MESSAGE"></li>
        <TMPL_IF NAME="LAST"></ul></TMPL_IF>
    </TMPL_LOOP>
<TMPL_ELSE>
    <p><i class="icon-pencil"></i> <TMPL_IF NAME="JAPANESE"><TMPL_VAR NAME="NO_ERROR_JAPANESE"><TMPL_ELSE>No error was found.</TMPL_IF></p>
</TMPL_IF>

ループの指定は以下のような感じで。MTの vars のセットなんかと似ているというか、元々これだったんですものね。

my $i = 0;
for my $error ( @errors ) {
    my $line = { MESSAGE => $error };
    if (! $i ) {
        $line->{ FIRST } = 1;
    }
    $i++;
    if ( $i == scalar( @errors ) ) {
        $line->{ LAST } = 1;
    }
    push ( @messages, $line );
}
$template->param( ERRORS => \@messages );

ただ、MTのテンプレートエンジンなんかと比較すると、テンプレートで使っていない param を突っ込むとエラーになるとか、緩さはあまりないです。

Twitter Bootstrap + google-code-prettify

デザインはTwitter Bootstrapを使いました。検証結果のHTMLに行番号とか付けるのには google-code-prettify を使いました。検証結果から該当行へリンク貼るところは、HTML Tidyの行番号から割り出して正規表現でゴニョゴニョしてます。

Web Accessibility Advent Calendar 2013の21番目の記事です(今年は3つ4つもAdvent Calendarに登録してしまった...)。

のっけからいきなり言い訳がましくて恐縮ですが、僕はここで取り上げるような新しい技術やアイデアは素晴らしいと思います。素晴らしいと思うだけに、このような新技術やアイデアを実現する人、あるいは利用する人に少しだけ考えて欲しいと思い、この記事を書きます。

新しい画像認証 - Copy

1つめ。画像認証の代わりになる「Capy」というサービス。知ったのは以下のニュース。提供元のサイトはこちら(Capy - 低コストで導入も簡単な不正ログイン対策)

ひとことでいえばジグゾーパズルの1ピースをドラッグしてはめ込むことで人間が認証しているということを判別するようなしくみです。

Copy の画面キャプチャ。メールアドレスとパスワードに加え、ジグゾーパズルのピースをはめるようになっている。

そもそも「画像認証」自体のアクセシビリティがどうなの? という話しもありますが(最近は音声再生ボタンがついているものも増えましたね)、この技術も同じく例えばスクリーンリーダーだったらどうするとか、そもそもこの画像のALTをどうするのかといった問題があると思うのです。以下のページはテキストタイプのデモですが、こういうJavaScript不使用タイプを用意しているあたり、古いブラウザのことや携帯電話なども考慮している姿勢が伺われます。だからこそ、画像のALT属性自体がないのが少し残念だし、代替手段でもユニークなアイデアを示せなかったのかな、と思います。

<img src="https://www.capy.me/gimpy/get_image/?captcha_key=GIMPY_DYHMCon5dyigDx99vbK1iEQLYm5cTT">

例えば、誰もが知っている、わかるであろう質問をクイズで音声で出題して、回答を入力するとかのアイデアはいかがでしょう? 簡単な算数とか常識問題とか。もちろん既存の音声ボタンを代替手段として付けてもいいと思いますし。

ひとつ大切なことは、アクセシビリティというと、すぐにスクリーンリーダーや音声ブラウザのことを想像する人が一定いるように思いますが、このようなドラッグ&ドロップでの細かいマウス(今やマウスとは限りませんが)前提の動作というのは、肢体不自由のユーザーにもバリアになります。これ、技術的なチャレンジという点でいえば視覚障害者対応ということ以外にキーボード操作(←→↑↓)で動かしてはめ込めると素敵じゃないかな(面倒ではありますが)。

これに限らないですけど、逆の意味で例えば電話の音声案内限定のやつとか、そういうのも考慮が必要ですね。

新しい電子チケット - ColorSync

2つめ。Peatix の全く新しい電子チケット方式「ColorSync」(以下の記事より引用)。

動画を貼っておきます。

素晴らしいアイデアだと思います。そう、思うんですが色によっては識別できない人がいる可能性があるということも考えると、数字を併記するとか(記号が良いかな...どっちにしても色+形で識別できるようにしたいところ)、そういう実装も考えてみて欲しいとも思います。人によると思いますが、多分、この動画を見る限りは識別できるんじゃないだろうかと想像しますけど、これを使う前提のバイトの面接とかだと、自分が色の識別が他人と違うと認識している人は尻込みしてしまうかもしれないですし。

あと、これも見落としがちなのが以下の話し。いわゆるポケモン・ショックですね。

光過敏性発作の疾患のある利用者は、閃光を放つ視覚的なコンテンツによって発作を引き起こす恐れがある。ほとんどの利用者は、発作が起こすまでは自分がこの疾患を持っていることに気づいていない。

JR東日本の静止画の配信

3つめ。これは、技術的に新しいというわけではないけれど、アイデアの勝利。でも、これやるなら、音も拾って配信しよう。写真は現在の技術では読み上げられない。時間が解決するとは思うけど。写真中の文字、そのうち読めるようになるだろうけど(OCR技術が進化するだろうけど)。

まとめます。

繰り返しになって恐縮ですが、新しい技術やアイデアを形にすることは素晴らしいことだし、僕はこれらの技術やサービスを批判するつもりは全くありません。1つめの話なんかはサービスに導入する側が配慮すればそれで済む、という考えもありますし。

それでも、こういった技術を実装するエンジニアやそれ以外の人の中にこういったことについて問題提起できる人がいて(既に配慮されているのかもしれません)、その課題をクリアする手段を提供できるならば、そのサービスがより多くの人に利用できるという点において、よりいっそう素晴らしいものになっていくのだと思います。

デバイスが多様化する現代だからこそ、新しいアイデアがどんどん生まれてくる。わくわくする時代。だからこそ、そこで今一度、アクセシビリティについて考えてみましょう。

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

地下鉄で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」に該当するかどうかは僕には疑問でした。

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

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

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

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

Facebook

Twitter

このアーカイブについて

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

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

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

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

Powered by Movable Type 6.2.6