E-mail List Archives
Thread: html 5 required
Number of posts in this thread: 3 (In chronological order)
From: John Hicks
Date: Tue, Feb 20 2018 4:08AM
Subject: html 5 required
No previous message | Next message →
... ah ! apologies . I just have found this thread.
Still, I am wondering if there is a clean solution.
"Invalid Entry" ... vocally, is the equivalent of a red box around the
field upon focus. Such is not the case for visual users so there is an
equivalence problem here.
best,
John
2017-11-08 16:55 GMT+01:00 Tomlins Diane < = EMAIL ADDRESS REMOVED = >:
> Thanks everyone for your input, very helpful. Since it's apparent NVDA
> users are accustomed to it and it's a Firefox bug, then we'll move forward
> with the "required" value. I did run across a form on another site that did
> exactly the same thing!
>
> Diane R Tomlins
> HCA IT&S | Digital Media
> Accessibility SME
>
>
>
From: Sailesh Panchang
Date: Tue, Feb 20 2018 7:10AM
Subject: Re: html 5 required
← Previous message | Next message →
I believe these are browser induced WCAG 2.0 failures of SC 3.3.1 and 2.2.1
When a form control with HTML5 "required" is submitted without any
input, the focus is placed in the failed field and an alert is
presented:
"Alert: Please fill out this field".
In Firefox, attempting to identify the field or read the message
again causes it to disappear.
The error message is read just once by the screen reader in Firefox
and not at all in Chrome. In Chrome it disappears after a few seconds.
This message fails WCAG 2.0 SC 3.3.1 because the error text does
notidentify the field.
This applies to other input types where input format does not match
what's expected too.
2. Next, as one tabs off or navigates off the field, the error text
disappears. So if one decides to review all errors before addressing
them, there is no error text present on the screen. This fails WCAG
2.0's 2.2.1.
Also WCAG 2.0 says:
"Guideline 2.2 Enough Time: Provide users enough time to read and use content".
(Similar behavior is noted for other input types where input format
does not match what's expected).
This is labelled as an alert by the browser so it should behave like one.
ARIA specs say:
"Since alerts are not required to receive focus, content authors
SHOULD NOT require users to close an alert".
Using aria--required / custom error messages negates the purpose of
the HTML5 required attribute. Browser makers need to fix the issue.
Thanks,
On 2/20/18, John Hicks < = EMAIL ADDRESS REMOVED = > wrote:
> ... ah ! apologies . I just have found this thread.
>
> Still, I am wondering if there is a clean solution.
>
> "Invalid Entry" ... vocally, is the equivalent of a red box around the
> field upon focus. Such is not the case for visual users so there is an
> equivalence problem here.
>
> best,
>
> John
>
>
> 2017-11-08 16:55 GMT+01:00 Tomlins Diane < = EMAIL ADDRESS REMOVED = >:
>
>> Thanks everyone for your input, very helpful. Since it's apparent NVDA
>> users are accustomed to it and it's a Firefox bug, then we'll move forward
>> with the "required" value. I did run across a form on another site that
>> did
>> exactly the same thing!
>>
>> Diane R Tomlins
>> HCA IT&S | Digital Media
>> Accessibility SME
>>
>>
>>
From: Birkir R. Gunnarsson
Date: Tue, Feb 20 2018 7:19AM
Subject: Re: html 5 required
← Previous message | No next message
I agree with Sailesh that the browser vendors are not exposing HTmL
validation attribute induced errors accessibly. This is a pity,
because these attributes are powerful and have the potential to make
form validation infinitely easier.
I have created a couple of HTML examples where I dig into the browser
validation to pick up the warnings and error messages and then expose
them in a more accessible manner.
While not ideal, it is a lot faster and easier than writing custom
Javascript to validate the form.
I need to put it on my to do list to put these examples out on Code Pen.
You have access to the validation constructs and you can create pseudo
classes for required and other HTmL5 attribute to make the errors more
visually noticeable.
This doesn't change the fact that we shouldn't have to do all that,
the default browser notifications should at least meet the
accessibility baseline.
On 2/20/18, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I believe these are browser induced WCAG 2.0 failures of SC 3.3.1 and 2.2.1
>
> When a form control with HTML5 "required" is submitted without any
> input, the focus is placed in the failed field and an alert is
> presented:
> "Alert: Please fill out this field".
> In Firefox, attempting to identify the field or read the message
> again causes it to disappear.
> The error message is read just once by the screen reader in Firefox
> and not at all in Chrome. In Chrome it disappears after a few seconds.
>
> This message fails WCAG 2.0 SC 3.3.1 because the error text does
> notidentify the field.
> This applies to other input types where input format does not match
> what's expected too.
>
> 2. Next, as one tabs off or navigates off the field, the error text
> disappears. So if one decides to review all errors before addressing
> them, there is no error text present on the screen. This fails WCAG
> 2.0's 2.2.1.
> Also WCAG 2.0 says:
> "Guideline 2.2 Enough Time: Provide users enough time to read and use
> content".
>
> (Similar behavior is noted for other input types where input format
> does not match what's expected).
> This is labelled as an alert by the browser so it should behave like one.
> ARIA specs say:
> "Since alerts are not required to receive focus, content authors
> SHOULD NOT require users to close an alert".
>
> Using aria--required / custom error messages negates the purpose of
> the HTML5 required attribute. Browser makers need to fix the issue.
> Thanks,
>
>
> On 2/20/18, John Hicks < = EMAIL ADDRESS REMOVED = > wrote:
>> ... ah ! apologies . I just have found this thread.
>>
>> Still, I am wondering if there is a clean solution.
>>
>> "Invalid Entry" ... vocally, is the equivalent of a red box around the
>> field upon focus. Such is not the case for visual users so there is an
>> equivalence problem here.
>>
>> best,
>>
>> John
>>
>>
>> 2017-11-08 16:55 GMT+01:00 Tomlins Diane
>> < = EMAIL ADDRESS REMOVED = >:
>>
>>> Thanks everyone for your input, very helpful. Since it's apparent NVDA
>>> users are accustomed to it and it's a Firefox bug, then we'll move
>>> forward
>>> with the "required" value. I did run across a form on another site that
>>> did
>>> exactly the same thing!
>>>
>>> Diane R Tomlins
>>> HCA IT&S | Digital Media
>>> Accessibility SME
>>>
>>>
>>>