トピックを検索
プレビューも編集も削除もできないまま公開されてしまうコメント欄
レシピブログのコメント欄は「コメントを送信」を押した瞬間にコメントを公開するうえ、事前のプレビューも、後から編集や削除をする手段もないため、書き間違いが名前付きでそのまま残ってしまう
問題
読み間違い、打ち間違い、音声入力の聞き違いをした人が、事前に確かめることも後で直すこともできないまま、その間違いを自分の名前で公開してしまう
あるレシピブログはWordPressで作られていて、各レシピの下に、WordPressがどのブログにも用意するコメント欄があります。この例では、ここで関わる部分だけを残しています。コメントの入力欄、名前の欄、そして「コメントを送信」ボタンです。すばやく書けるように作られていて、たいていのコメントはそのとおり、書いて押せば終わりです。
トマトスープを作った読者が、こつを書き込もうとします。塩は小さじ2杯のつもりでしたが、「大さじ2杯」と書いてしまいました。どちらも「さじ」で終わる、よく似た言葉です。このブログはコメントを承認待ちにしない設定のため、「コメントを送信」を押すと、コメントはその場で、読者の名前とともに、レシピを読むすべての人に公開されます。少しして読み返し、間違いに気づきます。コメントの下には「編集」も「削除」もなく、直し方を示すものもありません。ブログの持ち主にメールを書いて、待つしかありません。そのあいだに、次にスープを作る人が、このこつのとおりに塩を入れるかもしれません。
達成基準3.3.6「エラー回避（すべて）」はレベルAAAです。利用者に情報の送信を求めるページでは、次の三つのうち少なくとも一つが必要です。送信を取り消せること。入力されたデータの入力エラーがチェックされ、修正できること。確定する前に、情報を確認し、確定し、修正する手段があること。3.3.4はAAで同じことを求めますが、対象は法的な義務、金融取引、サイトに保存された利用者のデータの変更、試験の回答に限られます。コメントはどれにも当たらないため、3.3.6の対象になります。
このフォームも欄の検証はしています。コメントや名前が空だと、エラーが返ります。文字どおりに読めば、これは達成基準の二つ目の方法に当たり、厳密に読めばそこで終わるという見方もあります。しかし、WCAGは入力エラーを、フォームが受け付けない情報と定義しています。「塩を大さじ2杯」は受け付けられるため、この達成基準が防ごうとしている間違いには、チェックが届きません。3.3.6が十分な達成方法として示すのは、3.3.4の達成方法をすべてのフォームに使うことです。送信の前に回答を確認して修正できる段階（G98）、送信後に変更や取り消しができる期限の明記（G164）、送信ボタンに加えたチェックボックス（G155）、削除した情報を復元する手段（G99）、操作を続ける前の確認（G168）です。どれも検証ではなく、このフォームはどれも備えていません。
WordPressは、コメントを書く訪問者に、投稿前のプレビューも投稿後の編集も用意していません。期限付きの編集を加えるには、プラグインを使います。一方Drupalには、コメントを保存する前のプレビューを必須にする設定が、本体に用意されています。
コメントは公開され、書いた人の名前が付き、レシピがある限りその下に残ります。レシピ、やり方の解説、商品のページでは、ほかの人がそこに書かれたとおりに行動します。間違えやすい人ほど、サイトの持ち主にメールで訂正を頼むことも負担になりがちです。
10グループ中4グループに影響
- 全盲 （影響あり）
- 弱視 （影響あり）
- 色覚 （影響なし）
- ろう （影響なし）
- 難聴 （影響なし）
- 発話 （影響なし）
- 手の操作 （影響あり）
- 筋力・可動域 （影響なし）
- 認知 （影響あり）
- 光過敏 （影響なし）
- 言語・認知・学習の能力が限られる ディスレクシアのある人は大さじと小さじを読み違えることがあり、記憶や注意に困難がある人は、入力中の間違いに気づかないことがあります。間違いが見えてくるのは、ほかの人が見るとおりの形で、コメントだけを改めて見たときです。
- 手の操作が限られる 音声入力は言っていない言葉を書くことがあり、手のふるえやスイッチは余計なキーを入れることがあります。プレビューがなければ、ソフトが何を書いたかを初めて見るのは公開された後です。
- 視覚を使わない 入力欄の中でコメントを確かめるには、1行ずつ移動して読むことになります。送信した後は、スレッドを読み返すまで間違いが耳に入らないことがあり、そのときにはもう直せません。
- 視覚が限られる 拡大していると入力欄の数語しか見えないため、数行上の間違いは、「コメントを送信」を押すときには画面の外です。
各欄にはラベルがあり、ボタンには名前があり、フォームは自動チェックをすべて通ります。コメントをプレビュー、編集、削除できるかは、「コメントを送信」の後にサーバーが何をするかで決まり、スキャナーが実際のサイトにコメントを投稿することはありません。フォームのマークアップには、送信内容がどう扱われるかが書かれていないため、EaseWebの診断にもこれを見つけるチェックはありません。コーディングアシスタントにこのフォームの「エラーを防いで」と頼むと、コメント欄にminlengthとmaxlengthを加えることがあります。短すぎるコメントは防げても、「大さじ」は防げません。
試してみる
小さじのつもりで大さじと書いてしまったコメントを送信し、そのあと直してみましょう
公開される前にコメントを見せてくれるもの、または後で編集や削除をする手段はありますか？
問題あり 修正できますか？
コメント
Alex・2日前
2回作りました。先にトマトをローストするのがおすすめです。
修正方法
コメントを公開前に確認するか、公開後に直せるようにする
<h2>コメント</h2><ol class="comments"> <!-- 新しいコメント。「コメントを送信」を押すとすぐに公開される --> <li id="comment-1042"> <p><b>Sam</b>・たった今</p> <p>おいしいスープでした。最後に塩を大さじ2杯加えるのがおすすめです。</p> </li></ol><form method="post" action="/comments"> <label for="comment">コメント</label> <textarea id="comment" name="comment" required></textarea> <label for="author">名前</label> <input id="author" name="author" required autocomplete="name"> <button type="submit">コメントを送信</button></form>問題点3点
- フォームが届くとすぐに、サーバーがコメントを公開します。
- 公開される前に、コメントを本人に見せる段階がありません。
- 投稿した後、書いた本人がコメントを編集する手段も、削除する手段もありません。
投稿する前の、スレッドの中のプレビュー
<h2>コメント</h2><ol class="comments"> <!-- 新しいコメント。プレビューの下の「コメントを送信」を押すと公開される --> <li id="comment-1042"> <p><b>Sam</b>・たった今</p> <p>おいしいスープでした。最後に塩を大さじ2杯加えるのがおすすめです。</p> </li></ol><form method="post" action="/comments/preview"> <label for="comment">コメント</label> <textarea id="comment" name="comment" required></textarea> <label for="author">名前</label> <input id="author" name="author" required autocomplete="name"> <button type="submit">プレビュー</button></form>修正の手順4ステップ
- フォームのボタンを「プレビュー」にし、押すと、ほかの誰にも見えない下書きとしてコメントを保存するようにします。
- 同じレシピのページを、下書きの位置で開いて返します。コメントは公開されるときと同じスレッドの中に、本人にしか見えないプレビューとして表示されます。レシピもそれまでのコメントもページに残るので、ほかの人が読むのと同じ場所でこつを読み返せます。
- フォームがあった場所に「コメントを送信」と「コメントを編集」を置きます。「コメントを編集」では、コメントと名前を保ったままフォームが戻ります。間違いは一か所を直すだけで済み、コメントを書き直す必要はありません。
- コメントを公開するのは「コメントを送信」だけにします。
これで修正前の例は直り、G98のとおり、確定する前にコメントを確認し、確定し、修正する手段があるため、3.3.6を満たします。
この方法を選ぶ理由：確定する前に、注文内容を読み返せるようにする
どちらも3.3.6を満たします。プレビューを使ってください。ほかの人が読む前に間違いを止められるのはプレビューだけで、ログインしていてもいなくても、どの端末でも、すべての人に使えます。できれば「編集」と「削除」も加えてください。スレッドに載ったコメントを見て初めて気づく間違いにも対応できます。ただし、「編集」と「削除」だけでは、見つかるまで間違いは公開されたままです。
プレビューから投稿までのあいだ、下書きはページの中だけでなく、サーバーに保存します。そうすれば、戻るボタン、「コメントを編集」、再読み込みのどれでも、コメントと名前がそのまま戻ります。長いフォームについては「同じ住所を二度入力させるチェックアウトフォーム」も参照してください。
承認待ちのコメントも、この役目は果たしません。WordPressは初期設定では、まだ承認されたコメントがない人のコメントを承認待ちにし、書いた本人には「あなたのコメントは承認待ちです。」と添えて表示します。ブラウザーに情報が保存されていなければ「あなたのコメントは管理者の承認待ちです。これはプレビューで、コメントは承認後に表示されます。」となります。どちらの場合も、本人は見られても変更はできず、管理者は書かれたままの内容を承認します。
一部のフォーラムにある、入力に合わせて入力欄の下で更新されるプレビューでは、書式がどう表示されるかは分かります。しかし、映っているのは入力欄のすぐ横にある同じ言葉で、ボタンを押せばそのまま公開されるため、確認の段階の代わりにはなりません。
編集できる期限は、編集を必要とする人に合わせて決めます。WordPressのコメント編集プラグインには、訪問者の編集期限を初期設定で5分とするものがありますが、読むのに時間がかかる人や、戻ってきてから間違いに気づく人には短すぎます。アカウントのあるサイトなら、コメントをアカウントに結び付け、どの端末からでも、より長く、または期限なしで編集できるようにできます。返信が付いた後にコメントが変わったときは、そのそばに「編集済み」と示し、返信の意味が通るようにします。
削除はデータを消すため、AAの3.3.4の対象になります。先に確認するページか、直後の「元に戻す」で対応できます。「質問が読み上げられない確認ダイアログ」と「読む前や元に戻す前に消えるトースト」を参照してください。支払い、法的な同意、保存されたデータの変更では、同じ選択がAAで必須です。「確認も取り消しもできずに支払いが確定するチェックアウト」を参照してください。
修正の確認
5項目、マウス不要
確認方法： キーボード、スクリーンリーダー、拡大表示
OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。コメントの仕組み、そのプラグイン、テーマを変更した際は、再度確認します。
制限
このサンプルは、どのフォームでも同じ結果になることを保証するものではありません。例はブログのコメントですが、レビュー、フォーラムの投稿、メッセージ、問い合わせ、会員登録も、送信するボタンで同じ選択が必要です。コメントが投稿されたことを、画面とスクリーンリーダーの両方で伝えるのは別の問題です。「読み上げられないフォームの送信結果」を参照してください。3.3.6はAAAで、W3Cはサイト全体にAAAを求めることを推奨していませんが、公開されるコメントは、間違いを防ぐ手間は小さく、残ったときに困ることは大きい場所です。サイトが送るメールも含めて一連の流れ全体を、実際の読者と、その人たちが頼る道具で確認してください。
よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。
EaseWebのサービス
修正した問題を、次のリリースで再発させない
このガイドのような修正方法を、コーディングエージェントが従うルールと、CIのチェックに組み込みます。あわせて定期的に、キーボードとスクリーンリーダーで手動の再テストを行います。