Problem/Motivation
We learned during the Twin Cities 2013 accessibility testing that invalid form fields are invisible to users navigating that page with a screen reader because the invalid fields are not marked up as invalid.
Proposed resolution
Added [aria-invalid=true] to invalid fields so that a screen reader user will be informed that the field contents are invalid.
This is the method recommended by CITA (Illinois Center for Information Technology and Web Accessibility). There example can be found here: http://html.cita.illinois.edu/nav/form/aria/index.php?example=3

Remaining tasks
Propose a patch.
User interface changes
Screen readers users will know when a field has not passed validation.
API changes
None.
Related Issues
#1174938: Natively support the HTML5 required and aria-required FAPI properties
Original report by jessebeach
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | aria-invalid.fail_.patch | 857 bytes | larowlan |
| #11 | aria-invalid.pass_.patch | 1.29 KB | larowlan |
| #9 | aria-invalid-2047075-9.patch | 1.88 KB | jessebeach |
| #9 | interdiff_6-to-9.txt | 1.37 KB | jessebeach |
| #6 | Test Only - aria-invalid-2047075-redo.fail_.patch | 855 bytes | rareBlackMagic |
Comments
Comment #0.0
jessebeach commentedadded 1174938
Comment #1
mgiffordI don't think this is quite right, but wouldn't it be great if it just worked!
This will probably need tests too.
Comment #3
larowlanAdding form api tag
Comment #4
rareBlackMagic commentedHello all,
Please find attached two patch files. The first is a test only and should fail, and the second file contain the fix.
Though my manual test using a screen reader and checking page source, the aria-invalid attribute is there once a testfield isn't filled.
Comment #5
larowlanSo the fix is also in the .fail file. Ideally the .fail file should only contain the tests changes and should fail testing - demonstrating that the new tests catch the missing functionality, then the 'fix + tests' patch is the .pass file - this shows that the fix works. Hope that makes sense. But not a big deal.
Both lines use tabs for adding the indent, the Drupal standard is to use spaces. See http://drupal.org/coding-standards. You can update your editor to use spaces and never think of it again. You can also configure git to warn you - see http://drupal.org/node/1542048 for the recommended git config.
Comment #6
rareBlackMagic commentedAttached are the corrected patches. Including fixes to the code that didn't comply with Drupal coding standards.
Again, like before, the first file is the test only and the second file is the fix.
(Hope I sorted it properly!)
Comment #7
larowlanClose, the fail one is fine (and no need to re-upload as it will show that the tests catch what we're trying to catch).
But the pass one should be the 'complete' patch as in the patch that will be applied - so it should contain the tests (like the fail one) and the fix.
So the file size should be around the 1.2 kb (400b + 800b).
Whitespace looks good.
So if we can get a complete patch that includes the fix and the test - we're nearly done in my opinion.
Thanks again.
Comment #8
rareBlackMagic commentedFor some reason when i created the pass patch (just tried it again) it seemed to exclude the test. Here's the results of the new pass patch.
Comment #9
jessebeach commentedCaecus, awesome patch. You dove down deep into a complex Drupal system and made an impressive change. Nice work!
I've rolled the two patches together and made a slight change: TRUE to 'true'. A string instead of a Boolean. I'd like to print the word true as the value of aria-invalid, since when it does not have a value, it's interpreted as having the value false (default).
Comment #10
jessebeach commentedI tested the patch(es) from #6 with a screen reader (VoiceOver). The change works just as expected. The screen reader indicates that the field is invalid. I was ready to RTBC the change except for it not being rolled into a single patch and the need to assign a value of 'true' to aria-invalid, instead of a Boolean TRUE. The updated patch in #9 does not change the behavior of Caecus' original patch.
I would still like to see us eventually inline the invalid message for each field, so the remediation help isn't disassociated from the field by being printing somewhere else on the page in a messages box. But we can increment these improvements. That change in this patch gets us a little closer.
Comment #11
larowlanWe still need a pass/fail to show the tests do what they're supposed to, the patches above all passed, which means the tests (in the earlier patches) are a false positive. I suspect the explicit 'true' string will rectify this, but uploading in two parts to verify and demonstrate to reviewers/committers that the latest patch tests work as expected™.
If we see red/green for these two, its rtbc in my opinion.
Comment #12
larowlanI asked an admin to cancel the test run on #9 as #11's pass patch is the same thing. No need to overload the bot.
Comment #13
larowlanThis is RTBC in my book but given I worked on the original patch with @Caecus in office hours and uploaded the last version I'll leave that to someone else.
Comment #14
jibranHere we go.
Comment #15
wim leersAwesome! Thanks, Caecus and larowlan!
Comment #16
webchickNice!
Committed and pushed to 8.x. Thanks!
Does this happen to help with #742344: Allow forms to set custom validation error messages on required fields or #1493324: Inline form errors for accessibility and UX or #1797438: HTML5 validation is preventing form submit and not fully accessible by any chance?
Comment #17
mgiffordI don't think it's going to help with those other issues.
Glad this patch is committed & also nice that it was discovered in a #a11y sprint!
Comment #18.0
(not verified) commentedadded an example image.