• wp.a11y.speak()はAJAXで変わった状態を短い文でスクリーンリーダーへ伝える

wp.a11y.speak()はAJAXで変わった状態を短い文でスクリーンリーダーへ伝える

公開日: 執筆:佐藤

WordPress 4.2でAJAXの保存結果や検索結果の更新を伝えるなら、画面の色やanimationだけに頼らず、wp.a11y.speak()へ短い通知文を渡します。通知するのはbuttonを押した事実ではなく、処理が成功したか、失敗したかという結果です。

wp.a11y.speak()は、動的に変わった画面の状態をスクリーンリーダーへ伝えるためのJavaScript methodです。見える利用者向けのmessageを消す機能ではありません。画面表示と読み上げを同じ処理結果から出します。

動的な変更は画面を見ただけでは伝わらない

AJAXを使う管理画面では、pageを読み直さずに保存結果や検索件数を更新できます。色、animation、表示文の差し替えで変化が分かる利用者がいる一方、スクリーンリーダーには更新が伝わらない場合があります。

WordPress Accessibility Teamの解説では、更新領域全体をARIA live regionにすると、内容をまとめて読み上げる場合があるため、簡潔なmessageだけを伝える方法が示されています。

たとえば設定一覧の一行を更新したなら、「一覧を更新しました」では広すぎます。「表示件数を保存しました」のように、何が完了したかを一文にします。失敗時は「保存できませんでした。入力内容を確認してください」のように、結果と次の行動を分けます。

wp-a11yをscriptの依存関係へ加える

pluginやthemeのJavaScriptから使う場合は、wp-a11yを読み込みます。独自scriptが必ずあとから実行されるよう、wp_enqueue_script()の依存関係へ指定します。

function satolab_enqueue_admin_status_script() {
    wp_enqueue_script(
        'satolab-admin-status',
        plugin_dir_url( __FILE__ ) . 'admin-status.js',
        array( 'wp-a11y' ),
        '1.0',
        true
    );

    wp_localize_script(
        'satolab-admin-status',
        'satolabStatus',
        array(
            'saved' => __( '設定を保存しました。', 'satolab' ),
        )
    );
}
add_action( 'admin_enqueue_scripts', 'satolab_enqueue_admin_status_script' );

これは説明用の仮例です。admin-status.jsとtext domainは、実際のpluginに合わせます。通知文をPHP側で翻訳可能にし、JavaScriptへ渡しています。

wp.a11y.speak()はDOMの準備が終わったあとに呼びます。

jQuery(function () {
    wp.a11y.speak(satolabStatus.saved);
});

実装では、pageを開いた直後ではなく、保存が成功したresponseを受け取った箇所で呼びます。buttonを押しただけで成功messageを読み上げると、通信失敗時に画面の状態と通知が食い違います。

通知文は変化した結果だけを短く伝える

wp.a11y.speak()は、bodyへ通知用の領域を追加し、そこに渡したtextの変化を支援技術へ伝えます。この領域はstatus roleを持ち、aria-liveのpoliteとaria-atomicのtrueに相当する動作をします。

politeは、現在の読み上げを通常は遮らず、低い優先度で更新を伝えるための指定です。そのため、保存完了、絞り込み結果、一覧更新などに向きます。session終了が迫っている警告のように、直ちに割り込ませる必要がある通知は、同じ扱いにしません。緊急度を決めずにすべてのmessageを強く通知すると、操作を妨げます。

通知文には、更新した領域のHTMLをそのまま渡さないでください。商品一覧を絞り込んだなら、「12件を表示しました」のように結果だけを伝えます。件数を取得できないなら、「検索結果を更新しました」とし、存在しない数字を作りません。

見えるmessageと読み上げるmessageを同じ結果から作る

スクリーンリーダー向け通知を追加しても、画面上の保存messageは残します。見えるmessageと読み上げが別の条件から作られると、一方だけ成功し、もう一方だけ失敗することがあります。

処理は次の三段階に分けます。

段階 確認すること 表示と通知
request前 入力値と権限を確認する 処理中であることを必要に応じて示す
response受信 成功か失敗かを判定する 同じ判定から画面messageと読み上げを作る
更新後 focus位置と操作可能な状態を確認する 次にできる操作を伝える

wp.a11y.speak()は権限確認、nonce、server側のvalidationを代替しません。通知を付ける作業と、保存処理を安全にする作業を分けてください。

front endで使うthemeでは、通知領域に使われる.screen-reader-text classもtheme側で扱えるようにします。管理画面だけで使うpluginと、公開pageでも使うthemeでは、確認範囲が異なります。

制作を委託する場合は、「アクセシビリティ対応済み」という報告だけで終わらせず、どの操作の成功、失敗、0件を通知するかを一覧で受け取ります。最初の一手は、pageを読み直さずに結果が変わる操作を一つ選び、見えるmessageと読み上げるmessageが同じresponseから作られているかを確認することです。

戻る