Abide accessibility

[Owlbertz]

Improved Abide accessibility, based on issue #10552.
As this PR will not create a full WCAG compliance, it is at least a step towards it.

Maybe @udf2457 could give some feedback.

[udf2457]

@Owlbertz Normally I'd love to, but I'm drowning in work at the moment, so it might be 2–3 weeks (at least) before I can get round to looking properly at it. So for the moment the best I can do is thank you for your hard work. ;-)

[atainton]

@udf2457 any update, would be great for a disabled user to know when there are validation errors

[Owlbertz]

@atainton Don't hesitate to check this out and give feedback on your own .

[udf2457]

@atainton et al.

I'm afraid I'm currently a bit backlogged at work - more backlogged than I was in October, which apparently is somehow humanly possible ! So realistically I'm not going to be able to do much testing of the above commit until much before the end of the year.

Sorry to disappoint, but such is life !

[ncoden]

I'll check this. I want to learn about accessibility and this is a good opportunity for that ;)

[Owlbertz]

@ncoden glad to hear that.
I don't want to advert for myself too much, but if you want to get started with accessibility maybe my collection of related ressources might be helpful.

[ncoden]

@Owlbertz I added some aria attributes to the docs and tested it. It works well ;). I am particulary impressed by the aria-live="assertive" to "pop" an error message to the user.

The next step is to add these attributes when we can. I'm thinking to aria-live for all [data-abide-error], and aria-describedby for all .form-error and [data-form-error-for].

What do you think ?

[ncoden]

@Owlbertz

• Set [aria-live] attribute on [data-abide-error], according to the a11yErrorLevel option.
• Set [aria-describedby] attribute on field, targetting the first form error.
• Set [for] attribute on form errors labels, targetting their field.
• a11yAttributes option to disable all this. For now, it does not disable aria-invalid.
• Full documentation. Good enough like that
• Do not add "[aria-describedby]" on fields by form errors on init Actually, the W3C examples set [aria-describedby] from the begining. And Chromevox do not spell an hidden error field.
  --
• Visual tests.
• Unit tests.
  --
• Set [role=alert] attribute on form errors

[ncoden]

Poke @Owlbertz. Would you have some time to review this ? :)

[ahukkanen]

I don't know if @ncoden is still around but I would be interested in why you decided to add the aria-describedby to point to the error field if the aria-describedby attribute is not defined for the field.

This causes the screen reader to announce the error element event before the user has done anything wrong. I created a quick sample here what happens (try it out with a screen reader):
https://jsfiddle.net/f3g2rx1j/show

The screen reader is announcing here the following:

• "Text Required" field
• Editable
• Required
• Yo, you had better fill this out, it's required.
• (On some screenreaders it reads also the placeholder after the aria-describedby element)

We received feedback from accessibility auditors that this can be confusing for users using the assistive technologies. The user would not expect the error text to describe the contents of the input field. Instead, the screen reader should announce the error only when it becomes visible on the page, i.e. when the user leaves the field without entering anything to it (or when they return back to the field after first leaving it empty).

If there is a valid reason why you added the aria-describedby attribute to point to the first error message, we would be interested to hear the reasoning to better understand this and also to justify its use for the accessibility experts.

The described current behavior would be completely fine in case it happened when the error was already visible on the page, i.e. when the user returns back to the field after they first left it empty. But now that they hear the error description when it is still invisible on the screen, it creates confusion.

Could you share some insight on this?

---

Here's the example code if it disappears for some reason from JSFiddle:

<!DOCTYPE html>
<html>
<head>
<title>Foundation test</title>
<!-- Compressed CSS -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/foundation-sites@6.7.4/dist/css/foundation.min.css" crossorigin="anonymous">

<!-- Compressed JavaScript -->
<script src="https://code.jquery.com/jquery-3.6.0.min.js" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/foundation-sites@6.7.4/dist/js/foundation.min.js" crossorigin="anonymous"></script>
</head>
<body>
  <form data-abide novalidate data-abide="true" data-validate-on-blur="true" data-live-validate="true">
    <label>
      Text Required
      <input type="text" placeholder="Go to this field with a screenreader (don't type anything)" required>
      <span class="form-error">
        Yo, you had better fill this out, it's required.
      </span>
    </label>
  </form>

<script>
$(document).ready(() => {
  $("body").foundation();
});
</script>
</body>
</html>