WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Birkir R. Gunnarsson
Date: Nov 2, 2015 3:08PM

Thanks for all that info, very true.
The difficulty is the concept of interactive vs. browse mode in screen
readers and custom keyboard shortcuts implemented by applications.
There is no graceful way to communicate to screen readers that the
webpage developers implemented a set of keyboard navigation features
that could speed up and simplify the interaction.
A lot of beginner to intermediate screen reader users are still not
fully aware of the idea of browse mode or key pass through options.
Sure, off-screen instructions could be added for the element that
receives focus when the datepicker opens, or link them with the
calendar pop-up trigger element, but those would probably start to
annoy screen reader users who are used to interacting with the
webpage.
So in creating this example I was caught between forcing the users to
discover the behavior by using the application role, and let the
screen reader application itself decide on the interaction mode and
leave the mode of navigation up to the user by using the grid role.
I think the grid roll spec strongly suggests use of application mode
(else it would be no different from a table that includes interactive
elements), but ultimately I cannot read a definite interpretation from
the spec.
I only consider grids for content that does not include static
elements (unless associated with itneractive elemetns in some way).
So I may revisit the example and choose one mode over the other,
probably role = grid over application.
In general I don´t like the application role, and I avoid it whenever
possible, because we should not dictate how specific assistive
technologies work, it is up to them to know how to do things in a way
that is best for the end user.
But sometimes it seems like it would be the best option to ensure that
when a lot of work has been put into the user experience, for all
users including keyboard only and screen reader users, that work
should not go unnoticed.
Cheers



On 11/2/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> Actually it's not last time I checked, and may be doing the opposite in JAWS
> when in Virtual Cursor mode.
>
> E.G, using IE11 with JAWS16 on Win7 at
> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
> simply arrowing to the calendar picker button in VC mode and pressing Enter
> causes the date picker to open, but Applications Mode is not invoked as
> expected.
>
> Regarding role=grid, there are still significant screen reader differences
> between how JAWS and NVDA treat this, which you will notice between IE and
> FF using both, as well as within Chrome. E.G
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm
>
> One thing to keep in mind with role=grid as well, the use of role=grid is
> not supposed to cause a specific behavior to occur according to the ARIA
> spec, but role=application is, which is why there is so much confusion there
> even today.
>
> A Grid is simply meant to convey an interactive Grid construct where
> Gridcell nodes can be interacted with, but role=application specifies that
> an AT should pass all keystrokes to the element that has focus, but they
> both don't mean the same thing. E.G a Grid is a Composite widget type
> (Reference
> http://www.w3.org/TR/wai-aria-1.1/#composite )
> and may include embedded active elements that may not require Applications
> Mode when focus is set to one of them.
>
>
>
>