E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Sumit Patel
Date: Sat, Apr 22 2023 12:29AM
Subject: instruction for the input fields
No previous message | Next message →

Hai all,

I was going through 3.3.2 labels or instructions,
according to g89 - https://www.w3.org/WAI/WCAG21/Techniques/general/G89
We need to provide instruction about the restriction on the format
fields. They have given Date field as an example.
So, I think it is applicable for fields like mail id, mobile number
and zip code also .
need to provide instruction like " = EMAIL ADDRESS REMOVED = ", "5-digit zip
code", "10-digit mobile number" etc.

Similarly, according to 3.3.3 error suggestion, we need to make the
error messages descriptive in a way which helps user to understand
what is the valid format.
For example, instead of saying "provide valid mail id" , "provide
valid mail id. for example: = EMAIL ADDRESS REMOVED = "

So, is it mandatory to mention the expected format of these fields in
both these scenarios? first one isbefore making the error and second
one is in the error message .

Regards,
Sumit.

From: glen walker
Date: Sat, Apr 22 2023 1:47AM
Subject: Re: instruction for the input fields
← Previous message | Next message →

3.3.2 says labels OR instructions. That is, one or the other is required.
Both is common but not necessary to pass. The first line of the
understanding doc says "The intent of this Success Criterion is to have
content authors present instructions or labels that identify the controls
in a form so that users know what input data is expected."

Having a label of "email" or "zipcode" or "phone" is common enough that
"users know what input data is expected". While you could give examples of
formats, I don't think it's necessary, at least to pass 3.3.2, although
it's often a good practice to do so.

A date field might need instructions if you're allowing the user to type in
a value. Ideally, you let them type in a date in any format they want and
you, being a smart programmer, figure it out. The locale might come into
play so that if a user types "01-04-2023", that could either be January 4th
or April 1st. But if you are forcing the user to type in the date in a
specific way, then instructions would be needed.

And for error suggestions, as the SC says, if "suggestions for correction
are known, then the suggestions are provided to the user". If you try to
parse an email address and it fails, I suppose you could be very specific
and say the "@" sign is missing or the domain name is missing, or you could
do as you suggested and say it should be in the format of = EMAIL ADDRESS REMOVED =
but I probably wouldn't fail it if it only said "provide a valid email
address".

For something like creating a password, if you have restrictions such as
number of letters or special characters, you could be specific and say "not
enough letters" or "missing an uppercase letter", etc.


On Sat, Apr 22, 2023 at 12:29 AM Sumit Patel < = EMAIL ADDRESS REMOVED = >
wrote:

> Hai all,
>
> I was going through 3.3.2 labels or instructions,
> according to g89 - https://www.w3.org/WAI/WCAG21/Techniques/general/G89
> We need to provide instruction about the restriction on the format
> fields. They have given Date field as an example.
> So, I think it is applicable for fields like mail id, mobile number
> and zip code also .
> need to provide instruction like " = EMAIL ADDRESS REMOVED = ", "5-digit zip
> code", "10-digit mobile number" etc.
>
> Similarly, according to 3.3.3 error suggestion, we need to make the
> error messages descriptive in a way which helps user to understand
> what is the valid format.
> For example, instead of saying "provide valid mail id" , "provide
> valid mail id. for example: = EMAIL ADDRESS REMOVED = "
>
> So, is it mandatory to mention the expected format of these fields in
> both these scenarios? first one isbefore making the error and second
> one is in the error message .
>
> Regards,
> Sumit.
> > > > >

From: Sumit Patel
Date: Mon, Apr 24 2023 12:08PM
Subject: Re: instruction for the input fields
← Previous message | Next message →

so, you say it is not a failure of 3.3.2 if an example format is not
given for the mail fields like mail id and zip code as the user
already knows what would be the correct format . It is just a good
practice
Same with 3.3.3

But, in case if the user has to enter the country code also along with
the 10 digit number ,
The user won't be knowing the same if an instruction is not provided



