Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#52406 closed task (blessed) (fixed)

Extend the validity period of the comment moderation hash

Reported by: johnbillion's profile johnbillion Owned by: johnbillion's profile johnbillion
Milestone: 5.7 Priority: normal
Severity: normal Version: 5.7
Component: Comments Keywords: has-patch commit
Focuses: accessibility Cc:

Description

When a visitor submits a comment and it gets held for moderation, a moderation-hash query variable is added to the redirect URL so the moderated comment can be seen by the visitor. This was introduced in [47887] for #49956.

The moderation hash is valid for any length of time but it's only respected for one minute (ref, ref).

Since [50109] commenters can opt-in to receiving an email notification when their moderated comment gets approved, and this feature uses the same moderation hash.

The problem is that the one minute window also applies to submitting the notification opt-in form and reloading the page a second time. If you're on a slow connection, you're using assistive technology, or you're a slow reader or slow decision maker, you can easily take longer than 60 seconds to submit this form.

I propose extending the time that the moderation hash is respected to ten minutes. Any objections?

cc @whyisjake @peterwilsoncc @jonkolbert @ayeshrajans @imath

Attachments (2)

52406.diff (2.1 KB) - added by johnbillion 3 years ago.
Screenshot 2021-02-09 at 14.32.15.png (46.9 KB) - added by johnbillion 3 years ago.

Download all attachments as: .zip

Change History (14)

#1 @joedolson
3 years ago

From an accessibility perspective, any interface where timing matters should allow the timing to be a) exposed to the user and b) adjustable by the user. So for best practices on accessibility, we should add an indicator telling the user how much time they have left to complete this form with the option to extend it.

There are a few options for how this can be handled, see https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html

#2 @imath
3 years ago

Hi thanks @johnbillion for opening this ticket & @joedolson for this a11y concern. Maybe we could fix this ticket in 2 steps?

  1. Extend time to 10 minutes for 5.7
  2. Improve this including controls into the form to manage this timing when commenter has not opted in to cookies.

I believe 2 should need some JavaScript to inform about the remaining time.

#3 @hellofromTonya
3 years ago

  • Milestone changed from 5.7 to 5.8

5.7 Beta 1 is happening in about 25 minutes. Ran out of time to get this ticket into the release. Punting to 5.8.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

#4 @peterwilsoncc
3 years ago

@joedolson While indicating how much longer the link is valid for seems like a good idea, I worry about allowing users to extend it via the UI. Allowing users to turn it off would introduce the problem in #49956, either allowing them to adjust or extend it seems to partially reintroduce the bug as spammers would be able to exploit it.

I'm happy if people decide to extend the timeout from one minute, I'll review [50109] for the additional context.

#5 @johnbillion
3 years ago

  • Milestone changed from 5.8 to 5.7
  • Type changed from enhancement to task (blessed)

As this is an issue that was introduced in 5.7 ([50109]), I'd like to move this back to the 5.7 milestone. I think we can reclassify this as a task that is an extension of the already committed feature.

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


3 years ago

#7 @johnbillion
3 years ago

  • Keywords dev-feedback removed

Summary of discussion in the #accessibility channel today:

  • If a user misses the time window then it does honour their request to be notified of the approval, they just don't see a confirmation message and their unapproved comment disappears.
  • It was agreed that 10 minutes is likely sufficient time for any user to submit the opt-in form, although this isn't based on any research.
  • It was suggested to split the display of the confirmation message (after submitting the opt-in form) from the display of the pending comment, which would allow the former to have no time limit and the latter to remain visible only within a short window.
  • It might be too late to refactor the confirmation message for 5.8, unless someone wants to own that.

It would be great to do the latter for 5.7 but my preference would be to bump the time limit to 10 minutes and work on a solid improvement for 5.8.

Any objections?

Version 0, edited 3 years ago by johnbillion (next)

#8 @alexstine
3 years ago

That sounds like a fair way to go forward for now. Get the 10min time limit in place and then make further improvements for 5.8.

#9 @imath
3 years ago

I agree, let’s extend the time limit and take some more time to improve a11y 👌

@johnbillion
3 years ago

#10 @johnbillion
3 years ago

  • Keywords has-patch added; needs-patch removed

52406.diff increases the moderated comment window from 1 minute to 10. Screenshot above of HTTP response headers showing a 10 minute window.

#11 @davidbaumwald
3 years ago

  • Keywords commit added

Looking at the patch and the discussion above, I think this one is ready to move forward. Marking for commit.

#12 @johnbillion
3 years ago

  • Owner set to johnbillion
  • Resolution set to fixed
  • Status changed from new to closed

In 50271:

Comments: Extend the duration of the window within which unapproved comments are visible by their author.

This extension is necessary because the comment approval notification opt-in form introduced in [47887] uses the same mechanism, and the previous limit of one minute meant that users on a slow connection, using assistive technology, with limited motor skills, or who are generally indecisive may not complete the opt-in action within one minute, and therefore not see the confirmation message.

Props joedolson, imath, hellofromTonya, peterwilsoncc, alexstine, davidbaumwald 

Fixes #52406

Note: See TracTickets for help on using tickets.