New convention for form fields with no aria-corresponding attribute. #1000
Comments
|
Easy. We need value extension, we need to extend aria-invalid with an enum: We did the same with aria-haspopup. Then we use other techniques like aria-errormessage to give add. background info. And yes, "errormessage" is semantically not the best if type is warning or info. |
|
@stes-acc The only little hitch is that these things usually show up while the user is on the field or after they leave it. they'd have to SHIFT+TAB back to see if it was "checked", which might be OK, but worth mulling over. |
|
Using aria-errormessage for this? Where is the respective APG info? |
|
@DavidMacDonald I am not sure why you are uneasy with your original approach. It would be good to start with first principles and understand what, if anything, is the visual indicator doing for users. If it is helpful to some users, exactly why and how. Then ask the question if simulating that for AT users via ARIA provides the same value. Or, if you were going to provide the same value to AT users, would it require a completely different approach that would have to be implemented either by the author or screen reader developers. If yes, then what kind of additional ARIA markup would be needed to do that, if any. My gut is that trying to emulate this with more markup on the field has 0 value to screen reader users. My concern would be that we just add more potentially confusing noise to the experience. If the idea is scan the page and see if you missed anything, more ARIA markup is unnecessary. In fact, I would argue that current markup is sufficient for screen readers to automatically and intelligently provide this service to users whenever their reading cursor is sitting on a form submit button. Why couldn't a screen reader automatically enhance the submit button with information like 4 required fields are missing values. The screen reader could even list those fields and provide links to them in its context help. We have all the ARIA necessary for a screen reader to do that kind of thing. They just haven't thought about doing it. |
|
I think in order to progress this we need to collect examples from around the web and see if there are any cases where this would add value to users. |
I don't think this is necessarily true. If it's positioned with CSS, then the markup would resemble something like https://www.w3.org/WAI/tutorials/forms/notifications/#on-focus-change. What do you think? |
|
more use cases needed before progressing. |
I'm seeing a new convention on large corporate sites that have purchasing checkouts. The first time I saw it I shrugged it off. But then I saw it on about 3 more large sites. It seems to be an emerging standard pattern.
It's a checkmark to the right of the input field. It is a visual indication that the field has been filled out using an acceptable format. It's not saying that the content provided by the user has been validated.
For instance, you could enter a VISA # which is in a correct format and the green check will appear, but could still fail during validation of the card.
aria-invalidmight be sufficient, but its coming at the issue from the other side, notifying the user IF the format is bad, and not notifying them if it is good.I'm currently advising clients to make the green checkmark ignored by AT, and add the appropriate error message and
aria-invalidif its not Ok, but I'm a little uneasy with that. I thought about putting alt text on the image that says "acceptable format" but that seems a bit chatty and contrived.Do we need some sort of attribute or setting that gives a positive validation that the field has been filled out using an acceptable format?
The text was updated successfully, but these errors were encountered: