Fields’ errors should be programmatically associated with fields.

[Thibaud Colas]

Related: #32819. This could be worth fixing at the same time, although I would expect this issue shouldn’t require as breaking of a change to fix.

Django currently displays errors above fields in its forms rendering:

<ul class="errorlist">
  <li>This field is required.</li>
</ul>
<p>
  <label for="id_duration_required">Duration required:</label>
  <input type="text" name="duration_required" required="" id="id_duration_required">
  <span class="helptext">Help</span>
</p>

One thing this is missing is a way to programmatically indicate the field is in error – currently this can only be inferred visually because the error messages are displayed above the field. This is fail of WCAG 2.1 level A ​3.3.1: Error Identification. The most common way to do this programmatically is to use aria-invalid="true" on the field, as demonstrated in the non-normative ​technique ARIA21:

  <input type="text" name="duration_required" required="" id="id_duration_required" aria-invalid="true">

Here is the result in VoiceOver on Safari – announcing "invalid data" after the field label and required state:

[Thibaud Colas]

Screenshot of the VoiceOver text-to-speech output, announcing "Email required: required invalid data edit text"

[Chandra Kiran G]

Hey, can I work on this? I'm a beginner here, any kind of help would be greatly appreciated.

Thanks,
Kiran

[Tom Carrick]

Kiran, assign yourself the ticket if you want to take it. If you need help, I would first read ​https://docs.djangoproject.com/en/3.2/internals/contributing/ and try to get the tests passing at least.

You would probably need to find where the HTML for these forms are generated. I think ​https://github.com/django/django/tree/main/django/forms/templates/django/forms/widgets might be a good place to start. Then find out the best way to tell if the field is invalid and the best place to add the attribute.

If you get stuck, you could try posting on the forum or the django-developers mailing list.

[Kapil Bansal]

If I am not wrong, we need to remove the errorlist and use aria_techniques instead?

[Demetris Stavrou]

I will give this a try since there is inactivity.

[Thibaud Colas]

Note based on recent research for PR #15036 (​https://github.com/django/django/pull/15036#issuecomment-1008738687):

• I still think this is a _Bug_ (WCAG 2.1 conformance fail) as Django stands currently, however if/when ticket #32819 is tackled, we should mark this ticket as a _New feature_, as contrary to what I thought aria-invalid="true" isn’t required for conformance when aria-describedby already points to an error message. If the error message can’t be identified as such, then the bug to fix would be to make the error messages unambiguous, which is a different issue.
• Even though I would expect fixing this to be a straightforward improvement for almost all Django implementers, it’ll change how forms are announced to screen reader users, so it would be valid to consider this as a breaking change.

[Natalia Bidart]

There is a new ​PR here

[Mariusz Felisiak <felisiak.mariusz@…>]

In 10725a3:

Fixed #32820 -- Added aria-invalid="true" to fields with errors.

Co-authored-by: Demetris Stavrou <demestav@…>
Co-authored-by: David Smith <smithdc@…>