クリッカブルマップがrwdImageMapsで消える|動かなくなる場合がある件

こんにちは、システムの渋谷です。
画像の一部分の領域からリンクを張る、クリッカブルマップという便利な機能があるのですが、レスポンシブで画像のサイズが変わってもリンクの領域は自動的に変わらないため、ブラウザのサイズ変更に応じてリンクの領域をjavascriptで変えてあげる必要があります。

その作業を簡単に行ってくれるResponsive Image Maps jQuery Pluginという著名なjQuery Pluginがあるので、通常これを使ってクリッカブルマップのレスポンシブ対応を実現しています。

使い方も簡単で、「jquery.rwdImageMaps.min.js」を読み込んで

$(‘img[usemap]’).rwdImageMaps();

とするだけでOK!
まったく簡単だ!

と思ってたら、なぜかクリッカブルマップが正常に動いていない案件が……

やせいの バグが とびだしてきた!

症状としては、

  • タブを使って複数のクリッカブルマップを切り替える仕様
  • クリッカブルマップを切り替えるとリンク領域が消えている
  • ブラウザサイズを変更するとなぜか復活する

いろいろ適当にいじってみても正常に動作しないので、泣きながら(というほどでもないですが)ソースを読んでみました。

画像ロード時にimg要素の大きさを取得して、それをもとにレスポンシブで変更された画像の大きさでのリンク領域の計算を行っているようです。

つまり…タブで切り替える仕様などで、rwdImageMaps()実行時にクリッカブルマップが非表示の状態になっていると画像の幅と高さが「0」とされてしまうので、リンク領域も出なくなってしまう、と。

それで解決方法は?

これを解決するには、画像を表示するタイミングでサイズを取得してあげるようにすればいいのですが、プラグインの中身に手を入れると管理が面倒になるので今回は「ブラウザサイズを変更するとなぜか復活する」点に注目して、タブの切り替え時にresizeイベントを発火させることで解決することができました。

コードとしては、タブ切り替え時のslideDown等の関数のコールバックに

function(){$(window).resize();}

を指定してあげればいいだけです。

rwdImageMaps自体が結構長い間メンテナンスされておらず、最新のjQueryで廃止された関数を使っていたりするのでいろいろ書き換えたいところがあるんですけどね。

ウェブアクセシビリティのJIS規格対応2

システム部の渡辺です。

前回記事「
ウェブアクセシビリティのJIS規格対応」の続きで、

具体的な作業に関する部分を書きたいと思います。

アクセシビリティのJIS規格「JIS X 8341-3」の詳細がわかる公開されているページは現在、

公式ページ「実装チェックリストの例 2012年11月版」

になります。

38項目のリンク先ページに約10個ぐらいの対応内容が書かれていますので相当な量になりますが、基本的に常識的なWEB制作をしていれば大抵のものはクリアできるかと思います。

私個人の判断で、

「あまり一般的ではない内容」

「登場頻度が多く、うっかり忘れてしまいそうな内容」

「デザイン時」「コーディング、特にベース部分制作時」「コーディング、特に各ページの制作時」に分けてピックアップすると下記の表のようになりました。

もし参考になりましたら幸いです。

  • ※ 上記は動画に関する項目は省いています。サイト内に動画を設置する場合は気をつける点が増えます
  • ※ 「達成基準」の部分を、公式ページへのリンクにしています。

デザイン時に気をつける項目

