Problem/Motivation
So as part of my job, I help maintain a website that has several forms. We are seeing a few WCAG violations via Level Access (our accessibility management platform) mainly related to form focus on server side validation.
Steps to reproduce
We are seeing 2 issues here:
1. [The HTML5 validation piece of this should be fixed now that #1797438: HTML5 validation is preventing form submit and not fully accessible has landed] We have our main contact us form, with a few required fields. Now the browsers HTML5 validation prevents this form from being submitted if a field is not filled out (the focus goes up to the first field that is not filled out, and the screen reader reads the error message correctly). However, one of these fields is a phone number field, and we have server side validation for checking if that number is valid or not. If an invalid phone number is entered, you don't see the error until the page refreshes. Level access is saying that focus should be placed on that phone number field, and it currently does not. The screen reader seems to have issues here as it does not read the error message either. This could be just an issue with the screen reader...however I would expect the focus to be on the phone number field here. Now a user using a keyboard to navigate the site needs to tab several times to get into the form.
2. We have another form on our site that opens up in a modal. This is an ajax form, and we are running into the same issues. This form has an e-mail address field, however we have server side validation for this (we have a blacklisted domain list we compare against). Again, if a user inputs an invalid e-mail, the focus does not get sent to the e-mail field. The focus remains on the submit button. I believe this is standard for an ajax form...however it seems that the focus should still jump to the first field with an error? Also, the screen reader does not know what to read if this occurs.
I know Drupal 8 is supposed to be 100% WCAG 2.0 compliant...however based on what we have heard from Level Access, it appears these are the WCAG 2.0 rules that we are breaking:
Violation 1: Provide a clear indication of fields in error for information that is submitted
3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
Violation 2: Inform assistive technologies of changes in content
When content is inserted, made visible, or made invisible on a page via scripting after the page loads, users of assistive technologies such as screen readers may not be aware that a change in the page occurred. Developers must use certain methods to alert assistive technologies that content has changed through JavaScript. When these methods are not used, users of assistive technology such as screen readers may have an outdated/stale view of page content.
2.4.3 Focus Order:
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)
I've looked into a few other drupal.org issues related to form validation, but it seems they have gone in a different direction. I figured I would open up a new issue here. Just curious if these issues are truly accessibility violations?
Comments
Comment #2
cilefen commentedI am updating tags per policy and reminding you the Drupal 8 is end-of-life in about three weeks.
Comment #3
cilefen commentedI found #3088245: Convey form error messages to assistive technologies.
Comment #9
skaughtlinking: https://www.drupal.org/project/disable_html5_validation (until core does)
Comment #11
kentr commentedThe HTML5 and general WCAG 3.3.1 issues for non-AJAX forms should be fixed now that #1797438: HTML5 validation is preventing form submit and not fully accessible has landed.
I haven't tested on an AJAX form.
Tagging for accessibility review for input on focusing the first invalid field.
Note that the core Inline Form Errors module includes links to the invalid form fields in the page-top error message (as suggested by Technique G139: Creating a mechanism that allows users to jump to errors).
Regarding SC 2.4.3 Focus Order (Level A) mentioned in the issue summary
I question whether SC 2.4.3 Focus Order (Level A) applies here. Is the user able to tab through the interactive page elements in a logical way?
From the page linked above:
If there is a focus order issue, though, it should be handled in a different ticket.
Comment #12
kentr commentedRelated: #3083103: Programmatically associate error messages with inputs
Comment #13
kentr commented