植樹会の案内を作るときに考えたいウェブアクセシビリティ
植樹会の申込フォームで、必須項目を赤枠だけで示していないだろうか。色の違いが分かりにくい人はもちろん、日差しの強い屋外でスマートフォンを使う人も見落としやすい。公開後に赤枠を太くするより、項目名に「必須」と添え、入力に誤りがあればどこを直すのか文章で伝える設計にしておきたい。
ウェブアクセシビリティは、障害の有無や利用環境によって、情報の確認や操作が妨げられないようにすること。文字を大きくして読む人、キーボードだけで操作する人、音声読み上げを使う人、通信が不安定な場所で予定を確かめる人では、同じページでも困る箇所が違う。自然保全活動の案内なら、集合場所を取り違えたり、参加条件を確認できないまま申し込んだりすることにもつながる。
公開直前の修正だけでは足りない理由
アクセシビリティは文字色やボタンの見た目だけでは決まらない。何を文章で伝え、どんな順序で見せ、申込みの際に何を尋ねるか。企画段階の判断が使いやすさを左右する。
活動場所を地図画像だけで知らせる場合、後から代替テキストを付けても、画像中の細かな文字まで伝えるのは難しい。住所、公共交通機関からの行き方、集合地点の目印を本文にも書いておけば、読み上げを使う人も、地図を表示しにくい環境の人も確認できる。
公開直前は原稿や写真の確認に加え、フォームと参加受付の準備も重なる。その段階で情報の順序や申込手順を変えるには、担当者間の確認が必要だ。最初に「誰が、何を判断するためのページか」を決めておくと、大きな手戻りを減らせる。
植樹会の案内で、誰が何を判断するのか
参加案内の役目は、申込ボタンまで誘導することだけではない。希望者が作業内容と条件を知り、自分に合う参加方法を判断できることが先だ。苗木を運ぶ距離、斜面の有無、休憩場所、雨天時の対応は、写真だけでは分からない。
「誰でも参加できます」という一文にも気を配りたい。地形や設備によって、できる作業と難しい作業は変わる。条件をぼかすより、作業の選択肢と事前相談の連絡先を示すほうが、参加者にも受け入れ側にも役立つ。障害の種類で参加可否を決めつけず、現地で確認できている事実を書く。
企画書に入れたい確認項目
- 目的：読者はページを読んだ後、日時や参加条件を確認するのか、申込みまで行うのか。
- 対象となる情報：集合場所、移動方法、作業内容、持ち物、費用、荒天時の連絡方法をどこに載せるか。
- 操作方法：スマートフォン、キーボード、音声読み上げで主要な操作を進められるか。
- 担当：原稿、デザイン、フォーム、公開後の更新を誰が確認するか。
- 代替手段：フォームを使いにくい場合の問い合わせ方法と、対応できる範囲。
特別な機能を増やすための一覧ではない。ページを作る前に、必要な情報と担当を整理するための項目だ。開催日や集合場所が変わる可能性があるなら、公開後に誰が直すかも決めておく。
原稿と構造を一緒に設計する
見た目が整っていても、見出しの構造が曖昧だと、読み上げ機能で見出しをたどる人は必要な情報を探しにくい。ページの主題の下に「開催概要」「作業内容」「現地への行き方」「申込方法」などを置き、短い段落で説明する。文字を大きくするだけでなく、HTMLの見出しとして設定しよう。
リンクが「詳細はこちら」だけでは、リンクだけを拾って読むと行き先が分からない。「集合場所と交通手段を確認する」のように、移動先で分かることを文言に入れる。参加判断に必要な情報をPDFや画像の中だけに置かず、本文でも読めるようにしておけば、更新時の見落としも減らせる。
専門用語には短い説明を添える。「下刈り」なら、植えた木の周りで生育を妨げる草を刈る作業、と書ける。初めて参加する人が作業を想像できれば、服装や体力面の準備もしやすい。
色・写真・地図に情報を任せきりにしない
予定表で「緑が受付中、灰色が締切」と色だけに頼らず、各日程に「受付中」「受付終了」と書く。文字と背景のコントラストを確かめ、文字を拡大したり画面幅を変えたりしても情報が隠れないか試したい。一画面に収めようと行間を詰めるより、読みやすさを優先する。
写真の代替テキストは、画像の役割に合わせる。苗木の植え方を説明する写真なら、「苗木の根元に土を寄せる手元」のように、理解に必要な動作を伝える。一方、近くの文章と同じ情報を繰り返す装飾写真に、長い説明は要らない。集合時刻や持ち物を画像に入れる場合は、本文にも同じ文字情報を載せる。
地図には住所と集合地点名を併記する。「駅から徒歩圏内」では距離や道の状態が分からないため、確認できる範囲で距離、所要時間の目安、坂道や未舗装路の有無を書く。現地設備をまだ確かめていないなら、利用できると断言せず、確認先を示そう。
申込みは最後まで操作できて初めて届く
画面上では入力欄がきれいに並んでいても、読み上げ時に「入力してください」としか聞こえなければ、何を書く欄か分からない。各欄に常に見える項目名を付け、必須・任意を文字で示す。入力例は補足にとどめ、入力を始めると消える文字を項目名の代わりにしない。
エラー表示も「入力に誤りがあります」だけで済ませず、該当する項目と直し方を文章で伝える。送信後は受付結果を画面で確認でき、申込内容を修正する手順も分かるようにしたい。案内が自動で消えたり、制限時間が短かったりすると、入力に時間がかかる人は手続きを終えにくい。
キーボードではTabキーで項目とボタンを順にたどり、選択中の位置が見えるかを確かめる。日付選択や確認画面で操作が止まることもあるので、最初の欄から送信完了まで通して試す。電話やメールの相談窓口を設けるなら、受付時間と返答までの目安も添える。ただし、フォームの不備を窓口だけで補おうとはしない。
公開前の確認を、役割ごとに分ける
最後に一人で全ページを見ても、内容と操作の両方を確認しきるのは難しい。原稿担当は日時や条件が文章で伝わるか、デザイン担当は拡大時の表示や色だけに頼った表現がないかを確認する。制作担当は見出し、フォームの項目名、キーボード操作を確かめる。道順や作業内容の記述は、現地担当にも見てもらいたい。
確認には、ウェブコンテンツのアクセシビリティに関する国際的な指針「WCAG」を参照できる。ただ、チェック項目を満たした記録だけで、誰にとっても使いやすいとは言えない。自動検査で見つかる問題もあれば、案内文の分かりにくさのように、人が読んで気づく問題もある。可能なら、異なる操作方法を使う人に申込みを試してもらい、どこで詰まったか記録する。
小さく始める公開前テスト
- スマートフォンで文字を拡大し、開催日時から申込方法まで横スクロールなしで読めるか確かめる。
- 画像を見ずに、集合場所、作業内容、持ち物、連絡方法が文章から分かるか確認する。
- マウスを使わず、キーボードだけでフォームの入力と送信を試す。
- 必須欄を空にして送信し、エラーの場所と直し方が分かるか確かめる。
- 公開後に変更が起きやすい日時、定員、交通案内の修正手順を確認する。
「操作できたか」だけでなく、どの画面幅で、どの手順で迷ったかも残しておくと修正しやすい。確認用の申込みが実際の受付に混ざらないよう、テスト環境と担当者間の連絡方法も決めておこう。
公開後の更新まで計画に含める
公開時に使いやすいページでも、更新の仕方しだいで情報が届かなくなる。雨天による集合場所の変更を写真内の文字だけで知らせたり、新しい日程を表の末尾に色だけで追加したりしない。変更は該当する本文に反映し、必要に応じて更新日を添える。申込済みの人への連絡と、これから参加を考える人への案内は分けて考えたい。
古いページを引き継ぐなら、すべてを一度に作り直すより、現在参加者が使う案内とフォームから確認する。掲載情報を点検する順番は、自然保全の過去記事を見直す優先順位と確認手順の考え方も参考になる。ただし、過去の開催記録を直す作業と、次回の参加条件を安全に伝える作業は分けて管理したい。
次の植樹会の企画書では、「集合場所」の欄を地図の有無だけで終わらせない。本文に載せる住所、最寄りの交通手段、現地で確認済みの道の状態、変更時に書き換える担当者まで記入する。そこが決まれば、地図を表示できない人にも伝わる案内を書き始められる。
