Login form's aria-describeby points to an element that doesn't exist

hmm, do we have to unset it if we can just remove the code that sets it to begin with? This needs accessibility sign off

We need some one on the accessibility team to review this patch and give it a thumbs up. I've tagged it so someone should see it.

No problem! Thanks for the work

Dom., I'm one of the organizers of the Accessibility Group and can at least give you an initial review.

I haven't been actively participating for a while, and I'm not a scripter, so I would need to see the HTML produced with and without this patch.

aria-describedby is one way to add a label to a form field or other element. Labeling a form field seems to be the point of using it here.

It sounds like the issue is that the id that this aria-describedby points to is either not being created, not being set, or being cleared after it is set. Whatever is going on, the correct fix is more likely to be to ensure that id element is created, given a value, and kept intact in the code produced for this login form. Removing the aria-describedby because its target is not found is probably not what we want to do.

What we probably need to do is:

1. Replace aria-describedby, which is meant to point to a description (usually a sentence or two) of the feature, with aria-labelledby, which is meant to point to a simple label.
2. Confirm that somewhere on the page containing the form is an element with an id attribute that matches the contents of this aria-labelledby.

For example, this code, borrowed from an example for another aria property, aria-posinset, in the specification for ARIA 1.0, is the pattern we are expecting to see:

   <h2 id="label_fruit"> Available Fruit </h2>
<ul role="listbox" aria-labelledby="label_fruit">
[etc.]

The element with the matching id might be immediately adjacent to the element being labeled, but it could also be anywhere else in the code. We just need for the connection to be explicitly stated with an id attribute on one element that matches the aria-labelledby attribute on another.

By the way, you're right to focus on the aria-describedby, because having autocapitalize, autocorrect, or both active in a login field is completely inconsistent with WCAG 2.0. With respect to forms, WCAG calls for this approach:

• As much as possible, help the user avoid making a mistake. For example, when all possible answers are known, don't make the user type them in. Give them a selection box instead.
• When it isn't possible to help the user avoid mistakes, help them recognize and correct any mistakes they do make. Helping a user to correct a mistake might mean reminding them that an email address must have an "@" followed by a domain name.
• But don't change their entries—let them decide whether they need to be changed. In other words, if they type "suger," instead of changing it to a correctly spelled word automatically, highlight it and give them choices that might be right. Did they mean "sugar"? "super"? "surge"?
• And don't be so helpful that you make it easier for spambots and miscreants to get into secure environments.

I hope you can see my point:

• Alerting users to potential errors in form fields is good.
• But by changing entries instead of notifying the user that there is (or might be) an error and letting the user decide how to address it, activating autocorrect and autocapitalize in any form fields actually violates WCAG.
• And WCAG 2.0 explicitly does not require or encourage error checking in login fields, because to do so would undermine the security of the website or application. For similar reasons, error checking shouldn't be done on input fields for account numbers or other sensitive information. You should not say, "The security code for that Visa card isn't 333 any more. Try 666 instead."

And thanks for your work to make Drupal even more accessible!

Updating to tag as an Accessibility issue.

This patch removes autocapitalize and autocorrect from the name and pass fields and satisfies W3C requirements. Running the existing code through validator showed that those two attributes were not allowed.

Thanks, JesseStugis! It looks like we almost have this solved.

Dom., as to the aria in this login form, is it needed?

As I said, the purpose of aria-labelledby is to associate a label with a field when it would otherwise be hard to do. In the example I cited above, I'm not sure if the other possible approach would work. That would be:

<h2><label for="fruit"> Available Fruit </label></h2>
<ul role="listbox" id="fruit">
[etc.]

But labeling the fields on a login form isn't complex at all, so I'm not sure why we would even need aria here. Usually label is enough by itself.

So is this another of our issues involving aria orphans? Should we just remove the aria-describedby?

Thanks for starting this issue Dom., the login form is one of the most important forms in Drupal, so important that we get this right.

The UX folks are pushing against adding any more description elements if possible. There would need to be a strong case for including it but we probably shouldn't have the aria-describedby.

Just looking around for some references here.

• spellcheck="false"
• Mozilla response on autocapitalization
• Safari's approach

I would rather keep the usability fixes for mobile rather than validate. It sounds like the only other actionable fix would be to remove the "described-by" attribute if there isn't a describing element? I think the description text we have on the login page inputs are kind of redundant.

I think we should update the issue summary based on the comment in #17. If the testbot approves, then I think the Novice tag should be removed once the summary has been updated.

Add one more Novice task, once the testbot approves: show the HTML markup before and after the patch, in order to make the accessibility review easier and more public.

Working on this at mentored sprint at DrupalCon LA.

