Problem/Motivation
The description of the Inline Form Errors module has been updated to:
Enabling inline form errors improves accessibility of web forms errors so that they meet WCAG 2.0 requirements. Unfortunately, some functionality within Forms API may not work as desired.
There are a few things to improve with this text:
- It uses the words "unfortunately" and "desired", which is emotional language that does not comply with our content style guidelines. We should simply state the limitations of the experimental module, not apologize for them. Reference: https://www.drupal.org/node/604342 "As desired" is also vague; who desires it? What do they desire?
- The module does not need to tell you that enabling the module does what the module does. It should just tell you what the module does.
- "Forms API" is not something the site user should know or care about.
- It is overly long.
Proposed resolution
Make the description more declarative.
This issue is filed against 8.1.x because it involves a UI text improvement, which is allowed during the beta, and is for an experimental module.
Remaining tasks
Patch needs review.
User interface changes
Inline Form Errors text shortened to:
Adds WCAG 2.0 accessibility compliance for web form errors. Some form functionality may not work with this experimental module.
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
inline-description.patch | 760 bytes | xjm | |
Comments
Comment #2
xjmI know a lot of usability work has gone into module descriptions and help page text, so this might be an area we should always get usability signoff on.
Comment #3
xjmComment #4
xjmComment #5
yoroy CreditAttribution: yoroy commentedBig improvement for the right reasons. It’s a pity we can’t be more precise than saying "some functionality" (argh, which?!).
Comment #6
xjmThanks @yoroy. I tried to think of a way to summarize the bugs with it rather than just "some functionality" but did not come up with anything more straightforward than "this experimental module does not work properly yet." #2346773: Details form element should open when there are errors on child elements and #2509268: Inline errors repeated on child elements in module uninstall form and #2687249: Improve inline form errors for file upload fields are examples -- a wide selection of bugs in many flavors!
Comment #7
yoroy CreditAttribution: yoroy commentedUnderstandable. It's something to keep in mind with experimental modules: how many discaimers and when/where?
The last sentence can be read as if this module breaks forms that would otherwise work. Is that true?
Comment #8
yoroy CreditAttribution: yoroy commentedComment #9
xjmYes, I'd say it kind of does based on those outstanding bug reports. It will make some validation errors cause forms to seem impossible to submit (because the user cannot find the validation error), and make a confusing mess of others.
(FWIW, I'm going to encourage that the module needs to be either fixed up for 8.2.x or taken back out of core, since those bugs haven't really made progress since release.)
Comment #10
yoroy CreditAttribution: yoroy commentedThanks. This text change is rtbc then :)
Comment #13
catchOK that looks a lot better. This crossed my mind with the original patch, but also I can't see anyone actually trying to use this module at all yet, so couldn't really think of what to do with it.
Committed/pushed to 8.2.x and cherry-picked to 8.1.x. Thanks!