アクセシビリティJIS 改正の概要と押さえるべき点（１）―今までとの違い

アクセシビリティJIS 改正の概要と押さえるべき点（１）―今までとの違い

前回の「プロローグ」から2週間近く経過しましたが、やっとシリーズ開始します。まずは今までのものとどう違うか？と言う点から説明したいと思います。

2004年版と今回の2010年版は全くの別物と考えた方が良い

2004年に公開された「JIS X 8341-3:2004」、それから6年が経過し新たに改正された「JIS X 8341-3:2010」。改正という名前から、2004年のものを分かりやすくしたとか、使いやすくした等との想像をしがちですが、「まったくの別モノ」と考えた方が正しいです。

2010年版は WCAG2.0 がベースになっている

2010年版は W3C から出されている WCAG 2.0 (Web Content Accessibility Guidelines 2.0) をベースとして考えられており、チェックする項目についても全て項番まで一緒になっています。違いといえばガイドラインの補足に2ページにまとめられていますが、基本的には言い回しの部分や、説明を記述する場所が違う程度で、チェックする項目についての違いはありません。

逆に 2004年版との違いは延々と14ページに渡って記載されています。2ページに対して14ページなので、2004年と比較する事自体、あまり意味の無いものとなっています。

なぜ 2004年版から大きく変わったのか？

いくつか理由があります。

・世界標準に合わせた方が運営しやすい

グローバル企業の場合、日本ではJIS、海外ではWCAG、といった具合に対象とチェック内容が違うと、国々での運用方法が変わってきます。統一させた方が運営はしやすいですし、後半の説明に出てきますが、チェックツールをワールドワイドで同じものが利用できるという点もメリットとなります。

・技術的に細かく書かれていた為、進歩の激しいWeb業界で陳腐化していた

2004年版はフレームやアニメーションGIF等最近ではあまり使われていない技術について細かく記載されていた為、最近ではあまり意味をなさなくなっていました。2010年版では陳腐化しないように技術的な表現は無くしてあります。

・抽象的な表現が多く、明確なゴールがない

「適切な文章をいれること」といったような抽象的な表現が多く、人によって OK/NG が変わるような記載となっていた為に点数化しづらく、ゴールを決めにくいという事がありました。2010年版では達成基準を設け、ゴールを決めやすくなっています。

こういった理由に加えて

・達成基準を設けることで、達成宣言を出せるようになった

どこまでやったら合格か、第三者にも判断できるようになりました。ただし、まだ達成宣言に関する詳細な仕様は確定していません。このあたりは後日公開される予定です。

・チェック手法が具体的になったことで、自動チェックツールでチックできる項目が増えた

Webサイトの運用は現在では複雑化してきていますし、ページ数が数千～数万といったサイトも多く存在します。それらを目視で確認する事自体困難ですので、ツールによるチェックが必須となります。その為、チェック手法を具体的に記載してあり、チェックツールが作り易くなっています。今後はチェックツールによる運営が標準となっていくことでしょう。

難しくなった点もあります

メリットばかりかというと、そうでもありません。今回の改正で分かりづらくなっている点もあります。

・技術的に陳腐化しないようにできるだけ技術名は使用せずに説明してある

そのため分かりづらい表現の部分が多々あります。これらは今後、別途具体的な記述方法などを記載した技術書が出てくる事になっています。

これからアクセシビリティ対策される方へ

まずはこの「JIS X 8341-3:2010」を読み、いきなり自分のサイトを目視で確認するのではなく、チェックツールを探してください（ここ、宣伝になりますが、弊社では「IBM Rational Policy Tester OnDemand」を採用しており、導入支援サービスを実施しております）。次に、どこまでやるのか？最初はミニマムスタートから始めるとして、何を優先とするか？といった点を決めます（このあたりも弊社にてコンサルティングさせていただいております）。チェックツールがあればチェックは簡単ですが、一部ツールではどうしてもできない点もあります。それらをどうするかも含めて決めたらスタートです。サイト制作を外部に任せている場合は、アクセシビリティ対策の為に＋αの制作費用を要求される場合もありますので、制作会社との契約や予算、チェックエラー時のフローなどを決めて運用を開始します。ここでもミニマムスタートから実施し、少しずつ軌道修正していくことで自社サイトにあった対策を実施してくことができます。また、続ける事も大切です（弊社では運用コンサルティングも行ってますし、制作運用も行ってます。お気軽にご相談ください。）。