番号 達成基準 状況 項目の内容 説明 追記 等級
7.1.3.3 感覚的な特徴に関する達成基準 理解すべき情報を感覚的にだけ伝えることのないように、テキストでも情報を伝える 「フォームを送信するには、次へと記された円形のボタンを押して下さい」など操作方法を説明するようなシーンで、その「ボタン」の説明には、形や大きさ又は相対的な位置についての情報がない場合でも、アイテムを見つけて特定するための追加情報を含めましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合 色の違いで伝えている情報をテキストでも入手可能にする 色によって伝えられている情報は、テキストでも説明するようにしましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合: テキストの色の違いで情報を伝える際は、視覚的な手がかりを補足する A
7.1.4.1 色の使用に関する達成基準 状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合: リンク又はコントロールを色だけで識別している箇所の視覚的な手がかりを補足するために、周囲にあるテキストとのコントラスト比を 3:1 以上にする A
7.1.4.1 色の使用に関する達成基準 状況 B: 情報を伝える画像の中で色を用いている場合: 色とパターンを併用する 色を用いて伝達されている情報の全てに、色に依存しないパターンも併用しましょう。 A
7.1.4.1 色の使用に関する達成基準 状況 B: 情報を伝える画像の中で色を用いている場合: 色の違いで伝えている情報をテキストでも入手可能にする 画像の中であっても、色によって伝えられている情報は、テキストでも説明するようにしましょう。 A
7.1.4.3 最低限のコントラストに関する達成基準 状況 A: 太字でないテキストが18ポイント(日本語は22ポイント)未満、太字のテキストが14ポイント(日本語は18ポイント)未満の場合: テキスト(及び画像化された文字)とその背景の間に、少なくとも4.5:1のコントラスト比をもたせる 小さい文字は、コントラスト 4:5:1 もたせましょう

ロゴか装飾的なテキストは例外
AA
7.1.4.3 最低限のコントラストに関する達成基準 状況 B: 太字でないテキストが少なくとも18ポイント(日本語は22ポイント)、太字のテキストが少なくとも14ポイント(日本語は18ポイント)の場合: テキスト(及び画像化された文字)とその背景の間に、少なくとも3:1のコントラスト比をもたせる 文字が大きいならコントラストは 3:1 もたせましょう AA
7.2.4.6 見出し及びラベルに関する達成基準 目的や内容が分かるラベルを提供する サイト内で、入力を受け付ける input 属性には適切なラベルを表示しましょう AA

コーディング、特にベース部分制作時に気をつける項目

番号 達成基準 状況 項目の内容 説明追記 等級
7.1.1.1 非テキストコンテンツに関する達成基準 状況F:

非テキストコンテンツを支援技術が無視するようにしなければならない場合:
CSSで指定する画像は、装飾的なものだけである 意味のあるテキストやアイコンを、CSS だけで表示してしまうと、CSSを無効にした場合に表示されないので避けましょう。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
CSSを用いて構造と表現を分離する ブラウザの CSSをオフにして、情報が伝わることを確認しましょう A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
h1要素~h6要素を用いて、見出しを特定する A
7.2.1.1 キーボード操作に関する達成基準 JavaScriptでイベントハンドラを用いる場合は、キーボードで操作できるようにする

ただし、軌跡に依存した入力を要する機能(お絵描きプログラム等)は除く
キーボードだけで操作して、すべて操作可能であることを確認しましょう。

例)

キーボードでリンクを選択できる。

キーボードでリンク移動ができる。

メニューなど mouseover で表示されるサブメニューがある場合は、focus イベントも追加して、キーボードで操作できるようにする。
A
7.2.1.2 フォーカス移動に関する達成基準 利用者がコンテンツ内に閉じ込められないようにする A
7.2.4.1 ブロックスキップに関する達成基準 以下のいずれかを用いて、繰り返されるブロックをスキップ可能にする

1) 以下のいずれかを用いて、繰り返されるブロックをスキップするリンクを作成する

a) メインコンテンツへ直接移動するリンクを各ページの先頭に追加する

b) 繰り返しているコンテンツのブロックの開始位置に、そのブロックの終了位置へのリンクを追加する

c) ページの先頭に、コンテンツの各エリアへのリンクを追加する

2) 以下のいずれかを用いて、スキップ可能な方法で繰り返されるブロックをグループ化する

a) コンテンツの各セクションの開始位置に見出し要素を提供する

b) 構造を示す要素を用いて、リンクをグループ化する

c) frame要素を用いて繰り返しているブロックをグループ化し、frame要素にはtitle属性を付与する

d) 展開可能及び折り畳み可能なメニューを用いてコンテンツのブロックをバイパスする
A
7.2.4.3 フォーカス順序に関する達成基準 TABキー又は矢印キーを用いて、フォーカスを受け取る要素を移動し、その順序が意味及び操作性を保持していることを確認する。 レスポンシブウェブデザイン時では特に注意した方がよさそうな点。 A
7.1.4.4 テキストのサイズ変更に関する達成基準 以下のいずれかの実装方法を用いて、コンテンツ又は機能を損なうことなく、テキストを支援技術なしで 200%までサイズ変更できるようにする(ただし、キャプション及び画像化された文字は除く)

