Better explanation when demanding a CAPTCHA for an HTML comment
It is possible for a commeter to be shown a CAPTCHA even when the journal owner has set "Show CAPTCHA to nobody". It would be good if the reason for this was explained somewhere.
This is pretty obscure (only discovered due to bugfix-testing), but bear with me...
- Users set in account settings -> Privacy who will be shown captchas when they try to comment.
- In addition to this, and entirely independent of this setting, there is a site-wide configuration setting that causes captchas to be shown to people who use HTML in comments (by default on Dreamwidth this is shown only to anonymous commenters who use HTML. There is an option to enable it for all HTML commenters, which other sites using the code could turn on).
- It is thus possible for somebody making a comment (which includes HTML) to be shown a captcha even though the journal owner has set that captcha will be shown to "nobody". The text with the captcha doesn't indicate the reason that it is being requested, but simply says "Please fill out the CAPTCHA as an anti-spam measure".
I don't think it's actually a bug, hence I'm putting it in dw_suggestions, but I think that some journal owners might feel aggrieved about this - for instance if they have assured readers with accessibility needs that they will not need to complete a captcha to comment.
I imagine that there are good reasons for preventing robots from using HTML in comments, but I think that the text shown to the commenter when they are presented with the captcha should be amended to explain why it is happening.
An alternative (or additional) solution would be to add text to the Account Settings page to explain that setting "nobody" may still be overridden - but I think this would add unnecessary complexity to Account Settings for something that few will encounter or be bothered by.
Should be implemented as-is.
Should be implemented with changes. (please comment)
Shouldn't be implemented.
(I have no opinion)
(Other: please comment)