後半、宣伝が増えてしまいましたが、アクセシビリティは経験者に聞くのが最も手っ取り早いですし、結果、コストを安く抑え、期間を短くすることができます。是非、弊社のサービスもご利用ください。まずは気になった方はお気軽にご相談ください。　→ http://www.vccorp.net/

それでは。

Webサイト高速化技法（３）：きれいなHTMLを書く

Webサイト高速化技法（３）：きれいなHTMLを書く

今回は前回の予告通り、サイトの内部に話を移していきます。

きれいなHTMLとは？

もうお分かりだと思いますが、「きれいなページ」ではなく「きれいなHTML」ですので、見た目の問題ではなく、文法通りにHTMLが書かれているかが問題になります。ブラウザは当然、文法通りに書かれていた方が気持ち良く読めますし、早く読めます。その分表示も早くなります。一度ブラウザの気持ちになって HTML を読んでみる事をおすすめいたします。

たとえば、「レンダリングエンジン」

ブラウザは、レンダリングエンジンという描画エンジンを抱えています。インターネット経由で取得した HTML や CSS の文法を読解し、画面描画の為に、どこに何を書くのか？を判断して描画していきます。

みなさんも今までにいろんなサイトを見てきたと思いますが、それらの表示パターンが何通りかあったのは気付いているのではないでしょうか？

(1) しばらく白い画面が続いて急に画面全体が表示されるパターン

これは古いサイトに良くあるパターンです。テーブルレイアウトを使っているとよくこの現象が出るのですが、テーブルで指定したサイズと画像で指定したサイズ、実際に読み込んだ画像のサイズが違うと全部が計算終わるまで表示が出来なくなり、表示されません。つまり、描画に必要な画像を全て読み終わるまでは真っ白な画面が続く事になります。

こうならないように、テーブルレイアウトは使わずに、画像の width/height 属性も全部に書くようにしてください。

(2) 読み込んだ画像から次々表示されるのでカクカク感があり、読み終わるまでクリックしづらいパターン

このパターンが最近多いのではないでしょうか？読み込んでいる最中に先にページの下部が表示され、そこをクリックしようとした瞬間にその上部が読み込まれ表示されることで、クリックした場所がズレて期待したページではないページへ移動したこともみなさんあると思います。

最近は ajax 技術を使って、それぞれのパーツを別々に読み込ませているサイトが増えてきています。その場合に、それぞれのパーツのサイズが決まってないとカクカク表示され、その度にレンダリングエンジンが再計算をして表示し直す為、それなりにCPUリソースも使います。

できるだけユーザーの為にもカクカク表示させないように、パーツの width/height をしっかり定義しておきましょう。

(3) 全体の枠（レイアウト）が先に表示されて、そこに次々と画像が貼り付けられていくパターン

実はこれが最も早く表示され、かつ、ユーザーにやさしい「きれいなHTML」です。しかし、ここまでこだわっているサイトが少ないのも実情です。上の2パターンは表示が終わるまでレンダリングエンジンが計算しっぱなしで、それなりの負荷も与え、読み終わるまでクリックしづらい状況が続きます。このパターンでは、読み終えた部分から表示され、レンダリングエンジンはレイアウトの再計算をすることが無いので負荷もなく、表示も早く、読み終えてないパーツも alt で説明を入れておく事で、読み込んでいる最中でもズレる事なくクリックしやすいのでユーザーにも優しいです。

対応方法は至って単純です。width/height が必要な項目（画像やテーブルなど）に全て width/height を定義すれば良いのです。そこで、読み終わった画像とのサイズの差が無いように注意が必要ですが、定義しておく事で、表示も負荷も軽くなります。何よりイライラが無くなって人にやさしいサイトになります。

ほかにも注意すべき点