ユーザーエージェントの機能を用いて拡大できるコンテンツを作成する

コンテンツを拡大するためのコントロールを提供する

コンテンツ又は機能を損なうことなく、テキストを支援技術なしで 200% までサイズ変更できることを確認する(ただし、キャプション及び画像化された文字は除く)。
忘れると後からの修正が大変な項目です。

文字を 200% 拡大して、隠れる文字がないかを確認する

ブラウザによっては文字だけではないズーム機能も用意されているが、この場合は「文字だけを200%に拡大」した際に、コンテンツの意味が失われないように気をつけましょう。

具体的な作業としては、文字を含む要素には高さを指定せずに、縦幅リキッドレイアウトを意識してコーディングします。
AA
7.1.4.5 画像化された文字に関する達成基準 例外に該当しない文字は、画像化しない

いずれかを満たす場合は例外とする
画像化された文字が利用者の要求に応じて視覚的にカスタマイズできる

または

文字の特定の表現が、伝えようとする情報にとって必要不可欠である(ロゴタイプを含む)

7.2.4.6 見出し及びラベルに関する達成基準 内容が分かる見出しをつける

(見出しがある場合は、その内容が適切かを確認する。)
AA
7.2.4.7 視覚的に認識可能なフォーカスに関する達成基準 すべてのコントロールでフォーカスインジケータが視覚的に認識可能にする

キーボードのtabキーを押下し、フォーカスインジケータを移動させた場合に、すべてのコントロールにおいてフォーカスインジケータが視覚的に認識できるか、または、認識できるようにキーボードで変更する機能を有することを確認する。
AA
7.3.2.3 一貫したナビゲーションに関する達成基準 繰り返されるコンポーネントが表示されるたびに、それを相対的に同じ順序で提示する ウェブページの集合(例えばウェブサイト)にて繰り返し利用されるコンポーネント(例えば、ロゴ、タイトル、検索フォーム、ナビゲーションバー、ナビゲーションメニュー等)が、相対的に同じ順序で表示されていることを以下の方法などを用いて確認する。

  • CMS等により、繰り返し利用されるコンポーネントが相対的に同じ順序で提示されるように管理されている
  • 各ページを作成する際にテンプレートを利用したり、Webページ製作・編集ツールの機能を用いることなどにより、繰り返し利用されるコンポーネントが相対的に同じ順序で提示されるように管理されている
  • CMS、テンプレート等で管理されていない場合は、試験実施ガイドライン2.3節のb)c)に示された選択方法などを用いて試験対象ページを選択し、該当ページ間で繰り返し利用されているコンポーネントが相対的に同じ順序で表示されている
AA

コーディング、特に各ページの制作時に気をつける項目

番号 達成基準 状況 項目の内容 説明 追記 等級
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
img要素にalt属性がある imgタグに alt属性をいれましょう。

alt属性が不要な場合は alt=”” と属性値なしで書きます。
A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
隣り合う画像とテキストのリンクが同一のhref属性値を持つ場合、画像とテキストを1つのa要素でマークアップする 例えば、キャプチャ画像と説明テキストが同じリンクで隣あっているような時は、1つの同じ a要素にいれましょう A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
a要素のリンクの目的を説明するリンクテキストを提供する 音声読み上げされる a要素に含むテキストの意味に気をつけましょう。 A
7.1.1.1 非テキストコンテンツに関する達成基準 状況A:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
画像のグループにある一つの画像に代替テキストを提供して、そのグループのすべての画像を説明する 画像が連続していて連続で alt属性読み上げが無駄そうな時はむしろいれない方がいい。例えば「★☆☆」というような画像など A
7.1.1.1 非テキストコンテンツに関する達成基準 状況B:

短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できない場合(例:チャート又はダイアグラム):
以下のいずれかの方法を用いて長い説明を提供する

  • 短い説明の中で長い説明の場所を示す
  • 非テキストコンテンツのすぐ隣に長い説明へのリンクを提供する
  • object 要素のボディに代替テキストを記述する
