WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: jQuery Datepicker - expected kb behavior?

for

From: JP Jamous
Date: Oct 13, 2018 12:16PM


I may have written it incorrectly, but I was not suggesting the use of arrow
keys. In fact, if I would design a calendar, I would make it look like a
table and definitely provide the proper object type to the screen reader.
The user will know it is a table and to use the CTRL + Alt + arrow keys.

My point was that using CTRL along with the arrow keys would not be
something used in a table, list box or other types of object for the most
part. They are strictly to read previous or next word, or previous or next
paragraph. However, if the user hears "Calendar, table with 7 columns and 5
rows. " Then the user would know that this is a table. CTRL + Alt + arrow
keys would be the best navigation method for this type of object.

In a way, I would dislike going into forms mode to pick a date. I prefer the
table layout, because that would keep the basic calendar layout on any piece
of paper. Simply use the 7 days of the week as column headings and the days
listed underneath them.

I strongly prefer to provide the proper object type and let the screen
reader user pick the navigation mode he or she requires. I focused heavily
on that with my Windows form applications in the past and still carry the
same concept with me to web applications. I definitely frown upon
overwriting the Windows or screen reader shortcut keys.





--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen
walker
Sent: Friday, October 12, 2018 4:15 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?

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.
>
>
>
http://webaim.org/discussion/archives