カテゴリー: アクセシビリティ
この記事は2015年1月14日に書かれたものです。情報が古い可能性がありますのでご注意ください。
フォームのアクセシビリティ要件として、第一にラベルとコントロールを関連付けるということが必要です。この関連付けによって、スクリーンリーダー利用者は [tab] キーで入力枠等を移動していった場合に何を入力あるいは選択すればいいか分かります。また、マウスを使ってる場合はラベルのテキストをクリックすればコントロールをフォーカスでき、特にラジオボタンやチェックボックスの選択が容易になります。
しかし、CMS によってシステム的にフォームが出力される場合や、メルマガ配信サービスで出力される HTML を貼り付ける場合に、このラベルとコントロールの関連付けがなされていない場合があります。ラジオボタンやチェックボックスについては、暗示的なラベル付け(コントロールとラベルをまとめて label 要素で囲む)によって関連付けされていることが多いですが、テキストフィールドやセレクトメニューについては関連付けされていない場合があります。
最近上記のような事例があり、フロント側で HTML を編集することもできないため、jQuery を使って関連付けを設定してみました。フォームはよくあるテーブルによるマークアップの単純なもので、一行テキストフィールド、複数行テキストエリア、セレクトメニューに対して、ラベルとの関連付けを設定します。
“jQuery でフォームをアクセシブルに” の続きを読む »
カテゴリー: WordPress
この記事は2015年1月14日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress サイトで Google アナリティクスを導入する場合(トラッキングコードをテーマファイルの header.php などに貼り付ける場合)、そのままでは投稿のプレビュー画面もカウントされてしまいます。また、テストサーバでテーマの編集やプラグインのアップデートを行っている場合も同様にカウントされます。
Google アナリティクス側でフィルタを設定して回避することもできますが、クライアントからトラッキングコードを渡された場合など、Google アナリティクスへのログイン権限がない場合、テーマファイルの中で回避することになります。
プレビュー画面を除外する場合については多くのブログ等で紹介されていますが、WordPressの条件分岐タグ is_user_logged_in() を使います。このタグでログインしているかチェックし、ログインしていない場合にトラッキングコードを適用します。
テストサーバを除外する場合はホーム URL の値を使います。例えばテストサーバの URL に “local” が含まれているのであれば、home_url() にこれが含まれているかをチェックし、含まれていない場合にトラッキングコードを適用します。なお、home_url() の代わりに、php の $_SERVER['REQUEST_URI'] を使ってもよいでしょう。
<?php if ( !is_user_logged_in() && strpos(home_url(), 'local') === false ): ?>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>
<?php endif; ?>
!is_user_logged_in() && strpos(home_url(), 'local') === false で、ログインしていない、且つ URL に “local” が含まれない場合にトラッキングコードを読み込んでいます。
なお、Google Analytics Dashboard for WP などのプラグインを使用する場合は、プラグインの設定でログイン中を除外することができます。また、テスト環境ではプラグインをインストールしないか無効にすることで回避します。
カテゴリー: アクセシビリティ
この記事は2015年1月8日に書かれたものです。情報が古い可能性がありますのでご注意ください。
スクリーンリーダー利用者が [Tab] キーで Web ページ内のリンクを辿っていく場合、スクリーンリーダーは、リンクの範囲( a 要素に囲まれている範囲)のテキスト、あるいは画像などの代替テキストを読み上げます。
未だに多くの Web サイトで見受けられる、文章中の「こちら」だけにリンクが貼られている場合、この3文字だけではリンク先に何があるのか全くわかりませんので、そのリンクの前後のテキストを確認する必要があります。
JIS X 8341-3:2010 では、「7.2.4.9:リンクの目的に関する達成基準」として、
それぞれのリンクの目的がリンクのテキストだけから特定できるメカニズムが利用可能でなければならない。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。
とありますが、これは等級 AAA の達成基準となっています。一方、等級 A の達成基準では、「7.2.4.4:文脈におけるリンクの目的に関する達成基準」として、
それぞれのリンクの目的が、リンクのテキストだけから、又はプログラムが解釈可能なリンクの文脈をリンクのテキストとあわせたものから解釈できなければならない。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。
となっています。
つまり、「こちら」だけにリンクを貼ることは、同じ段落内のテキストや直前の見出しなどを参照してリンク先が分かれば、等級 A、あるいはこれを含む等級 AA も達成できるということになります。
しかし、[Tab] キーでリンクを辿っている途中で、「こちら リンク」と読み上げられ、前に戻って確認しなければならないという行為は、とても煩わしいのではないかと思うのです。「7.2.4.9 リンクの目的に関する達成基準」は少なくとも等級 AA であるべきではないかと。
“ページネーションの読み上げ対応” の続きを読む »
カテゴリー: WordPress
この記事は2015年1月6日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のカスタム投稿タイプをブログのように使う場合、月別アーカイブページを表示させたい場合があります。この時のパンくずリストについて、自分でパンくずリストを実装する場合は何とでもなると思いますが、Breadcrumb NavXT などのプラグインを利用している場合はなかなか思うように表示されません。
例えば、カスタム投稿タイプ “blog” の2015年1月のアーカイブページの URL は、http://example.com/blog/date/2015/01/ となりますが、このページのパンくずリストが本来ならば、
Home > ブログ > 2015年 > 1月
と表示させたくても
Home > 2015 > 1月
のように、カスタム投稿タイプのアーカイブページへのリンクが表示されず、さらに2015年のリンク先が、通常の投稿の年別アーカイブページ http://example.com/2015/ になってしまいます。
これは、そもそもカスタム投稿タイプの日付アーカイブは WordPress に標準装備されていない機能らしく、パンくずリストを自分で実装する必要があるようです。
今回このブログの月別アーカブページのパンくずリストを、Breadcrumb NavXT を使ったまま、テンプレートで書き替えてみました。
“カスタム投稿タイプの日付ベースアーカイブとパンくずリスト” の続きを読む »
カテゴリー: WordPress
この記事は2015年1月2日に書かれたものです。情報が古い可能性がありますのでご注意ください。
WordPress のカスタムメニューを使って、任意の固定ページをリストアップし、それぞれに登録したアイキャッチ画像を表示する方法を考えてみました。
通常、カスタムメニューの出力には wp_nav_menu 関数を使いますが、これでは固定ページに関連付けられている情報を取得することができません。
そこで、一旦 wp_get_nav_menu_items 関数でカスタムメニュー項目の配列を取得します。そこから各メニュー項目に設定した固定ページのアイキャッチ画像の属性を取得し、タイトルや URL などと共に自由なスタイルで出力します。
<ul>
<?php
$menu_items = wp_get_nav_menu_items('menu_name'); // menu_name: カスタムメニューの名前
foreach ($menu_items as $menu):
$page_id = $menu->object_id;
$thumbnail_id = get_post_thumbnail_id($page_id);
$image_attributes = wp_get_attachment_image_src($thumbnail_id);
$content = get_page($page_id);
?>
<li class="<?php echo $content->post_name; ?>">
<a href="<?php echo get_permalink($page_id); ?>">
<img src="<?php echo $image_attributes[0]; ?>" alt="" width="<?php echo $image_attributes[1]; ?>" height="<?php echo $image_attributes[2]; ?>" />
<?php echo $content->post_title; ?>
</a>
</li>
<?php
endforeach;
?>
</ul>
上記では、wp_get_attachment_image_src 関数の初期値で thumbnail サイズの画像を取得していますが、異なるサイズの画像を取得する場合は、”medium”, “large”, “full” あるいは “array(32,32)” という形でオプションを指定します。
また、アイキャッチ画像だけでなく、<?php echo $content->custom_field_name; ?> のようにして、カスタムフィールドの値も表示させることができます。
この方法で、このサイトのトップページの3つのコンテンツを表示しています。実際は、更にアイキャッチ画像が無い場合に代替画像を表示するための条件分岐とか入れています。
この記事は2015年1月1日に書かれたものです。情報が古い可能性がありますのでご注意ください。
Willさんいんのフロントエンドエンジニア石輪です。日々粛々とマークアップ作業に勤しんでいます。
十数年前からコーディングをやってきましたが、近年は HTML や CSS 以外のコードも書くようになり、jQuery の記述や WordPeress のテーマ作成等においては分からないことが多く、これまでどれだけ沢山のブログ記事に助けられたか数知れません。
プログラミングなど Web のバックエンド技術は、そのソースコードが公開されてなければ知ることができませんが、HTML や CSS、JavaScript といったフロントエンド技術はオープンなもので、ブラウザでソースを表示して辿って行きさえすれば、誰もがそれを見ることが出来る共有技術です。
しかし、CMS の使用が当たり前のようになった今、我々フロントエンドエンジニアが扱わなければならない技術も増えてきました。特に WordPress のテーマ作成は PHP 言語によるプログラミング的要素が多く、ある意味バックエンド技術であり、サイトのソースからは見ることができません。それが、沢山のエンジニアの皆さんのブログによって様々な手法が共有されており、40代後半の固い頭で日々勉強させてもらっています。
予てから一制作会社のエンジニアとして、技術を与えてもらってばかりでなく、私が試行錯誤し、実現できた技術は世の中に共有すべきだと考えていました。過去にブログを書いていたこともありますが、この数年間閉鎖しており、この度のWillさんいんのサイトのリニューアルを機に、新たにブログを始めることにしました。
「フロントエンドエンジニアのblog」というそのまんまのタイトルですが、Webアクセシビリティというフロントエンド技術についても、いろいろ発信していきたいと考えています。どうぞよろしくお願いします。