E-mail List Archives
Thread: Interpretation of WCAG 1.4.13
Number of posts in this thread: 3 (In chronological order)
From: Peter Quale
Date: Wed, Jul 18 2018 8:30AM
Subject: Interpretation of WCAG 1.4.13
No previous message | Next message →
Hello all,
I'm hoping to get some opinions on the breadth of WCAG 2.1 guideline
1.4.13, Content on Hover or Focus.
I'm helping with a datepicker widget that opens down from a form field when
the user focuses on the field. The datepicker will sometimes close when
blurred and sometimes not and in the past I would call this out to the
client as a UX issue that affects accessibility. This client is also keen
on addressing 2.1 issues immediately now that the standard is launched.
So my question to the group is does this behavior fit within the spirit of
guideline 1.4.13? The datepicker does obscure the field immediately
following the date field, but it is also possible to close the datepicker
by backtracking to the date field and intentionally using an enter
keypress.
My opinion is that while this is not likely a barrier, it is cumbersome to
go back and intentionally close the datepicker when it does not close. I'm
inclined to require the client to make the datepicker always close on blur.
For reference, here is a link to the guideline.
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
Any thoughts or opinions are greatly appreciated.
Thank you all!
-Peter
--
*Peter Quale*
Google Voice: (707) 992-5696
From: Steve Green
Date: Wed, Jul 18 2018 8:45AM
Subject: Re: Interpretation of WCAG 1.4.13
← Previous message | Next message →
I agree that closing the date picker on blur is highly desirable. Backtracking to the date field and pressing the Enter key is not compliant with 1.4.13, which states ".A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus".
However, if you can arrange for the Esc key to close the date picker regardless of where the focus is, my view is that this should be compliant.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Quale
Sent: 18 July 2018 15:30
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Interpretation of WCAG 1.4.13
Hello all,
I'm hoping to get some opinions on the breadth of WCAG 2.1 guideline 1.4.13, Content on Hover or Focus.
I'm helping with a datepicker widget that opens down from a form field when the user focuses on the field. The datepicker will sometimes close when blurred and sometimes not and in the past I would call this out to the client as a UX issue that affects accessibility. This client is also keen on addressing 2.1 issues immediately now that the standard is launched.
So my question to the group is does this behavior fit within the spirit of guideline 1.4.13? The datepicker does obscure the field immediately following the date field, but it is also possible to close the datepicker by backtracking to the date field and intentionally using an enter keypress.
My opinion is that while this is not likely a barrier, it is cumbersome to go back and intentionally close the datepicker when it does not close. I'm inclined to require the client to make the datepicker always close on blur.
For reference, here is a link to the guideline.
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
Any thoughts or opinions are greatly appreciated.
Thank you all!
-Peter
--
*Peter Quale*
Google Voice: (707) 992-5696
From: Peter Quale
Date: Wed, Jul 18 2018 11:24AM
Subject: Re: Interpretation of WCAG 1.4.13
← Previous message | No next message
Excellent point on the "Esc" key, Steve. Thank you.
On Wed, Jul 18, 2018 at 9:45 AM, Steve Green < = EMAIL ADDRESS REMOVED =
> wrote:
> I agree that closing the date picker on blur is highly desirable.
> Backtracking to the date field and pressing the Enter key is not compliant
> with 1.4.13, which states ".A mechanism is available to dismiss the
> additional content without moving pointer hover or keyboard focus".
>
> However, if you can arrange for the Esc key to close the date picker
> regardless of where the focus is, my view is that this should be compliant.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Peter Quale
> Sent: 18 July 2018 15:30
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Interpretation of WCAG 1.4.13
>
> Hello all,
>
> I'm hoping to get some opinions on the breadth of WCAG 2.1 guideline
> 1.4.13, Content on Hover or Focus.
>
> I'm helping with a datepicker widget that opens down from a form field
> when the user focuses on the field. The datepicker will sometimes close
> when blurred and sometimes not and in the past I would call this out to the
> client as a UX issue that affects accessibility. This client is also keen
> on addressing 2.1 issues immediately now that the standard is launched.
>
> So my question to the group is does this behavior fit within the spirit of
> guideline 1.4.13? The datepicker does obscure the field immediately
> following the date field, but it is also possible to close the datepicker
> by backtracking to the date field and intentionally using an enter keypress.
>
> My opinion is that while this is not likely a barrier, it is cumbersome to
> go back and intentionally close the datepicker when it does not close. I'm
> inclined to require the client to make the datepicker always close on blur.
>
> For reference, here is a link to the guideline.
> https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
>
> Any thoughts or opinions are greatly appreciated.
>
> Thank you all!
>
> -Peter
>
> --
> *Peter Quale*
> Google Voice: (707) 992-5696
> > > at http://webaim.org/discussion/archives
> > > > > >
--
*Peter Quale*
Google Voice: (707) 992-5696