User login block before:

      <form class="user-login-form" action="/drupal/node?destination=/drupal/node" method="post" id="user-login-form" accept-charset="UTF-8">
  <div class="form-item js-form-type-textfield form-type-textfield form-item-name">
      <label for="edit-name" class="form-required">Username</label>
        <input autocorrect="off" autocapitalize="off" spellcheck="false" aria-describedby="edit-name--description" type="text" id="edit-name" name="name" value="" size="15" maxlength="60" class="form-text required" required="required" aria-required="true" />

      </div>
<div class="form-item js-form-type-password form-type-password form-item-pass">
      <label for="edit-pass" class="form-required">Password</label>
        <input aria-describedby="edit-pass--description" type="password" id="edit-pass" name="pass" size="15" maxlength="128" class="form-text required" required="required" aria-required="true" />

      </div>
<input type="hidden" name="form_build_id" value="form-TucjkBKVr9xy84ZcRPhYShokHx6LlE8_U3WSqQz33pY" />
<input type="hidden" name="form_id" value="user_login_form" />
<div class="form-actions form-wrapper" id="edit-actions"><input type="submit" id="edit-submit" name="op" value="Log in" class="button form-submit" />
</div>

</form>

User login block after patch applied:

<form class="user-login-form" action="/drupal/node?destination=/drupal/node" method="post" id="user-login-form" accept-charset="UTF-8">
  <div class="form-item js-form-type-textfield form-type-textfield form-item-name">
      <label for="edit-name" class="form-required">Username</label>
        <input autocorrect="off" autocapitalize="off" spellcheck="false" type="text" id="edit-name" name="name" value="" size="15" maxlength="60" class="form-text required" required="required" aria-required="true" />

      </div>
<div class="form-item js-form-type-password form-type-password form-item-pass">
      <label for="edit-pass" class="form-required">Password</label>
        <input type="password" id="edit-pass" name="pass" size="15" maxlength="128" class="form-text required" required="required" aria-required="true" />

      </div>
<input type="hidden" name="form_build_id" value="form-GEWllfmCRyA7LOW9i_uCHbKRetG5Fe6cK9gP37rHdtk" />
<input type="hidden" name="form_id" value="user_login_form" />
<div class="form-actions form-wrapper" id="edit-actions"><input type="submit" id="edit-submit" name="op" value="Log in" class="button form-submit" />
</div>

</form>      

Aria-described by attribute is removed.

Thanks, @heatherwoz!

This patch does work but I am concerned we are fixing a symptom and not the actual issue. If I understand this correctly the issue occurs when code unsets #description without unsetting aria-describedby after the form is created.

Could we add something to the render layer to remove the aria-describedby if there is no description attribute or does this need to be done on a form by form basis?

@crasx that does seem like it would be a better fix.

The login form is pretty unique. Are there other examples where we might want to unset the aria-describedby attribute like this patch does in $form['name'] & $form['pass']?

Would be better not to introduce a hacky solution to get around this though.

I think at think that we need to address this issue with the login form in 8.0 and move @crasx's concerns that we remove the aria-describedby in FAPI if there is no description attribute to 8.1. Maybe we can address them both in 8.1, but I don't know it well enough, and having this error on all login pages is a pretty big issue.

Bumping this up to major.

I wasn't clear. @crasx suggested that fixing it just in the login block was a problem and that we should look for a broader fix to FAPI.

I don't see a reference to RTBC in the comment by @heatherwoz in #23.

I am willing to mark this RTBC though to fix the login block. I will create a new issue to fix fapi in 8.1. EDIT: Created - #2547063: Remove the aria-describedby introduced in FAPI if there is no description

On the one hand, I agree with crasx that I'd much prefer to fix this holistically for any element missing #description, rather than force all developers who want to unset descriptions without introducing accessibility issues to know this One Weird Trick™.

However, I think the case for fixing this here is that the login block, unlike other forms where this might be happening, is much more prominent for end users. Also, the approach being taken here, where a block is the same as a full-page form but manually unsets descriptions, isn't like a widespread pattern we see lots of places. The only other potential place I can think of is Search, but the full page version doesn't have a description/described-by attribute, so we're OK there.

Typically we'd block this on tests; however, I don't know that it's worth a test for this one particular one-off issue—we're very unlikely to re-introduce this problem for the login block again. I think it's definitely worth a test if we fix this in the holistic way, though. So +1 on the follow-up issue to discuss this.

Committed and pushed to 8.0.x, with the small addition of a comment to explain why this was done:

    // When unsetting field descriptions, also unset aria-describedby attributes
    // to avoid introducing an accessibility bug.
    // @todo Do this automatically in https://www.drupal.org/node/2547063.