WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: jQuery Datepicker - expected kb behavior?

for

From: glen walker
Date: Oct 12, 2018 3:15PM

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.
>
>
>