New 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 要素（整形済みテキスト）の折り返しを切り替え可能にする” の 続きを読む »