E-mail List Archives
Re: html 5 required
From: Birkir R. Gunnarsson
Date: Feb 20, 2018 7:19AM
- Next message: Alan Zaitchik: "Table regularity versus empty table cell"
- Previous message: Sailesh Panchang: "Re: html 5 required"
- Next message in Thread: None
- Previous message in Thread: Sailesh Panchang: "Re: html 5 required"
- View all messages in this Thread
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 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 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 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
>>>
>>>
>>>
- Next message: Alan Zaitchik: "Table regularity versus empty table cell"
- Previous message: Sailesh Panchang: "Re: html 5 required"
- Next message in Thread: None
- Previous message in Thread: Sailesh Panchang: "Re: html 5 required"
- View all messages in this Thread