Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Follow-up to #1493324: Inline form errors for accessibility and UX
Currently postponed on #1870006-10: HTML5 validation with table sticky header is misaligned over the toolbar.
Problem
The inline error massage handling is great, but it's a nuisance to be snapped to the form (input) element related to the error instead of the elements title (a user should be able to see what the field is about).
Related: in case the menu toolbar is enabled the form element is often not visible at all (below the top bar). #1440628: [Meta] javascript toolbar/tableheader with url fragment mess
Proposed Resolution
It would seem that all form field errors get an error wrapper around them so let's always jump to it, instead of the form element itself.
We could add a dedicated anchor tag above the field label and/or fieldset.
Add an ID to the form element labels and point the links to those ID's instead of the ID of the input element.
This will allow the user to see the form label and any instructions that are pertinent to resolving said error.
Remaining tasks
Update error message link target to point to error message wrapper(Not relevant anymore)Add dedicated anchors above field labels and fieldsets(Not valid HTML5)- Research if the focus goes to the target input element when we jump to labels.
- Add ID's to field labels
- Point inline error links to the
anchorslabels when present, and the input element otherwise
| Comment | File | Size | Author |
|---|
Comments
Comment #1
BLadwin CreditAttribution: BLadwin commentedComment #2
BLadwin CreditAttribution: BLadwin commentedI marked this as a minor issue, as the error message does take you to the form field in question. This is a minor tweak to the functionality, but seems more cosmetic than functional. If my assumption of this after reading https://www.drupal.org/core/issue-priority is incorrect, please rectify and update the issue priority.
Comment #3
vijaycs85Let's postpone until #1493324: Inline form errors for accessibility and UX gets in...
Comment #4
dmsmidtCurrently the error messages are in most cases below the fields. So the problem is less problematic in this regard.
However, in some cases the message are still above the input elements (fieldset, checkboxes, password change, etc.).
I find it also problematic that the field titles are not visible anymore after jumping to the problematic field.
A good solution would be to not target the ID of the form elements but to
add dedicated anchors above the labels and target thoseadd an ID to the label (if there is a label) and target those.(This also means we don't need the wrapping error-div back, jay).
There is another problem: when there is a top menu bar, the error message and input item are often below the bar.
This is even a bigger problem than the original because it can seriously confuse the user.
In fact it is a more general problem: when using the admin toolbar the targeted content will always be (partly) invisible after the jump.
Using a dedicated anchor tag could also prove part of the solution for this extra problem (using css offsets).
I'll create an issue for the toolbar to address this problem.
Edit:
<a name='foo'></a>is no valid HTML5, change commentComment #5
nod_for the more general problem, see related.
Comment #6
dmsmidt#5 @nod_ Thanks for pointing out that issue.
Comment #7
dmsmidtdeleted
Comment #8
dmsmidtComment #9
dmsmidtComment #10
dmsmidtWe should check that if we jump to the labels, the fields still get focus somehow.
Comment #11
xjmComment #13
mgiffordComment #14
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedComment #15
SKAUGHTperhaps this should only be a drupal.behaviour to scroll to the top of the form-item. then, keeping focus on the input itself.
reminder:
#2560467: Inline Errors not shown for container elements -- containers don't have labels/legend.
Comment #16
dmsmidtAlso, it becomes more common to not have a label at all, in favor of a placeholder. So this functionality shouldn't break if someone removes the label (via code).
I think we should by default still jump to the id of the form field, but indeed use some JS to get the label in view IF it is present.
We should wait for #1870006-10: HTML5 validation with table sticky header is misaligned over the toolbar and could improve that patch later, by instead of bringing the element (field) into view, to bring the closest label into view if present.
Comment #17
rootworkI've updated the summary with a note saying this is postponed on #1870006-10: HTML5 validation with table sticky header is misaligned over the toolbar.