ほかにも、最近気になるページとして「ブラウザのローディングが動いてないのにローディング中」のページがあります。ajax 技術を使っていて、タブのところのグルグルが止まったので、読み込み終了かと思ったら、まだ次から次へ表示される。しかもローディング中かどうか表示されてないので、いつ終わったかが分からない。こういったページが増えてきています。関係者はどこまで読めばクリックできるか分かるので気にならないのかもしれませんが、一般の人が見ると、「終わったの？まだ待った方がいいの？」と悩んでそれがストレスになる事もあります。 ajax とはいえ、ローディング中の場合はその旨表示させる事を義務と考えた方が良いと思います。

今回はレンダリングエンジン（おもに width/height ）を取り上げましたが、他にもいろいろあります。まずはこの辺りから手をつけてみるのも良いかと思い3回目に紹介させていただきました。

4回目は未定です。

それでは。

9/5 Google Analytics 利用率は 35.7% (前週から0.1ポイント増）

今週も上場企業のWebサイト 3,828社分を調査してGoogle Analytics の利用率を調べてみました。

今週は先週から比べて 4社増えてました。

合計で 1,365社。前回の 35.6% から 0.1ポイント増えて 35.7% となりました。

ちなみに

SiteCatalystは変わりありませんでした。

企業サイトには 105社に入っています。
※SiteCatalyst は企業サイトには入れずにサービスサイトのみ導入している企業も多いので、これがそのまま導入数ではありません。

今週はダウンしているWebサーバが多数ありました。リニューアル中でしょうか？来週大きく増える可能性もありますので注意して見てみたいと思います。

9月に入ってもまだまだ酷暑は続きます。予想では9月いっぱい続くそうですので、外出時は熱中症に気を付けて、室内の冷房との温度差で体調を崩さないようにしっかり栄養と睡眠をとるようにしてください。

それでは。

「グループ」と「チーム」の違い

「グループ」と「チーム」の違い

みなさん、「グループ」と「チーム」の違いを意識して使っていますでしょうか？
「作業グループ」や「プロジェクト・チーム」、「アイドルグループ」「チームK」等、いろんな場面で使われてますが、そもそも、この２つに違いはあるのでしょうか？

Yahoo!辞書で調べてみました。

グループ【group】
１ 仲間。集団。「―旅行」
２ 共通の性質で分類した、人や物の一団。群。
３ 同系列に属する組織。「企業―」

チーム【team】
ある目的のために協力して行動するグループ。組。
スポーツや共同作業についていわれる。「―を組む」「野球―」

ということですので、

　　共通の性質で集めた仲間　　→　グループ
　　目的の為に集められた団体　→　チーム

という風に分けられるかと思います。

グループは足し算、チームは掛け算

上記の内容から考えると、グループは同じ性質で集められる為に比較的まとまりがあり、団体生活を送る上では適している団体だと考えられます。一方、チームはある目的の為に集められ、それぞれに個性や特性があり役割が決まっている団体と考えられます。つまり、内部のメンバーが同じ作業をする団体＝グループ、内部のメンバーがそれぞれ違う役割を持って作業をする団体＝チームと言えるかと思います。

言い方を変えると、グループで効果を上げようとすると、それに比例するリソースを投入する必要があり（リソースに比例した効果）、チームで効果を上げようとすると、足りない部門のリソースを投入する感じです。

守る部門はグループ、攻める部門はチーム

他の見方をすると、グループはカスタマーサポートや現場の制作部隊のような同じ作業を行う団体で、チームは開発やマーケティングのような得意分野を役割分担して効果を上げようとする団体とも受け取れるかと思います。つまり、突出したスキルは必要なく、守る為に画一化されたサービスを提供するのがグループ、突出したスキルを有効活用し、より効果を上げる為の相乗効果を図るのがチームとなります。

グループに必要なのはマネージャー、チームに必要なのはリーダー

さらに違う見方をすると、グループをまとめる場合には誰かが遅れる事なく、みんながまとまって行動する為のマネージャー的役割が必要で、チームをまとめる場合にはそれぞれの長所を活かして、みんなで相乗効果を出し合って目標へ向かう為のリーダー的役割が必要だと思います。

ほかにもいろんな使い分けが

みなさんは使い分けていますか？みなさんも上記を参考に使い分けをしてみてください。

それでは。

Webサイト高速化技法（２）：HTTPリクエスト数を減らす

Webサイト高速化技法（２）：HTTPリクエスト数を減らす

これも1回目の「物理的に近い場所に置く」に近い概念となります。

Webサーバーをアメリカに置くとHTTPリクエスト1回でデータは地球を1周します。これがサーバーを近くに置いたとしても数10キロ～数100キロの「旅」は実施されます。この旅の回数を減らすのも大きなポイントです。サーバーの中で処理している時間、クライアントPCの中で処理されてレンダリングエンジンを実行する時間に比べて、データを転送している時間というのは物凄く大きな比重を占めます。また、このリクエスト回数が半分になれば、表示までの時間も半分に近いところまで短縮されます。

どうやってHTTPリクエスト数を減らすか？

単純に画像の数やJSの数を減らせばリクエスト数は減りますが、そうするとWebサイトはやはり地味になってしまいます。サイトのデザインを変えずにリクエスト数を減らす方法はないのでしょうか？

まず、「 @import を減らす」

これは非常に効きます。簡単に説明しますと、CSSファイル内に @import を記述した場合、

1. css ファイルを取得 → 解析 → @import 発見 → 次に読む CSS ファイルを判断
2. @import で記載されていた css ファイルを取得 → 解析・・・・

と、サーバーとクライアントPCの間を2往復します。これらは読み込まないと次のファイル名が分からないので、並行処理はできません。前のファイルを読み込んで解析するまで次のファイルを読み込みに行けません。単純に css ファイル1個の中に書くよりも HTTPリクエストは倍増し、時間も倍増します。極力 @import は使わずに 1つの cssファイル内に書ける分だけ書きましょう。

※注意：何事にも限度があります。あまり長すぎても今度は管理がしづらくなります。管理体系毎に最小の単位に分けて css を記述することをお勧めします。

次に、「 CSS スプライトを使う」

これも非常に有効です。1つの画像の中に何回も流用する画像をパネル状に並べて保存しておくことで、利用時にそれらを css で座標を指定して表示させる部分を切り抜いて使います。ですので、1つのページの中にある数十個の画像を1個にすることで圧倒的に転送時間を短縮させることができます。

※注意：これも同じく限度があります。追加・修正のある画像が中にあると、編集作業や css 定義しなおしが発生して非常に煩雑になってしまいます。次のリニューアルまでほぼ触らないと思われるものだけをピックアップして1枚の画像にするようにしましょう。

あとはひたすら、「ソースの結合」

JSファイルやCSSファイルを小さく数十個記述してあるサイトを良く見ますが、これらは単純にファイルをくっつけて 1枚の長いソースにする事で HTTPリクエストを減らす事ができます。

※注意：これも同じですね。あまり多くを結合してしまうと編集や加筆が非常に煩雑になってしまうことがあります。そうならない為にも、変更しないものだけを抽出することをお勧めいたします。

「 JSファイル圧縮」は？

圧縮という技術もあります。複数の画像やJSファイルを圧縮して1つにし、クライアントPCへロード後に解凍して利用することで、HTTPリクエスト回数を減らしたり、転送（取得）するデータ量を減らして高速化する技術です。しかしこれは最近ではあまり実施している企業はありません。というのも、圧縮してしまうと、ブラウザや利用先でウイルス等の危険性を謳われて取得できない事もある為です。効果はありますが、リスクもありますので、利用の際には細心の注意を払う必要があります。


上記の3つの手段を実施するだけでページの表示時間は大幅にカットされること間違いなしでしょう。前回の（！）の次にこの（２）の「HTTPリクエスト数を減らす」は是非とも実施して見てください。ただし、やりすぎると、編集・修正・プチリニューアル時に大変になりますので、そのあたりも注意しながら実施してください。

次は（３）ですが（３）では内部に話を移していく予定です。

それでは。