Re: Best practices for design and programming for invalid form inputs
Re: Best practices for design and programming for invalid form inputs
- Subject: Re: Best practices for design and programming for invalid form inputs
- From: Chris Fleizach <email@hidden>
- Date: Mon, 19 Nov 2018 08:48:54 -0800
> On Nov 19, 2018, at 8:42 AM, Drake, Ted <email@hidden> wrote:
>
> Hi
>
> I'm working with our design team to define user experience for form inputs
> that have been marked as invalid. I'm not finding much in the iOS
> documentation for defining an input is invalid and displaying the error
> message. I've found suggestions on using textFieldShouldEndEditing as the
> trigger for validating. This keeps focus in the form input instead of
> allowing the user to move forward.
>
> I found a suggestion of using an alert for displaying error messages:
> https://developer.apple.com/library/archive/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/ManageTextFieldTextViews/ManageTextFieldTextViews.html#//apple_ref/doc/uid/TP40009542-CH10-SW8
>
> The User Interface Guidelines tells us to validate immediately:
> Dynamically validate field values. It’s frustrating when you have to go back
> and correct mistakes after filling out a lengthy form. Whenever possible,
> check field values immediately after entry so users can correct them right
> away.
>
> But there are form inputs that cannot be validated immediately. How should we
> design for a form input that is marked invalid on submit?
From an accessibility standpoint, popping an alert after submission which
indicates which fields are incorrect would be helpful
After the alert dismissed, moving VO focus to that field would be good too
Finally, I think including the invalidate status in the label of the text field
is probably your best bet for communicating that status. And if there's a
longer form error message, putting that in the hint would probably be the best
place
>
> Does the developer need to set a trait to show it is invalid on submit?
We don't have a trait for this status yet
> Do we set focus back to the input?
I think that would be helpful rather than having the user move through on their
own
> Do we use a label to include the error message?
I would use the label. Setting anything in the value would mess up the text
editing
> How do you connect the error message to the input?
I would just put the error message in the hint
>
> Sorry for the long email with lots of questions. I'm hoping there's a good
> article that already covers this subject that I can use as a reference.
>
> Thank you
>
> Ted Drake | Principal Engineer, Intuit Accessibility
> Pronouns: He/Him/His
> Email: email@hidden
>
> Intuit | Powering Prosperity
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Accessibility-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden