2025年12月7日 カテゴリー: WordPress , アクセシビリティ
WordPress のメールフォームプラグイン Contact From 7。デフォルトでは、送信ボタンを押下した時のエラーメッセージや送信完了などのメッセージはフォームの下に表示されます。
この応答メッセージをフォームの上に表示して、エラーがある場合にフォームの先頭にスクロールさせるというカスタマイズがあります。よく紹介されているのが次のようなものです。
まずフォームのソースで応答メッセージを表示するショーコード [response] をフォームの先頭に入れます。
[response]
（フォーム要素）
[submit "送信する"]そして、バリデーションエラー時に発火するイベント wpcf7invalid を使ってエラーメッセージの要素 '.wpcf7-response-output' へスクロールさせます。
document.addEventListener('wpcf7invalid', function(event) {
var position = $('.wpcf7-response-output').offset().top;
$('html, body').animate({
scrollTop: position
}, 300);
}, false );確かにこれで送信ボタン押下時にエラーがあると、フォームの先頭に表示したエラーメッセージにスクロールするのですが、このままではフォーカス移動の問題があります。
“Contact Form 7 でエラー時にフォームの先頭にスクロールするカスタマイズで、フォーカスも移動させる” の 続きを読む »
2023年9月14日 カテゴリー: アクセシビリティ
この記事は2023年9月14日に書かれたものです。情報が古い可能性がありますのでご注意ください。
2016年8月3日の投稿「閲覧支援機能とアクセシビリティ 」でも書いたのですが、Webサイト側で、文字サイズの拡大や背景色の変更、画面を読み上げる機能を提供することは、ウェブアクセシビリティとは本来関係のないものです。
弊社の所在地である島根県と島根県内19市町村、計20の自治体の公式サイトを確認したところ、実に18の自治体サイトで文字サイズの変更機能を、背景色の変更機能は16の自治体サイトで、そして読み上げ機能は3つの自治体サイトで提供していました。
もっとも、多くの自治体サイトでは JIS X 8341-3:2016（または 2010）の適合レベル AA 準拠を目標としたウェブアクセシビリティ方針を掲げ、これに則って試験結果を公開していますので、支援機能は付加的なものとして提供しているものと思いますが（決して文字サイズ変更機能の提供をもって「1.4.4 テキストのサイズ変更の達成基準」を“合格”などとするのではなく）、残念ながら2つの自治体サイトでは、文字の拡大機能と背景色変更機能だけをアクセシビリティの取組として掲載していました。
“文字サイズの変更、背景色の変更、読み上げなどの支援機能の提供は非推奨” の 続きを読む »
2016年8月3日 カテゴリー: アクセシビリティ
この記事は2016年8月3日に書かれたものです。情報が古い可能性がありますのでご注意ください。
近年、主に自治体等のサイトで、文字サイズを拡大したり背景色を変更したりできる機能（以下、“閲覧支援機能”とします）を提供しているサイトをよく見かけます。よくWebページの上部にある、「文字サイズ：[小][中][大]」とか「背景色：[白][黒][青]」などとあるボタンです。読み上げ機能や漢字にルビを振る機能が提供されている場合もありますね。自治体サイト向けの CMS に標準で閲覧支援機能が付属しているものが多いからということもあるのでしょう。
ただ、このような機能を提供することは悪いことではないと思いますが、閲覧支援機能を提供することがアクセシビリティだと、勘違いされているケースがかなり多くあるように感じます。
中には、Webサイトのアクセシビリティについて記載されているページに、閲覧支援機能を提供していることだけが、あたかもアクセシビリティに配慮していることをアピールしているかのように書かれているサイトも見受けられます。そのため、一般ユーザーまでもが、閲覧支援機能が提供されてないWebサイトは文字サイズを拡大したり背景色を変更したりすることができない、アクセシブルではないと判断してしまう懸念もあります。
“閲覧支援機能とアクセシビリティ” の 続きを読む »
2015年12月11日 カテゴリー: アクセシビリティ
この記事は2015年12月11日に書かれたものです。情報が古い可能性がありますのでご注意ください。
多くのコンテンツをコンパクトに表示するために、よく用いられるタブ切り替えUI ですが、スクリーンリーダーでの利用やキーボド操作を考慮した場合に、アクセシブルではないと思えるものが少なくありません。
例えば、スクリーンリーダー利用者はタブ切り替えUIであると認識することが難しいと思われます。タブ切り替えUIは一種のページ内リンクと考えられますので、一つのタブを選択したらそのタブが示す先のコンテンツにフォーカスが移動しなければなりません。しかし、多くのタブ切り替えUIは、タブを選択した後に[tab]キーを押すと、リンク先のコンテンツ内、あるいはその次のリンクにジャンプすることはなく、選択したタブの次のタブにフォーカスが移動します。つまり、ページ内リンクとして機能していないということになります。
そのため、これまで jQuery Accessible Tabs をよく利用していましたが、もっと気軽に、自由に設定できるように、jQuery Accessible Tabs の挙動を参考にして簡単な jQuery と CSS で実装してみました。
“アクセシブルなタブ切り替えUIを考える” の 続きを読む »
2015年7月25日 カテゴリー: アクセシビリティ
この記事は2015年7月25日に書かれたものです。情報が古い可能性がありますのでご注意ください。
ソースコードを掲載する時に code 要素と併せて利用する pre 要素（整形済みテキスト）。通常は折り返さずに表示されますので、CSS で overflow: auto; として横スクロールバーを表示するようにしている場合が多いかと思います。
敢えて CSS で記述していなくても、ソースコードをハイライトして読みやすく表示させる SyntaxHighlighter などの JavaScript ライブラリを使うことで、同等の表示になっている場合もあります。
ちなみにこの blog では、ソースコードをハイライト表示するために google-code-prettify を利用しています。
pre 要素内で overflow: auto; によりスクロールが発生した場合（以降、これを “擬似的なインラインフレーム” と称します）、もちろんマウスで操作すれば見えていなかった部分をスクロールして表示することができますが、キーボード操作ではアクセシビリティ上の問題があります。
多くのブラウザでは、その中に a 要素（リンク）がない限り、キーボードで擬似的なインラインフレームにフォーカスすることができませんので、キーボード操作ではスクロールができず、見えない部分を確認することができないからです。
“pre 要素（整形済みテキスト）の折り返しを切り替え可能にする” の 続きを読む »
2015年7月10日 カテゴリー: アクセシビリティ
この記事は2015年7月10日に書かれたものです。情報が古い可能性がありますのでご注意ください。
先日の blog で、音声読み上げの検証のためにスクリーンリーダーを利用しているというWeb制作者は少ないのではないかということを書きました。その理由の一つに、スクリーンリーダーが高価だということもあるかもしれません。PC-Talker は38,000円で、これに Web 閲覧機能を強化する音声ブラウザ NetReader は28,000円（Web制作者向け価格は38,000円）、高機能なスクリーンリーダー JAWS に至っては15万円余りもの価格です。
つまりこれは、スクリーンリーダーを必要とする視覚障がい者は、パソコンを使用するために少なからずとも余計な出費を強いられているということでもあります。
一方、NVDA (NonVisual Desktop Access) は無料で使えるオープンソースの Windows 用スクリーンリーダーです。視覚障がい者が晴眼者と同じように、パソコンと OS 以外の出費をしなくても Windows が利用できるようにとの目的で、オーストラリアの Michael Curran 氏を中心に2006年から開発が進められ、現在は日本語版 を含む40以上の言語に対応しています。
“オープンソースのスクリーンリーダー NVDA と Mac と” の 続きを読む »
2015年6月25日 カテゴリー: アクセシビリティ
この記事は2015年6月25日に書かれたものです。情報が古い可能性がありますのでご注意ください。
視覚に障がいのある方がパソコンを使用される際に利用されるスクリーンリーダー。音声読み上げの検証のためにスクリーンリーダーを利用しているというWeb制作者は少ないのではないでしょうか。アクセシビリティチェックツールに任せて、実際に検証などしないというパターンが多いのではないかと思います。
しかし、例えば音声読み上げでもっとも問題となる画像の代替テキスト。チェックツールでは代替テキスト（alt 属性）の有無はチェックできますが、その内容が正しいか、妥当かどうかまではチェックできません。代替テキストが “画像” だけでも、“xxx.jpg” といったファイル名のままでも、値がどうであれ、とにかく alt 属性がありさえすれば OK と判定されます。
また、実際にスクリーンリーダーを利用されている方を対象に、ユーザーテストを実施する場合もあるかと思いますが、そもそも視覚的に画像を把握できないユーザーに、妥当な代替テキストが与えらているかどうか分かる筈もないですよね。ユーザーテストでストレスなく利用できていても、果たして提供されている情報がすべて入手できているでしょうか。
“画像の代替テキストについて” の 続きを読む »
2015年5月28日 カテゴリー: アクセシビリティ
この記事は2015年5月28日に書かれたものです。情報が古い可能性がありますのでご注意ください。
このブログの2015年4月14日の「タイトルとサムネイル画像の重複リンク 」という記事で、下層ページの一覧などに各ページのタイトルとサムネイル画像があり、そのタイトルとサムネイル画像それぞれに同じページへのリンクが貼ってあるパターンについて、スクリーンリーダーなどでは［Tab］キーで同じリンクを続けて2回辿ることになるほか、サムネイル画像の代替テキストが空だったりすると、そのリンク先を理解することが難しくなるということを書きました。
そして、これを解消する以下の3つの方法を紹介しました。
1. ページタイトルとサムネイル画像を一つのリンク内に含める
HTML5 の a 要素内には複数のブロックレベル要素を含めることができるという仕様により、ページタイトルとサムネイル画像をまとめて a 要素で囲むという方法。
2. サムネイル画像をキーボードでフォーカスさせない
これも HTML5 の仕様を利用し、サムネイル画像の a 要素に tabindex 属性で負の値を設定することで、マウスでクリック可能なまま［Tab］キーではフォーカスされなくする方法。
3. JavaScript でサムネイル画像のクリックに対応する
サムネイル画像にはリンクを設定せず、JavaScript（jQuery）を使って、サムネイル画像をクリックしたらタイトルのリンク先に遷移するようにする方法。
しかし、上記の 2. と 3. にはアクセシビリティ上の問題があるのではないかと気がつきました。
“続・タイトルとサムネイル画像の重複リンク” の 続きを読む »
2015年4月14日 カテゴリー: アクセシビリティ
この記事は2015年4月14日に書かれたものです。情報が古い可能性がありますのでご注意ください。
CMS で作成されたサイトで、下層ページの一覧などにページのタイトルとサムネイル画像、ページの概要があり、そのタイトルとサムネイル画像それぞれに、リンク先となる同じページへのリンクが貼ってあるパターンをよく見かけます。例えば、次のような HTML です。
<h2><a href="hogehoge.html">ページタイトル</a></h2>
<div class="thumbnail"><a href="hogehoge.html"><img src="thmbnail.jpg" alt="" /></a></div>
<p>概要テキスト概要テキスト概要テキスト概要テキスト概要テキスト</p>サムネイル画像が左に、ページタイトルと概要がその右にあるようなデザインでは、1行目と2行目が逆の場合もありますし、サムネイル画像の代替テキストにページタイトルが付けられている場合もあります。
しかし、このような HTML は、スクリーンリーダーなどでは［Tab］キーで同じリンクを続けて2回辿ることになりますし、サムネイル画像の代替テキストが空だったりすると、そのリンク先を理解することが難しくなります。
これではアクセシビリティ的に問題がありますので、これを解消する3つの方法を考えてみます。
“タイトルとサムネイル画像の重複リンク” の 続きを読む »
2015年1月8日 カテゴリー: アクセシビリティ
この記事は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 であるべきではないかと。
“ページネーションの読み上げ対応” の 続きを読む »