A
7.1.1.1 非テキストコンテンツに関する達成基準 状況F:

非テキストコンテンツを支援技術が無視するようにしなければならない場合:
支援技術が無視すべき画像の img 要素は、alt属性値を空にして、title 属性を付与しない 音声読み上げで伝える意味のあるテキストであり、不要な場合は alt=”” と属性値なしで書きましょう。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
セマンティックなマークアップを用いて、強調したテキスト又は特別なテキストを示す 太字で強調するテキストには、 em か strong を使いましょう。など。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
引用箇所がある場合、blockquote要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
引用箇所に参照情報がある場合、参照先を cite 要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
下付き文字、上付き文字がある場合、それらを sub、sup要素でセマンティックにマークアップする A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
色の手がかりを用いる場合には、セマンティックにマークアップする

色で情報を伝えている場合、セマンティックなマークアップ(例えば、em、strongなど)を用いていることを確認する。
A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
table 要素の summary 属性を用いて、データテーブルの概要を提供する html5 では summary を書いてしまうと、valid ではなくなってしまいますので、html5 でマークアップしている際はつける必要はないと思われます。 A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
見出し構造が複雑で、scope属性だけでは見出しセルが指定できないデータテーブルでは、id 属性及び headers 属性を用いて、データテーブルのデータセルを見出しセルと関連付ける A
7.1.3.1 情報及び関係性に関する達成基準 状況 A:

ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
リストに、ol 要素、ul 要素、dl 要素を用いる

リストのマークアップを用いて、リストの情報を提示する
7.1.3.2 意味のある順序に関する達成基準 単語の文字間にスペースやタグを用いない A
7.2.4.2 ページタイトルに関する達成基準 title要素を用いて、コンテンツの内容が分かるページタイトルを提供する A
7.2.4.4 文脈におけるリンクの目的に関する達成基準 以下のいずれかを用いて、リンクの目的を特定する

  • 1) a) b)を用いてリンクの目的を説明したリンクのラベルを提供する
    • a 要素のリンクの目的を説明するテキストリンクを提供する
    • b) イメージマップの area 要素に代替テキストを提供する
  • 2) リンクのラベルとそれが含まれている文章中のテキストとを組み合わせる
  • 3) リンクのラベルとそれが含まれているリスト項目とを組み合わせる
  • 4) リンクのラベルとそれが含まれている段落とを組み合わせる
  • 5) リンクのラベルとそれが含まれているデータセル及び関連づけられた見出しセルとを組み合わせる
  • 6) リンクのラベルとその直前にある見出し要素とを組み合わせる
  • 7) 入れ子になったリスト項目にあるリンクのラベルとその親のリスト項目とを組み合わせる
  • 8) CSSを用いて、リンクの目的の説明を補足したリンクテキストの一部を非表示にする
A
7.4.1.1 構文解析に関する達成基準 ページをバリデートし、問題がないことを確認する。

ページがバリッドでない場合、少なくとも下記のいずれかを満たすこと

  1. 開始タグ及び終了タグが仕様に準じており、属性値のクオーテーションが正しく組になっていること
  2. ページがwell-formedであること
A

[WordPress]公開済みの古い記事上に注意文を表示する。

ブログなんかで、「この記事は古いですよ」的なアナウンスをしている記事、ありますよね。

七夕ですね!システム部のヒライでございます。

デザインツールの使い方や技術系の解説、ブログ等を読んでいると、「この記事の内容は最新でない可能性があります」的な注意書きが目につきますよね。
書いた当時は最新の情報ですが、日がたつにつれその内容が正しくなくなる可能性もあるわけでして、
記事を読みに来られたユーザーさんへのとても良い配慮になると思います。

この様な注意書きですが、WordPressでは一瞬で出来ちゃいます。

投稿日が1年以上前の記事に注意書きを表示する。

サンプルとして、まずは適当に投稿日を古くした記事を作ってみます。

1

お使いのテーマ内にあるsingle.phpを開き、注意書きを表示されたい場所に以下を差し込みます。

