WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: jQuery Datepicker - expected kb behavior?

for

From: Janet Magruder
Date: Oct 12, 2018 6:01PM

 Janet Magruder1900 LanceyModesto, CA 95355
Cancel this do not email me again!

On Friday, October 12, 2018 2:16 PM, glen walker < <EMAIL REMOVED> > wrote:


Good points, JP.  However, your last point about having a component
implement ctrl+arrow might interfere with a screen reader can also be
applied to a component implementing an unmodified arrow key and having it
interfere with a screen reader user navigating the accessibility tree.
When focus moves into a menu (eg, a real menu with a menu role, not a
navigation menu that is a list of links), then you'll hear the menu role
and have the expectation that the (unmodified) arrow keys will navigate
(and many screen readers will tell you to use the arrow keys).  You don't
have any expectations that right arrow will read the next character rather
than move to the next menu item.

With a calendar, since there isn't a native element or aria role, there may
not be the same expectation.  Whether the calendar uses a simple arrow or a
modified arrow is kind of up to the developer, since we don't really have
any standards for it (unfortunately).  If a simple arrow is used, I would
think you'd hear the screen reader go into forms mode so that you'd know
the arrow keys won't navigate the accessibility tree.

On Fri, Oct 12, 2018 at 3:02 PM JP Jamous < <EMAIL REMOVED> > wrote:

>
> If CTRL + arrow keys are implemented, they can conflict with screen readers
> navigation scripts in a browser, thereby disabling the read word or
> paragraph functionality.
>
>
>