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
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Steve Faulkner
> Sent: Monday, November 06, 2017 6:48 PM
> To: Beranek, Nicholas < = EMAIL ADDRESS REMOVED = >; WebAIM
> Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [EXTERNAL] Re: [WebAIM] html 5 required
>
> >
> > Now we find in testing, using NVDA 2017.3 with Firefox, NVDA announces
> > empty fields as "invalid entry" the first time the user focuses on
> > them, even before the error checking that takes place when a user hits
> > the Submit button.
>
>
> This is not due to any screen reader, it is due to the required attribute
> being exposed as required and invalid in browser accessibility APIs. The
> reasoning behind this is that until a required control has received some
> user input, it does not meet its validation constraints and is therefore in
> an invalid state.
>
> discussion of this is in a related Firefox bug
> https://bugzilla.mozilla.org/show_bug.cgi?idf6544
>
>
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 6 November 2017 at 23:47, Beranek, Nicholas via WebAIM-Forum <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi Diane, I recommend keeping the required attribute. For
> > compatibility, I would add the value "required", as well. You're
> > encountering expected behavior with NVDA and Firefox because, by
> > definition, since a value is required, lack of a value, or null value,
> > would be invalid. I am always hesitant to include a hack to appease a
> > browser/AT, and the use of the required attribute is a sufficient
> technique.
> >
> > Nick Beranek
> > Capital One
> >
> > On Nov 6, 2017, at 5:17 PM, Tomlins Diane <Diane.Tomlins@HCAhealthcare.
> > com<mailto: = EMAIL ADDRESS REMOVED = >> wrote:
> >
> >
> > This just came up for us, and we just switched 70+ code files to use
> > the html 5 "required' attribute. Now we find in testing, using NVDA
> > 2017.3 with Firefox, NVDA announces empty fields as "invalid entry"
> > the first time the user focuses on them, even before the error
> > checking that takes place when a user hits the Submit button. So I
> > would think this would make things confusing for AT users.
> >
> > We tried adding aria-required="true" but that didn't help since we
> > still have the "required" attribute in there too.
> >
> > If I understand the replies to this thread, the "required' attribute
> > is still a patchwork of support between browsers and AT??
> >
> > Our developers won't be thrilled to back-pedal to take out the
> > attribute they just put in :-/
> >
> > Any possible workaround besides going back?
> >
> > Thanks!
> >
> > Diane R Tomlins
> > HCA IT&S | Digital Media
> > Accessibility SME
> >
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Jonathan Avila
> > Sent: Saturday, August 05, 2017 7:04 PM
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
> > = EMAIL ADDRESS REMOVED = >>
> > Subject: [EXTERNAL] Re: [WebAIM] html 5 required
> >
> > I am confused. The label is exposed isn´t it, the way you wrote it.
> >
> > I can confirm that with NVDA after a form is submitted and focus is
> > moved to the field in error in some browsers NVDA only announces the
> > error and not the label. If you open the speech viewer you will find
> > the label is there -- which I believe indicates that the error message
> > is being treated like an assertive live region and somehow
> > interrupting the label from being announced.
> >
> > In our testing of the HTML required attribute in different browsers
> > the supports varied between browsers with screen readers. In
> > addition, some browsers use a red border to indicate the error state
> > while only providing a mouse involked tooltip further complicated the
> > use of the required attribute as it could be claimed color alone was
> > used to communicate the error visually to people with color deficiency
> > who were not using a screen reader.
> >
> > I would agree with Patrick that at this time if you need to support
> > multiple browsers and multiple AT the support is not there yet to
> > fully conform with this method alone. It's a shame because it's a
> > simple method that should be better supported without requiring
> > developers to implement more complex and costly solutions.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > Level Access, inc. (formerly SSB BART Group, inc.)
> > (703) 637-8957
> > = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> > Looking to boost your accessibility knowledge? Check out our free
> webinars!
> >
> > The information contained in this transmission may be attorney
> > privileged and/or confidential information intended for the use of the
> > individual or entity named above. If the reader of this message is not
> > the intended recipient, you are hereby notified that any use,
> > dissemination, distribution or copying of this communication is strictly
> prohibited.
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Birkir R. Gunnarsson
> > Sent: Saturday, August 5, 2017 1:19 PM
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
> > = EMAIL ADDRESS REMOVED = >>
> > Subject: Re: [WebAIM] html 5 required
> >
> > I am confused. The label is exposed isn´t it, the way you wrote it.
> > If there is a title attribute or a placeholder, maybe those don´t get
> > exposed when you add the required attribute?
> > Which browsers/a.t. combinations are you using?
> > Are you using a proper label assocaition?
> > Are you using either a title or placeholder attribute (on the input
> field)?
> > Cheers
> > -B
> >
> > On 8/3/17, Angela French < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
> > wrote:
> > Thanks for responding. I guess what confuses me is that if the cursor
> > goes to the field (with the required message) and the field is
> > labelled correctly, why isn't the label exposed again?
> >
> > Angela
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Patrick H. Lauke
> > Sent: Thursday, August 03, 2017 2:51 PM
> > To: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > Subject: Re: [WebAIM] html 5 required
> >
> > On 03/08/2017 22:45, Angela French wrote:
> > Hello,
> >
> > We are trying to use the html 5 required attribute on required form
> > fields. In testing, I am finding that each browser I test with (with
> > NVDA) handles it differently. The problem is that in most browsers I
> > hear the message that a field is required, but it doesn't tell me
> > WHICH field it is referring to even though the cursor goes to the
> > first empty field.
> > The only browser that played very nicely on this was Chrome.
> > Curiously, even Chrome didn't read the required field message ("Please
> > fill out this field."). Rather it said "Last Name invalid entry
> > required."
> >
> > Is there a way to make this behavior consistent?
> >
> > In short: don't use required attribute at this stage, but instead
> > aria-required="true" and traditional custom error messages/bubbles.
> >
> > Regarding the "Please fill out this field", I assume you're referring
> > to the default browser error tooltip bubble? If so, last time I
> > checked (2 years ago), none of the browsers exposed the text they
> > visually present
> > -
> > http://developer.telerik.com/featured/building-html5-form-validation-b
> > ubble-replacements/#comment-2381878676
> >
> > So once again, better to use old custom-made bubbles to show error
> > messages (and then tie them to the relevant form field with
> > aria-describedby or similar).
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > www.splintered.co.uk<;http://www.splintered.co.uk>; |
> > https://github.com/ patrickhlauke http://flickr.com/photos/redux/ |
> > http://redux.deviantart.com
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > > > archives at http://webaim.org/discussion/archives
> > > > = EMAIL ADDRESS REMOVED = >
> > > > > > archives at http://webaim.org/discussion/archives
> > > > = EMAIL ADDRESS REMOVED = >
> >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > archives at http://webaim.org/discussion/archives
> > > > = EMAIL ADDRESS REMOVED = > > > _________________ > > http://list.webaim.org/ List archives at
> > http://webaim.org/discussion/archives
> > > > = EMAIL ADDRESS REMOVED = >
> > > > > > archives at http://webaim.org/discussion/archives
> > > > = EMAIL ADDRESS REMOVED = >
> > > >
> > The information contained in this e-mail is confidential and/or
> > proprietary to Capital One and/or its affiliates and may only be used
> > solely in performance of work or services for Capital One. The
> > information transmitted herewith is intended only for use by the
> > individual or entity to which it is addressed. If the reader of this
> > message is not the intended recipient, you are hereby notified that
> > any review, retransmission, dissemination, distribution, copying or
> > other use of, or taking of any action in reliance upon this
> > information is strictly prohibited. If you have received this
> > communication in error, please contact the sender and delete the
> material from your computer.
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > at http://webaim.org/discussion/archives
> > > > > >
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
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Steve Faulkner
>> Sent: Monday, November 06, 2017 6:48 PM
>> To: Beranek, Nicholas < = EMAIL ADDRESS REMOVED = >; WebAIM
>> Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: [EXTERNAL] Re: [WebAIM] html 5 required
>>
>> >
>> > Now we find in testing, using NVDA 2017.3 with Firefox, NVDA announces
>> > empty fields as "invalid entry" the first time the user focuses on
>> > them, even before the error checking that takes place when a user hits
>> > the Submit button.
>>
>>
>> This is not due to any screen reader, it is due to the required attribute
>> being exposed as required and invalid in browser accessibility APIs. The
>> reasoning behind this is that until a required control has received some
>> user input, it does not meet its validation constraints and is therefore
>> in
>> an invalid state.
>>
>> discussion of this is in a related Firefox bug
>> https://bugzilla.mozilla.org/show_bug.cgi?idf6544
>>
>>
>>
>> --
>>
>> Regards
>>
>> SteveF
>> Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>
>> On 6 November 2017 at 23:47, Beranek, Nicholas via WebAIM-Forum <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Hi Diane, I recommend keeping the required attribute. For
>> > compatibility, I would add the value "required", as well. You're
>> > encountering expected behavior with NVDA and Firefox because, by
>> > definition, since a value is required, lack of a value, or null value,
>> > would be invalid. I am always hesitant to include a hack to appease a
>> > browser/AT, and the use of the required attribute is a sufficient
>> technique.
>> >
>> > Nick Beranek
>> > Capital One
>> >
>> > On Nov 6, 2017, at 5:17 PM, Tomlins Diane <Diane.Tomlins@HCAhealthcare.
>> > com<mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>> >
>> >
>> > This just came up for us, and we just switched 70+ code files to use
>> > the html 5 "required' attribute. Now we find in testing, using NVDA
>> > 2017.3 with Firefox, NVDA announces empty fields as "invalid entry"
>> > the first time the user focuses on them, even before the error
>> > checking that takes place when a user hits the Submit button. So I
>> > would think this would make things confusing for AT users.
>> >
>> > We tried adding aria-required="true" but that didn't help since we
>> > still have the "required" attribute in there too.
>> >
>> > If I understand the replies to this thread, the "required' attribute
>> > is still a patchwork of support between browsers and AT??
>> >
>> > Our developers won't be thrilled to back-pedal to take out the
>> > attribute they just put in :-/
>> >
>> > Any possible workaround besides going back?
>> >
>> > Thanks!
>> >
>> > Diane R Tomlins
>> > HCA IT&S | Digital Media
>> > Accessibility SME
>> >
>> >
>> > -----Original Message-----
>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> > Behalf Of Jonathan Avila
>> > Sent: Saturday, August 05, 2017 7:04 PM
>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
>> > = EMAIL ADDRESS REMOVED = >>
>> > Subject: [EXTERNAL] Re: [WebAIM] html 5 required
>> >
>> > I am confused. The label is exposed isn´t it, the way you wrote it.
>> >
>> > I can confirm that with NVDA after a form is submitted and focus is
>> > moved to the field in error in some browsers NVDA only announces the
>> > error and not the label. If you open the speech viewer you will find
>> > the label is there -- which I believe indicates that the error message
>> > is being treated like an assertive live region and somehow
>> > interrupting the label from being announced.
>> >
>> > In our testing of the HTML required attribute in different browsers
>> > the supports varied between browsers with screen readers. In
>> > addition, some browsers use a red border to indicate the error state
>> > while only providing a mouse involked tooltip further complicated the
>> > use of the required attribute as it could be claimed color alone was
>> > used to communicate the error visually to people with color deficiency
>> > who were not using a screen reader.
>> >
>> > I would agree with Patrick that at this time if you need to support
>> > multiple browsers and multiple AT the support is not there yet to
>> > fully conform with this method alone. It's a shame because it's a
>> > simple method that should be better supported without requiring
>> > developers to implement more complex and costly solutions.
>> >
>> > Jonathan
>> >
>> > Jonathan Avila
>> > Chief Accessibility Officer
>> > Level Access, inc. (formerly SSB BART Group, inc.)
>> > (703) 637-8957
>> > = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
>> > Looking to boost your accessibility knowledge? Check out our free
>> webinars!
>> >
>> > The information contained in this transmission may be attorney
>> > privileged and/or confidential information intended for the use of the
>> > individual or entity named above. If the reader of this message is not
>> > the intended recipient, you are hereby notified that any use,
>> > dissemination, distribution or copying of this communication is strictly
>> prohibited.
>> >
>> > -----Original Message-----
>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> > Behalf Of Birkir R. Gunnarsson
>> > Sent: Saturday, August 5, 2017 1:19 PM
>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
>> > = EMAIL ADDRESS REMOVED = >>
>> > Subject: Re: [WebAIM] html 5 required
>> >
>> > I am confused. The label is exposed isn´t it, the way you wrote it.
>> > If there is a title attribute or a placeholder, maybe those don´t get
>> > exposed when you add the required attribute?
>> > Which browsers/a.t. combinations are you using?
>> > Are you using a proper label assocaition?
>> > Are you using either a title or placeholder attribute (on the input
>> field)?
>> > Cheers
>> > -B
>> >
>> > On 8/3/17, Angela French < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
>> > wrote:
>> > Thanks for responding. I guess what confuses me is that if the cursor
>> > goes to the field (with the required message) and the field is
>> > labelled correctly, why isn't the label exposed again?
>> >
>> > Angela
>> >
>> > -----Original Message-----
>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> > Behalf Of Patrick H. Lauke
>> > Sent: Thursday, August 03, 2017 2:51 PM
>> > To: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>> > Subject: Re: [WebAIM] html 5 required
>> >
>> > On 03/08/2017 22:45, Angela French wrote:
>> > Hello,
>> >
>> > We are trying to use the html 5 required attribute on required form
>> > fields. In testing, I am finding that each browser I test with (with
>> > NVDA) handles it differently. The problem is that in most browsers I
>> > hear the message that a field is required, but it doesn't tell me
>> > WHICH field it is referring to even though the cursor goes to the
>> > first empty field.
>> > The only browser that played very nicely on this was Chrome.
>> > Curiously, even Chrome didn't read the required field message ("Please
>> > fill out this field."). Rather it said "Last Name invalid entry
>> > required."
>> >
>> > Is there a way to make this behavior consistent?
>> >
>> > In short: don't use required attribute at this stage, but instead
>> > aria-required="true" and traditional custom error messages/bubbles.
>> >
>> > Regarding the "Please fill out this field", I assume you're referring
>> > to the default browser error tooltip bubble? If so, last time I
>> > checked (2 years ago), none of the browsers exposed the text they
>> > visually present
>> > -
>> > http://developer.telerik.com/featured/building-html5-form-validation-b
>> > ubble-replacements/#comment-2381878676
>> >
>> > So once again, better to use old custom-made bubbles to show error
>> > messages (and then tie them to the relevant form field with
>> > aria-describedby or similar).
>> >
>> > P
>> > --
>> > Patrick H. Lauke
>> >
>> > www.splintered.co.uk<;http://www.splintered.co.uk>; |
>> > https://github.com/ patrickhlauke http://flickr.com/photos/redux/ |
>> > http://redux.deviantart.com
>> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> > = EMAIL ADDRESS REMOVED = >
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> > = EMAIL ADDRESS REMOVED = >
>> >
>> >
>> >
>> > --
>> > Work hard. Have fun. Make history.
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> > = EMAIL ADDRESS REMOVED = > >> > _________________ >> > http://list.webaim.org/ List archives at
>> > http://webaim.org/discussion/archives
>> > >> > = EMAIL ADDRESS REMOVED = >
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> > = EMAIL ADDRESS REMOVED = >
>> > >> >
>> > The information contained in this e-mail is confidential and/or
>> > proprietary to Capital One and/or its affiliates and may only be used
>> > solely in performance of work or services for Capital One. The
>> > information transmitted herewith is intended only for use by the
>> > individual or entity to which it is addressed. If the reader of this
>> > message is not the intended recipient, you are hereby notified that
>> > any review, retransmission, dissemination, distribution, copying or
>> > other use of, or taking of any action in reliance upon this
>> > information is strictly prohibited. If you have received this
>> > communication in error, please contact the sender and delete the
>> material from your computer.
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>> >> >> at http://webaim.org/discussion/archives
>> >> >> >> >> >>
> > > > >
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765
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
>>>
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> Behalf Of Steve Faulkner
>>> Sent: Monday, November 06, 2017 6:48 PM
>>> To: Beranek, Nicholas < = EMAIL ADDRESS REMOVED = >; WebAIM
>>> Discussion List < = EMAIL ADDRESS REMOVED = >
>>> Subject: [EXTERNAL] Re: [WebAIM] html 5 required
>>>
>>> >
>>> > Now we find in testing, using NVDA 2017.3 with Firefox, NVDA announces
>>> > empty fields as "invalid entry" the first time the user focuses on
>>> > them, even before the error checking that takes place when a user hits
>>> > the Submit button.
>>>
>>>
>>> This is not due to any screen reader, it is due to the required attribute
>>> being exposed as required and invalid in browser accessibility APIs. The
>>> reasoning behind this is that until a required control has received some
>>> user input, it does not meet its validation constraints and is therefore
>>> in
>>> an invalid state.
>>>
>>> discussion of this is in a related Firefox bug
>>> https://bugzilla.mozilla.org/show_bug.cgi?idf6544
>>>
>>>
>>>
>>> --
>>>
>>> Regards
>>>
>>> SteveF
>>> Current Standards Work @W3C
>>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>>
>>> On 6 November 2017 at 23:47, Beranek, Nicholas via WebAIM-Forum <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > Hi Diane, I recommend keeping the required attribute. For
>>> > compatibility, I would add the value "required", as well. You're
>>> > encountering expected behavior with NVDA and Firefox because, by
>>> > definition, since a value is required, lack of a value, or null value,
>>> > would be invalid. I am always hesitant to include a hack to appease a
>>> > browser/AT, and the use of the required attribute is a sufficient
>>> technique.
>>> >
>>> > Nick Beranek
>>> > Capital One
>>> >
>>> > On Nov 6, 2017, at 5:17 PM, Tomlins Diane <Diane.Tomlins@HCAhealthcare.
>>> > com<mailto: = EMAIL ADDRESS REMOVED = >> wrote:
>>> >
>>> >
>>> > This just came up for us, and we just switched 70+ code files to use
>>> > the html 5 "required' attribute. Now we find in testing, using NVDA
>>> > 2017.3 with Firefox, NVDA announces empty fields as "invalid entry"
>>> > the first time the user focuses on them, even before the error
>>> > checking that takes place when a user hits the Submit button. So I
>>> > would think this would make things confusing for AT users.
>>> >
>>> > We tried adding aria-required="true" but that didn't help since we
>>> > still have the "required" attribute in there too.
>>> >
>>> > If I understand the replies to this thread, the "required' attribute
>>> > is still a patchwork of support between browsers and AT??
>>> >
>>> > Our developers won't be thrilled to back-pedal to take out the
>>> > attribute they just put in :-/
>>> >
>>> > Any possible workaround besides going back?
>>> >
>>> > Thanks!
>>> >
>>> > Diane R Tomlins
>>> > HCA IT&S | Digital Media
>>> > Accessibility SME
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> > Behalf Of Jonathan Avila
>>> > Sent: Saturday, August 05, 2017 7:04 PM
>>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
>>> > = EMAIL ADDRESS REMOVED = >>
>>> > Subject: [EXTERNAL] Re: [WebAIM] html 5 required
>>> >
>>> > I am confused. The label is exposed isn´t it, the way you wrote it.
>>> >
>>> > I can confirm that with NVDA after a form is submitted and focus is
>>> > moved to the field in error in some browsers NVDA only announces the
>>> > error and not the label. If you open the speech viewer you will find
>>> > the label is there -- which I believe indicates that the error message
>>> > is being treated like an assertive live region and somehow
>>> > interrupting the label from being announced.
>>> >
>>> > In our testing of the HTML required attribute in different browsers
>>> > the supports varied between browsers with screen readers. In
>>> > addition, some browsers use a red border to indicate the error state
>>> > while only providing a mouse involked tooltip further complicated the
>>> > use of the required attribute as it could be claimed color alone was
>>> > used to communicate the error visually to people with color deficiency
>>> > who were not using a screen reader.
>>> >
>>> > I would agree with Patrick that at this time if you need to support
>>> > multiple browsers and multiple AT the support is not there yet to
>>> > fully conform with this method alone. It's a shame because it's a
>>> > simple method that should be better supported without requiring
>>> > developers to implement more complex and costly solutions.
>>> >
>>> > Jonathan
>>> >
>>> > Jonathan Avila
>>> > Chief Accessibility Officer
>>> > Level Access, inc. (formerly SSB BART Group, inc.)
>>> > (703) 637-8957
>>> > = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>>> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
>>> > Looking to boost your accessibility knowledge? Check out our free
>>> webinars!
>>> >
>>> > The information contained in this transmission may be attorney
>>> > privileged and/or confidential information intended for the use of the
>>> > individual or entity named above. If the reader of this message is not
>>> > the intended recipient, you are hereby notified that any use,
>>> > dissemination, distribution or copying of this communication is
>>> > strictly
>>> prohibited.
>>> >
>>> > -----Original Message-----
>>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> > Behalf Of Birkir R. Gunnarsson
>>> > Sent: Saturday, August 5, 2017 1:19 PM
>>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto:
>>> > = EMAIL ADDRESS REMOVED = >>
>>> > Subject: Re: [WebAIM] html 5 required
>>> >
>>> > I am confused. The label is exposed isn´t it, the way you wrote it.
>>> > If there is a title attribute or a placeholder, maybe those don´t get
>>> > exposed when you add the required attribute?
>>> > Which browsers/a.t. combinations are you using?
>>> > Are you using a proper label assocaition?
>>> > Are you using either a title or placeholder attribute (on the input
>>> field)?
>>> > Cheers
>>> > -B
>>> >
>>> > On 8/3/17, Angela French < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
>>> > wrote:
>>> > Thanks for responding. I guess what confuses me is that if the cursor
>>> > goes to the field (with the required message) and the field is
>>> > labelled correctly, why isn't the label exposed again?
>>> >
>>> > Angela
>>> >
>>> > -----Original Message-----
>>> > From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> > Behalf Of Patrick H. Lauke
>>> > Sent: Thursday, August 03, 2017 2:51 PM
>>> > To: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>>> > Subject: Re: [WebAIM] html 5 required
>>> >
>>> > On 03/08/2017 22:45, Angela French wrote:
>>> > Hello,
>>> >
>>> > We are trying to use the html 5 required attribute on required form
>>> > fields. In testing, I am finding that each browser I test with (with
>>> > NVDA) handles it differently. The problem is that in most browsers I
>>> > hear the message that a field is required, but it doesn't tell me
>>> > WHICH field it is referring to even though the cursor goes to the
>>> > first empty field.
>>> > The only browser that played very nicely on this was Chrome.
>>> > Curiously, even Chrome didn't read the required field message ("Please
>>> > fill out this field."). Rather it said "Last Name invalid entry
>>> > required."
>>> >
>>> > Is there a way to make this behavior consistent?
>>> >
>>> > In short: don't use required attribute at this stage, but instead
>>> > aria-required="true" and traditional custom error messages/bubbles.
>>> >
>>> > Regarding the "Please fill out this field", I assume you're referring
>>> > to the default browser error tooltip bubble? If so, last time I
>>> > checked (2 years ago), none of the browsers exposed the text they
>>> > visually present
>>> > -
>>> > http://developer.telerik.com/featured/building-html5-form-validation-b
>>> > ubble-replacements/#comment-2381878676
>>> >
>>> > So once again, better to use old custom-made bubbles to show error
>>> > messages (and then tie them to the relevant form field with
>>> > aria-describedby or similar).
>>> >
>>> > P
>>> > --
>>> > Patrick H. Lauke
>>> >
>>> > www.splintered.co.uk<;http://www.splintered.co.uk>; |
>>> > https://github.com/ patrickhlauke http://flickr.com/photos/redux/ |
>>> > http://redux.deviantart.com
>>> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> > = EMAIL ADDRESS REMOVED = >
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> > = EMAIL ADDRESS REMOVED = >
>>> >
>>> >
>>> >
>>> > --
>>> > Work hard. Have fun. Make history.
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> > = EMAIL ADDRESS REMOVED = > >>> > _________________ >>> > http://list.webaim.org/ List archives at
>>> > http://webaim.org/discussion/archives
>>> > >>> > = EMAIL ADDRESS REMOVED = >
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> > = EMAIL ADDRESS REMOVED = >
>>> > >>> >
>>> > The information contained in this e-mail is confidential and/or
>>> > proprietary to Capital One and/or its affiliates and may only be used
>>> > solely in performance of work or services for Capital One. The
>>> > information transmitted herewith is intended only for use by the
>>> > individual or entity to which it is addressed. If the reader of this
>>> > message is not the intended recipient, you are hereby notified that
>>> > any review, retransmission, dissemination, distribution, copying or
>>> > other use of, or taking of any action in reliance upon this
>>> > information is strictly prohibited. If you have received this
>>> > communication in error, please contact the sender and delete the
>>> material from your computer.
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> >
>>> >>> >>> at http://webaim.org/discussion/archives
>>> >>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> Phone 703-225-0380 ext 105
> Mobile: 571-344-1765
> > > > >
--
Work hard. Have fun. Make history.