[php]
<?php
// 投稿日が1年以上前であれば表示する
if( date(‘U’) – get_the_time(‘U’) > 60*60*24*365 ) {
?>
<!– ↓ここにhtmlで注意書きを入力 –>
<div style="background: #FFEDED; border: solid 1px #B84749; color: #B84749; padding: 10px; font-weight: bold; margin-bottom: 20px;">
<p>本記事は<?php the_time(‘Y年n月j日’) ?>に投稿されました。<br>現在の状況とは違う可能性があることをご了承下の上、お読み下さい。</p>
</div>
<?php
}
?>
[/php]

これで、投稿日が1年以上前の記事のみに注意書きが表示されます。
1年では長すぎるので短くしたい、等の場合は2行目の「365」を変更すればOKです。(30にしたら30日以上前となります)

それでは同じ記事を表示してみます。

2

一目で古い記事なんだなとわかるようになりました。
というわけで私もブログを書くようなことがあれば積極的に使おうと思います。

ご存知でしたか?Google Map APIの使用にAPI Keyが必須になりました

システム部の鈴木です。

もはやwebサイト制作だけではなく日々の生活に無くてはならなくなったGoogle Map
世界中の人が無料で使えて、これを活用したサービスだって無料で作れる。
当たり前になりすぎてしまいこの恩恵の価値を忘れてしまうくらいでしたが
ここにきて少し動きがあった事、ご存知でしたか?

Google Map API

これを使うと、自分のサイトの中にこんな感じで、沢山の好きなアイコンを並べたり
様々なカスタマイズを加えた独自のマップを作ることができます。

現在のAPIはVer.3 となり、Ver.2 までは煩わしかったAPI Keyが不要になった、ということで制作者にとっては非常にありがたいアップデートになりました。

2016-07-01_21.47.20

ところが、それは突然の出来事でした・・・

Mapが表示されない!?

いつも通りに作ったはずが全く表示されない?
今まで動いていたサイトのコードを流用しているんだから間違ってるはずもないのに?

そこでChromeのデベロッパーツールでコンソールを開くと見慣れないエラーが。。

Google Maps API warning: NoApiKeys https://developers.google.com/maps/documentation/javascript/error-messages#no-api-keys

NoAPIKeysエラー?

APIKeyはいらないはず、と思いながら調べたところ、Google が2016年6月22日に以下のようなアナウンスを出していた事が分かりました。

http://googlegeodevelopers.blogspot.jp/2016/06/building-for-scale-updates-to-google.html

これによると6/22より、スタンダードプラン(無料のもの)を使って新しく作成するアプリケーションでは
API Keyが必須になったとあります。

Google developers blog でもそんな事書いていなかった気がするんですが。。

API Keyはどうやって取るの?

まずは予めGoogle アカウントにログインをしておいてください

160701

Google Map API のサイトにある「キーを取得」を選択します

 

160701_02

するとこんな感じのモーダルが表示されるので「続ける」を選択

 

160701_03

今度はGoogle API Console に遷移します。
「プロジェクトを作成」を選択したまま「続行」します。

160701_04

するとこのような「認証情報」という画面が表示されます。

ここでAPI Keyを発行するのですが、とりあえず「作成」します。

 

160701_05

なにやらAPIが発行されたようです。

 

160701_06

まだこの段階では発行されたAPIが使われるサイトのドメインが登録されていません。

作成されたAPIキーの名前を選択してドメインを登録しましょう。

 

160701_07

API Key発行の画面が表示されるので、ここで改めてアプリケーションを作成するサイトのドメインを設定します。
テストサイトと本番サイトがサブドメインでわかれている場合は、サブドメインをワイルドカードにすれば環境ごとにキーを設定する必要が無く便利です。

 

これで、API Keyの準備ができました。

あとはアプリケーション側で、APIのロードをこんな感じで変更します。

変更前
変更後
これで今までどおり、Google Map APIが使用出来るはずです。

前に作ったアプリケーションはどうなるの?

6/22以前にすでに稼働しているアプリケーションは、今のところAPI Keyなしでも動きます。
今のところはAPI Keyをいつまでに付けなければいけない、という事も無さそうです。

しかし今後いつ、今回のように突然の変更があるかは分かりません。

今後はAPI Keyを必須にするという方針に沿って、直せるうちになおした方が良いでしょう。