On 22/04/2023, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> 3.3.2 says labels OR instructions. That is, one or the other is required.
> Both is common but not necessary to pass. The first line of the
> understanding doc says "The intent of this Success Criterion is to have
> content authors present instructions or labels that identify the controls
> in a form so that users know what input data is expected."
>
> Having a label of "email" or "zipcode" or "phone" is common enough that
> "users know what input data is expected". While you could give examples of
> formats, I don't think it's necessary, at least to pass 3.3.2, although
> it's often a good practice to do so.
>
> A date field might need instructions if you're allowing the user to type in
> a value. Ideally, you let them type in a date in any format they want and
> you, being a smart programmer, figure it out. The locale might come into
> play so that if a user types "01-04-2023", that could either be January 4th
> or April 1st. But if you are forcing the user to type in the date in a
> specific way, then instructions would be needed.
>
> And for error suggestions, as the SC says, if "suggestions for correction
> are known, then the suggestions are provided to the user". If you try to
> parse an email address and it fails, I suppose you could be very specific
> and say the "@" sign is missing or the domain name is missing, or you could
> do as you suggested and say it should be in the format of = EMAIL ADDRESS REMOVED =
> but I probably wouldn't fail it if it only said "provide a valid email
> address".
>
> For something like creating a password, if you have restrictions such as
> number of letters or special characters, you could be specific and say "not
> enough letters" or "missing an uppercase letter", etc.
>
>
> On Sat, Apr 22, 2023 at 12:29 AM Sumit Patel < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hai all,
>>
>> I was going through 3.3.2 labels or instructions,
>> according to g89 - https://www.w3.org/WAI/WCAG21/Techniques/general/G89
>> We need to provide instruction about the restriction on the format
>> fields. They have given Date field as an example.
>> So, I think it is applicable for fields like mail id, mobile number
>> and zip code also .
>> need to provide instruction like " = EMAIL ADDRESS REMOVED = ", "5-digit zip
>> code", "10-digit mobile number" etc.
>>
>> Similarly, according to 3.3.3 error suggestion, we need to make the
>> error messages descriptive in a way which helps user to understand
>> what is the valid format.
>> For example, instead of saying "provide valid mail id" , "provide
>> valid mail id. for example: = EMAIL ADDRESS REMOVED = "
>>
>> So, is it mandatory to mention the expected format of these fields in
>> both these scenarios? first one isbefore making the error and second
>> one is in the error message .
>>
>> Regards,
>> Sumit.
>> >> >> >> >>
> > > > >

From: glen walker
Date: Mon, Apr 24 2023 12:46PM
Subject: Re: instruction for the input fields
← Previous message | No next message

I can't make a general statement without knowing your specific situation.
I gave several examples in my previous reply.

The normative text of 3.3.2 just says "Labels or instructions are provided
when content requires user input."

If your input field has a label, such as "email" or "phone", then
technically you are conforming to that success criterion.

Is that all you have to do? That depends on your definition of
"accessibility". If you only want to adhere to the minimum baseline of
WCAG, then yes. If you want to consider the user experience, then you might
need "instructions" as well, but it's not necessarily required.

The non-normative "understanding" document for 3.3.2 gives more details
that the purpose of this SC is so that users will understand the format of
the input, but since that document is non-normative, not adhering to it
doesn't mean you fail 3.3.2.

Personally, I don't think email fields need instructions.

If you have a US-based site, then a zipcode probably doesn't need
instructions either, unless it's a zip+4 code, in which case the label
should probably indicate that, or there should be two input fields, one for
the zipcode and one for the +4. But other countries have different
"zipcode" type fields: postcode, postal index number, Postleitzahl, etc. In
the US, a zipcode is a common field and doesn't require instructions. I'm
guessing the same is true for other countries.

A phone could be tricky. Is it only US based? US users will know what a US
phone number looks like. But if any country code can be specified, then
instructions might be needed.

Also mentioned previously, you should let the user type whatever they want
and you should figure it out. For US based number, if I type
"123-456-7890" or "123.456.7890" or "1234567890" or "(123) 456-7890", all
should be allowed. If you want to put the burden on the user to type a
format exactly in a way to make your programming job easier, you can
certainly do that. Technically, you might not need to tell the user what
format the phone number should be in but if they use the wrong format, your
error message would need to tell them the correct format (3.3.3). I think
that's a poor UX but passes WCAG.


On Mon, Apr 24, 2023 at 12:08 PM Sumit Patel < = EMAIL ADDRESS REMOVED = >
wrote:

> so, you say it is not a failure of 3.3.2 if an example format is not
> given for the mail fields like mail id and zip code as the user
> already knows what would be the correct format . It is just a good
> practice
> Same with 3.3.3
>
> But, in case if the user has to enter the country code also along with
> the 10 digit number ,
> The user won't be knowing the same if an instruction is not provided
>
>
>