E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 22 (In chronological order)

From: Mary Elizabeth Sullivan
Date: Mon, Nov 02 2015 5:56AM
Subject: Datepicker questions - are they useful?
No previous message | Next message →

Hello,

I have a question about datepickers for the group.

We are looking to create a recommended pattern for a style guide. This style guide will influence desktop, responsive and mobile native applications.

Generally we know we want

<label ...>
<format instructions>
<input text box>
<date picker validation>

We obviously will also have to keep error handling in mind. My questions to everyone are:
- do screen reader users enjoy accessible datepickers or do they prefer a text box?
- do keyboard only or zoomtext users enjoy accessible datepickers or do they prefer a text box?
- same question for dragon users

- also for responsive and mobile web, do people like the input typeÚte with mobile assistive technologies like VoiceOver and talkback? Switch control? Or is the textbox preferred?

- is a sequence of drop downs better?

Lately I've been trying to find a one size fits all option and I really haven't found one. It begs the question, what is the most fluid way for people to use a date picker. What is the user impact? Are calendar date pickers helpful or do they make a simple process more difficult?

Thank you,

Beth


Sent from my iPhone

From: _mallory
Date: Mon, Nov 02 2015 6:15AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

On Mon, Nov 02, 2015 at 07:56:46AM -0500, Mary Elizabeth Sullivan wrote:
>
> - is a sequence of drop downs better?

This is the only one I can really reply to, though I also personally
dislike graphical date pickers (mostly because everything's too small
and hard to choose, though I do like *seeing* the dates on a
calendar), and that is:
please check and user-test and check again if you go for the multi-
dropdown route. It's physically very easy to screw these up as a user
since your focus stays on the input while you may now think you've
switched to scrolling the page. Gov.uk should have some statistics
on this as I recall Anna Bartlett? giving a talk about all the problems
they've seen with select tags.

There's also the issue of having three inputs for what mentally we
consider a single value, the date. Using dropdowns is simply easier
for the back-end to check validity, but I can't say they're an
improvement for the front-end.

_mallory

From: Birkir R. Gunnarsson
Date: Mon, Nov 02 2015 6:42AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

A datepicker offers some things that an input field does not, such as
the ability to quickly select a date which falls on a given day of the
week.
Also it gives the aplication a way to restrict the dates available
)for some internal reason such as expiration date of offer, staff
availability etc.) and thus minimize the chance of users dealing with
error conditions on the form.
Usually datepickers are offered as an optional control to date input
fields, so this way you give the user best of both worlds.
A key to making datepickers useful on desktop is to set them up in an
accessible table or, better yet, offer keyboard shortcuts that quickly
let the user explore and choose a date. After all, you do not want the
keyboard only user to have to wear down his tabkey to get to December
12th, 2015 by tabbing through each date until then.

One accessible datepicker implementation is available at
https://dequeuniversity.com/resources (where you can download and play
with the code, it is written using JQuery).
The actual JQuery datepicker had a lot of accessibility issues last
time I looked (that was some months ago).
I think the 3 dropdown aproach is not bad either. As a user I have
found that to be a safe and relatively easy option, but that is the
opinion of a single (well, married) screen reader user. It might be a
nightmare for people with cognitive disabilities, I don't know.
And, yes, please use the html5 datatypes for mobile devices.
It make a ton of difference to get the appropriate UI or keyboard
option up when entering values in a mobile environment (such as the @
symbol on the main keyboard for type="email"). That should be better
for all users.
Cheers
-Birkir



On 11/2/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> On Mon, Nov 02, 2015 at 07:56:46AM -0500, Mary Elizabeth Sullivan wrote:
>>
>> - is a sequence of drop downs better?
>
> This is the only one I can really reply to, though I also personally
> dislike graphical date pickers (mostly because everything's too small
> and hard to choose, though I do like *seeing* the dates on a
> calendar), and that is:
> please check and user-test and check again if you go for the multi-
> dropdown route. It's physically very easy to screw these up as a user
> since your focus stays on the input while you may now think you've
> switched to scrolling the page. Gov.uk should have some statistics
> on this as I recall Anna Bartlett? giving a talk about all the problems
> they've seen with select tags.
>
> There's also the issue of having three inputs for what mentally we
> consider a single value, the date. Using dropdowns is simply easier
> for the back-end to check validity, but I can't say they're an
> improvement for the front-end.
>
> _mallory
> > > > >


--
Work hard. Have fun. Make history.

From: Nancy Johnson
Date: Mon, Nov 02 2015 7:07AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

I have also struggled with date pickers. I have encouraged the
engineers to use all JQuery UI for all client-side JS needs where
possible as I know it does add the WAI-ARIA controls automatically,
which may not be totally perfect but helps.

For the date picker I stayed with allowing user to add the date to the
field directly or popping the calendar off a button.

We have so many other issues that come up from changing business
requirements at the last minute and third party add ons, to security
and data issues. A one-size-fits all solution, that I need one size
fits all.

I will look at Deques solution.

Nancy


On Mon, Nov 2, 2015 at 8:42 AM, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:
> A datepicker offers some things that an input field does not, such as
> the ability to quickly select a date which falls on a given day of the
> week.
> Also it gives the aplication a way to restrict the dates available
> )for some internal reason such as expiration date of offer, staff
> availability etc.) and thus minimize the chance of users dealing with
> error conditions on the form.
> Usually datepickers are offered as an optional control to date input
> fields, so this way you give the user best of both worlds.
> A key to making datepickers useful on desktop is to set them up in an
> accessible table or, better yet, offer keyboard shortcuts that quickly
> let the user explore and choose a date. After all, you do not want the
> keyboard only user to have to wear down his tabkey to get to December
> 12th, 2015 by tabbing through each date until then.
>
> One accessible datepicker implementation is available at
> https://dequeuniversity.com/resources (where you can download and play
> with the code, it is written using JQuery).
> The actual JQuery datepicker had a lot of accessibility issues last
> time I looked (that was some months ago).
> I think the 3 dropdown aproach is not bad either. As a user I have
> found that to be a safe and relatively easy option, but that is the
> opinion of a single (well, married) screen reader user. It might be a
> nightmare for people with cognitive disabilities, I don't know.
> And, yes, please use the html5 datatypes for mobile devices.
> It make a ton of difference to get the appropriate UI or keyboard
> option up when entering values in a mobile environment (such as the @
> symbol on the main keyboard for type="email"). That should be better
> for all users.
> Cheers
> -Birkir
>
>
>
> On 11/2/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>> On Mon, Nov 02, 2015 at 07:56:46AM -0500, Mary Elizabeth Sullivan wrote:
>>>
>>> - is a sequence of drop downs better?
>>
>> This is the only one I can really reply to, though I also personally
>> dislike graphical date pickers (mostly because everything's too small
>> and hard to choose, though I do like *seeing* the dates on a
>> calendar), and that is:
>> please check and user-test and check again if you go for the multi-
>> dropdown route. It's physically very easy to screw these up as a user
>> since your focus stays on the input while you may now think you've
>> switched to scrolling the page. Gov.uk should have some statistics
>> on this as I recall Anna Bartlett? giving a talk about all the problems
>> they've seen with select tags.
>>
>> There's also the issue of having three inputs for what mentally we
>> consider a single value, the date. Using dropdowns is simply easier
>> for the back-end to check validity, but I can't say they're an
>> improvement for the front-end.
>>
>> _mallory
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > >

From: Bryan Garaventa
Date: Mon, Nov 02 2015 9:05AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

> One accessible datepicker implementation is available at
> https://dequeuniversity.com/resources

Hi, as a quick question, I'm not sure what the role=grid is for on the table element. The use of role=application will activate the correct modality when focus is set within, , yet role=grid propagates the Grid roles down through all of the table markup, but since focus is being set to the A tags and not the implicit Gridcell elements, the role of Grid doesn't really do anything since the construct is already contained within a properly marked up data table already.

From: Bryan Garaventa
Date: Mon, Nov 02 2015 9:28AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

A date picker is very useful, especially when it's important to know the day of the week or month involved, or when planning months or years in the future. This is especially the case with travel sites.

There is another implementation you are welcome to test at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
Which supports disabled date ranges, comment notation, date format changing, localization support within any language, calendar changing for European calendar layout differences, full control over styling across various devices, and so on.

The module works as powered by jQuery within the archive at
https://github.com/accdc/tsg

Or powered by Dojo at
https://github.com/accdc/tsg-dojo

Or powered by MooTools at
https://github.com/accdc/tsg-mootools

Sincerely,
Bryan Garaventa

From: Birkir R. Gunnarsson
Date: Mon, Nov 02 2015 10:16AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Re the Deque University datepicker:
The original idea was to use grid and we expect that would ensure
screen readers going into forms mode.
But at the time we tested it, we did not get the behavior we expected.
To force forms mode we added the application role.
We may need to look at this again, since I think the grid role alone
is sufficient now.



On 11/2/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> A date picker is very useful, especially when it's important to know the day
> of the week or month involved, or when planning months or years in the
> future. This is especially the case with travel sites.
>
> There is another implementation you are welcome to test at
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
> Which supports disabled date ranges, comment notation, date format changing,
> localization support within any language, calendar changing for European
> calendar layout differences, full control over styling across various
> devices, and so on.
>
> The module works as powered by jQuery within the archive at
> https://github.com/accdc/tsg
>
> Or powered by Dojo at
> https://github.com/accdc/tsg-dojo
>
> Or powered by MooTools at
> https://github.com/accdc/tsg-mootools
>
> Sincerely,
> Bryan Garaventa
>
>
>
>
>

From: Bryan Garaventa
Date: Mon, Nov 02 2015 12:36PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

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.

From: Birkir R. Gunnarsson
Date: Mon, Nov 02 2015 3:08PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Mon, Nov 02 2015 9:02PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

No problem, I understand the issues as well, and had to consider all of the same things when building the WhatSock date picker too.

What I concluded back in 2012 when building it, was that there was a need for there to be a certain level of functional equivalence in the experience for such a control that traditional tables and similar based markup didn't provide.

For example, in the scenario where there is a time based limit, such as wen filling out a stock trade date range, or a time sensitive ticket purchase for a concert, or for a travel site where the availability changes by the minute, and so on, there needs to be a way for a non-sighted screen reader or keyboard only user to perform the same actions as a sighted mouse user within an equivalent time range in order for this type of interaction to be both usable and accessible for them as well.

All of the methods I tried back then required anywhere from ten to twenty extra steps for every single step for a sighted mouse user to accomplish, which is unacceptable.

So the most useful implementation I came up with was to use standard Link and Button roles, by surrounding these first with role=dialog, with a child table with role=application, and with standard Link and Button roles within for managing focus between them.

This sounds weird, but it deals with many different AT issues that existed back then, such as JAWS 11 not supporting role=application until JAWS14, yet activating Applications Mode prior to that using role=dialog going back to JAWS 12, where role=application was supported in JAWS11 when in IE going back to IE8 on Windows XP, and so on.

The use of the Application role in this case ensures the greatest level of equal accessibility possible, since it enforces a level of interaction that is impossible without it.

The result being, that you can test the WhatSock date picker using any version of JAWS going back to JAWS11 in IE8 on Windows XP to the present, as well as on modern ATs like NVDA or VO on iOS or on the Mac, and it will allow any user to choose a date on any weekday on any month on any year in a matter of seconds from the keyboard equally. Granted touch based navigation is always a bit slower, but this is true for everything.

So basically, I simply want the same user experience that everybody else has, or as close to it as I can get, with the same level of convenience and usability for everybody as possible.

This is what I think the true meaning of accessibility should be.

All the best,
Bryan

From: Chaals McCathie Nevile
Date: Mon, Nov 02 2015 5:21PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

On Tue, 03 Nov 2015 07:08:34 +0900, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:

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

In principle you should be able to use accesskey to do this - with the
added bonus that it would work for keyboard users who haven't got a
screenreader running.

As we know, implementation in browsers is still generally bad - although
it has improved from the "truly dreadful" it used to be, so there is hope.

More importantly, it is often screen reader users who miss out since their
shortcuts are generally not overridden any more, but no effort is made to
reassign the access key.

This is one of the gazillions of use cases that motivate
https://chaals.github.io/accesskey/index.src.html which I hope is ready to
propose for wider review now, as a step to getting a decent solution to
these problems in browsers.

One of the things I tried to do there is make as easy a transition path as
possible. The result is basically that people who are using piles of
javascript in an attempt to solve the issue will be able to throw most of
it away, people who use accesskey already will find it magically being
more useful, and browsers have a smooth upgrade path without breaking any
kind of compatibility I can find.

Of course we'll see what happens if we get this on the road…

cheers

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

From: MEJ - Beth Sullivan
Date: Tue, Nov 03 2015 10:56AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Hello,



as usual I can humbled by the responses I see in peace responses you all
have provided. Thank you dearly.



I'm going to attempt to respond to each of your comments.


_mallory - thank you for the information on date pickers from your
perspective I'd be cuirous to see the information that was posted by Gov.uk
on select fields and there shortcomings. I'm getting from you is that when
you are selecting a date the calendar function is important so you can
understand what day of the week you are choosing as well as getting a
mental model of a calendar grid.


Birkir, from your first email, I understand they can minimize the need for
error handling. The concern I have is that keyboard shortcuts are
inconsistent between date picker to date picker for keyboard users and that
currently there is not a date picker that we can say works with three
different assistive technologies (keyboard, JAWS, voiceover) let alone the
myriad of other assistive technologies that a user might be using with the
date picker. The Deque University date picker is the best I've tested yet
but it falls short in the requirement to call out the date that have been
picked and move focus back to the input field with the most current iOS
Voiceover. For the HTML5 input fields I've had a better success with
voiceover since obtained to iOS nine, although I'm not sure how well that
would work talkback. And if you look at the iOS implementation of the HTML5
date field, it is a series of 3 scroll bars not a calendar date picker.


Nancy, I think I'm in the same spot as you with my concerns. There's
nothing right now that fills all the requirements, not that great people
like Bryan, Birkir, and Deque aren't trying. There are lots that are very
close but I'm not comfortable just yet telling my business partners to use
this kind of mostly accessible date picker. In their perfect world, they
would get rid of the input fields altogether. My team isn't going to let
that happen, but what I'm hoping understand is how much effort are these
date pickers worth and when do we say, okay this is the best we have and
what users will we need understand won't have the same experience for
"this" amount of time, which may be the next big redesign in 5-6 years
after this redesign. Or is it about finding a better solution for everyone.
It seems to me that there are some great advantages for all users, from a
practical perspective I have yet to see one that works in all ways is it
supposed to, especially when we look at native mobile browsers not even
implementing calendar date pickers, but other forms like the iOS date
picker.


Bryan, thank you for your links to a few other date pickers to test as
well. You mentioned the case of travel sites. Here's what really grabs my
attention, now I may be a bit preemptive in assuming these sites would have
properly implemented accessible date pickers since the required date isn't
until mid December 2015 apparently, but the fact of the matter is that they
have yet to at this point. Now I'm in Canada but I am aware of the air
carrier access act the states which requires all flights companies have
believed to have accessible sites. For more information see the Deque link:
http://www.deque.com/air-carrier-access-act-update/ . What I find
interesting is that the industry that has the most need for them don't have
accessible date pickers. It looks to me that in these situations they are
going for the label, (possibly offscreen) format, with input fields
solution, mobile or web.


I want to reiterate that I 100% believe that these date pickers should be
accessible to everyone. But what I getting even from the role=grid great
conversation is that the state of screen readers does not allow for this to
work fully. That with every instance and example there is a caveat.


Love to hear more feedback on this. Is there another / better way?


Thank you,

Beth

On Mon, Nov 2, 2015 at 7:21 PM, Chaals McCathie Nevile <
= EMAIL ADDRESS REMOVED = > wrote:

> On Tue, 03 Nov 2015 07:08:34 +0900, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> 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.
>>
>
> In principle you should be able to use accesskey to do this - with the
> added bonus that it would work for keyboard users who haven't got a
> screenreader running.
>
> As we know, implementation in browsers is still generally bad - although
> it has improved from the "truly dreadful" it used to be, so there is hope.
>
> More importantly, it is often screen reader users who miss out since their
> shortcuts are generally not overridden any more, but no effort is made to
> reassign the access key.
>
> This is one of the gazillions of use cases that motivate
> https://chaals.github.io/accesskey/index.src.html which I hope is ready
> to propose for wider review now, as a step to getting a decent solution to
> these problems in browsers.
>
> One of the things I tried to do there is make as easy a transition path as
> possible. The result is basically that people who are using piles of
> javascript in an attempt to solve the issue will be able to throw most of
> it away, people who use accesskey already will find it magically being more
> useful, and browsers have a smooth upgrade path without breaking any kind
> of compatibility I can find.
>
> Of course we'll see what happens if we get this on the road…
>
> cheers
>
>
> 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 ADDRESS 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.
>>>
>>>
>>>
>>>

From: Bryan Garaventa
Date: Tue, Nov 03 2015 12:23PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

One thing that is important to keep in mind, is that there is no such thing as 100% accessibility. No matter what you do, there is always going to be a percentage of people who have difficulty with whatever it is. The reason being that there is no way to predict all types and variations of disabilities for all people at the same time, and all such have different ways and technologies for accessing these technologies. Also, there are many who have such disabilities who don't have access to these technologies at all, and nothing will allow them to access these features without them.

So it's a mistake to not recommend something because it is not 100% accessible to all people equally.

That being said, we as developers can raise the bar as high as possible, and staple it there, so that others can learn from and build new and better technologies from such benchmarks in the future.

This is the concept that I used to build the WhatSock date picker, so that others might learn from and benefit from the research that went into its construction, and use it if they desire.

As technologies change, better solutions are likely to evolve as ATs improve and API mappings become better synchronized with browsers and so on, so all of these technologies will evolve with them as time goes on. It's doubtful however that such simple constructs as the one I've been referencing will just stop working though, since it uses the most basic of concepts to comprise it's functionality. Even so, specs change and sometimes events are deprecated, and widgets need to be updated accordingly. The trick for managing this is to modularize components like this so they can be easily updated and just plugged back into the application without disrupting functionality.

Luckily styling and content display is easy to change using CSS, so it's also important to understand the difference between the functional accessibility of an interactive widget versus how it looks, which are very different. E.G If something simply doesn't look right, it can easily be changed. If something is programmed inaccessibly however, it is often much harder to fix no matter what it looks like.

Please do me a favor and test the WhatSock date picker when you have time and let me know which accessibility issues you encounter. I can usually fix them very quickly when discovered. Also, for any control like this, the type of device will often affect its usability, which can't be avoided. For example you can view something on a monitor or tablet with ease, but try to do the same on a 2 inch wide iPod screen and it will likely be impossible to interact with. We haven't figured out a foolproof way of dealing with all devices equally as yet, but this should get easier as time goes on and responsive design techniques improve.

All the best,
Bryan

From: Birkir R. Gunnarsson
Date: Tue, Nov 03 2015 6:34PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Beth

The closest we have to a guide on how keybord navigation within
datepickers should work is the ARIA Authoring Practices Guide:
http://www.w3.org/TR/wai-aria-practices-1.1/#datepicker
This guide is not normative (meaning not all keyboard interaction has
to follow this exact model), and the task force (that includes myself
as well as Bryan) are working on ideas and improvements.

I thought you might find this useful.
I will take a second look at the Deque datepicker with Voiceover. It
used to work fine (including the focus management when user selects a
date from the calendar widget) when we tested it but that was with
Voiceover 8 (I think 8.1).
This is the other challenge we face.
Assistive technologies keep changing.
Fortunately most of the time it is for the better, but sometimes they
change the way they interpret web or application content. When those
updates are combined with upgrades to the browsers which deliver the
webpage content to them, makes making complex widgets accessible a
moving target.
So I think we should all keep trying. That is what myself, Bryan (who
taught me a lot of what I know actually), and others keep trying to
come up with ever so slightly different implementations to see what
works best, and to realize where there are problems.
We try to communicate those problems to browser and the assistive
technology vendors, and improve standards and recommendations if that
helps make complex content universally accessible.
We cannot achieve a 100% accessible datepicker currently on all
combinations of assistive technologies and browsers.
But I think we should put the best and most accessible widgets we can
make out there. When we do that, people will want to use them with
their adaptive hardware or software, those people will hopefully
report those problems, which creates a demand and discussion to get
them fixed.
Offer a text input field as a more accessible fallback solution, even
when it isn't perfect.
That way you try to deliver the best of both worlds to the user.






On 11/3/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> One thing that is important to keep in mind, is that there is no such thing
> as 100% accessibility. No matter what you do, there is always going to be a
> percentage of people who have difficulty with whatever it is. The reason
> being that there is no way to predict all types and variations of
> disabilities for all people at the same time, and all such have different
> ways and technologies for accessing these technologies. Also, there are many
> who have such disabilities who don't have access to these technologies at
> all, and nothing will allow them to access these features without them.
>
> So it's a mistake to not recommend something because it is not 100%
> accessible to all people equally.
>
> That being said, we as developers can raise the bar as high as possible, and
> staple it there, so that others can learn from and build new and better
> technologies from such benchmarks in the future.
>
> This is the concept that I used to build the WhatSock date picker, so that
> others might learn from and benefit from the research that went into its
> construction, and use it if they desire.
>
> As technologies change, better solutions are likely to evolve as ATs improve
> and API mappings become better synchronized with browsers and so on, so all
> of these technologies will evolve with them as time goes on. It's doubtful
> however that such simple constructs as the one I've been referencing will
> just stop working though, since it uses the most basic of concepts to
> comprise it's functionality. Even so, specs change and sometimes events are
> deprecated, and widgets need to be updated accordingly. The trick for
> managing this is to modularize components like this so they can be easily
> updated and just plugged back into the application without disrupting
> functionality.
>
> Luckily styling and content display is easy to change using CSS, so it's
> also important to understand the difference between the functional
> accessibility of an interactive widget versus how it looks, which are very
> different. E.G If something simply doesn't look right, it can easily be
> changed. If something is programmed inaccessibly however, it is often much
> harder to fix no matter what it looks like.
>
> Please do me a favor and test the WhatSock date picker when you have time
> and let me know which accessibility issues you encounter. I can usually fix
> them very quickly when discovered. Also, for any control like this, the type
> of device will often affect its usability, which can't be avoided. For
> example you can view something on a monitor or tablet with ease, but try to
> do the same on a 2 inch wide iPod screen and it will likely be impossible to
> interact with. We haven't figured out a foolproof way of dealing with all
> devices equally as yet, but this should get easier as time goes on and
> responsive design techniques improve.
>
> All the best,
> Bryan
>
>
>
>

From: _mallory
Date: Wed, Nov 04 2015 2:10AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

On Tue, Nov 03, 2015 at 11:23:16AM -0800, Bryan Garaventa wrote:
> ...For example you can view something on a monitor or tablet with ease, but try to do the same on a 2 inch wide iPod screen and it will likely be impossible to interact with.

Hm, a lot of mobiles seem to have their own built-in calendar
software and can also run downloaded calendar apps. I wonder
if it would make sense for the small devices to, when encountering
an input typeÚte, switch context to whatever built-in calendar
they've got? It removes control from web page developers but
assuming the builtin calendar can accept meta-data from the
site (like that only certain dates should be choosable), we
know these calendars are specifically built for the tiny screens,
built to work with their built-in AT (mags and readers), and
for touch. It could also let users see their own calendar stuff
at the same time (the in-built calendar may show an appointment
on a date the user may be choosing for a trip).

I'm trying to think of another example where clicking something
on a web page would change context, but the only one I can think
of is clicking on another file type and the browser or OS knowing
whether it should open for example Adobe Reader rather than a
PDF in a new tab.

Has there been any discussion in this direction? Especially if it
were something a user could set up on their own device (whether to
allow a web-page datepicker vs using a built-in one), this could
make it mostly a non-issue whether the datepicker works exactly the
same cross-device-- it would instead work however the user was used
to working anyway.

_mallory

From: Jonathan Avila
Date: Wed, Nov 04 2015 6:27AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

> I'm trying to think of another example where clicking something on a web page would change context

On mobile platforms such as iOS touching a play button on multimedia will often launch a full screen platform level media player that has a done button that will take you back to the page.

Jonathan

From: Bryan Garaventa
Date: Wed, Nov 04 2015 11:01AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

> Hm, a lot of mobiles seem to have their own built-in calendar software and can also run downloaded calendar apps. > I wonder if it would make sense for the
> small devices to, when encountering an input typeÚte, switch context to whatever built-in calendar they've got? > It removes control from web page developers
> but assuming the builtin calendar can accept meta-data from the site (like that only certain dates should be > choosable), we know these calendars are specifically
> built for the tiny screens, built to work with their built-in AT (mags and readers), and for touch. It could also let users > see their own calendar stuff
> at the same time (the in-built calendar may show an appointment on a date the user may be choosing for a trip).

That would be helpful if possible in some cases, but usually date pickers are meant to go two ways, first opening the calendar from the web page which is probably doable in some cases like this, but also the other way where the date selected needs to be sent back to the web page in a way that can be processed. Also there may be disabled date ranges or additional info that needs to be conveyed within the calendar to the user at the same time that may not be possible to do on a software/app based calendar since it would only apply to the site where the date picker was originally located. Currently it's not possible for a standard web page to send and receive information like this by accessing apps on the device OS like this, because it also introduces security vulnerabilities. E.G If a malicious site were for example to access your calendar and read all of your events it could also save and record them, which would be a breach of your privacy.

There has indeed been discussion for making native date pickers that work in browsers, but date pickers that actually display interactive calendars are still a ways off. First all of the browser implementers need to agree on how something should be displayed and what it should do, and how it should work, and how it should map, and how it should render, and how it should be configurable, and so on. To my knowledge nobody has tried to spec something like this out as yet. Perhaps some of the browser guys on this list may know of something in this regard.

From: _mallory
Date: Thu, Nov 05 2015 7:07AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

On Wed, Nov 04, 2015 at 10:01:17AM -0800, Bryan Garaventa wrote:
> That would be helpful if possible in some cases, but usually date pickers are meant to go two ways, first opening the calendar from the web page which is probably doable in some cases like this, but also the other way where the date selected needs to be sent back to the web page in a way that can be processed. Also there may be disabled date ranges or additional info that needs to be conveyed within the calendar to the user at the same time that may not be possible to do on a software/app based calendar since it would only apply to the site where the date picker was originally located. Currently it's not possible for a standard web page to send and receive information like this by accessing apps on the device OS like this, because it also introduces security vulnerabilities. E.G If a malicious site were for example to access your calendar and read all of your events it could also save and record them, which would be a breach of your privacy.

Yeah, it would have to be one-way metadata from the site to the
calendar app to counter security problems, and the selection of
date(s) would need to be considered an input back to the page,
something I think the calendar would/should be able to control.

>
> There has indeed been discussion for making native date pickers that work in browsers, but date pickers that actually display interactive calendars are still a ways off. First all of the browser implementers need to agree on how something should be displayed and what it should do, and how it should work, and how it should map, and how it should render, and how it should be configurable, and so on. To my knowledge nobody has tried to spec something like this out as yet. Perhaps some of the browser guys on this list may know of something in this regard.

fingers crossed.
_m

From: Kevin Prince
Date: Thu, Nov 05 2015 9:08PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Just looking at this from a user perspective (sighted, mouse available)

My first thought is that a date picker is useful where there is both a specific day and validation required. My preference is to type directly (eg a birth date) in ddmmyy format or have 3 dropdowns (but please date first, it's so confusing when the month is first for most of the world :)) So there are a couple of context-based thoughts as to when to use which:
1. If you want my birthday, wedding day etc just let me type it and tell me clearly what format (preferably handle the format behind the scenes and accept yy or yyyy and mm or MMM).
2. If you are really stuck on a format give me 3 labelled dropdowns but I insist you let me use first character navigation.
3. If it's something where validating the day and date (eg =booking a xyz ) then go for the accessible datepicker. In 1 and 2 you can offer the datepicker as an alternative too of course.

If you do the datepicker don't forget to style it so I can see it (one of the examples had a visual focus indicator of dark grey on black seemingly)

Thanks for this thread and the two examples though - I had literally just been asked to go find what was available and looked in the Webaim list to kill some time while I found the energy.

Kev
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.



> On 6/11/2015, at 03:07, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> On Wed, Nov 04, 2015 at 10:01:17AM -0800, Bryan Garaventa wrote:
>> That would be helpful if possible in some cases, but usually date pickers are meant to go two ways, first opening the calendar from the web page which is probably doable in some cases like this, but also the other way where the date selected needs to be sent back to the web page in a way that can be processed. Also there may be disabled date ranges or additional info that needs to be conveyed within the calendar to the user at the same time that may not be possible to do on a software/app based calendar since it would only apply to the site where the date picker was originally located. Currently it's not possible for a standard web page to send and receive information like this by accessing apps on the device OS like this, because it also introduces security vulnerabilities. E.G If a malicious site were for example to access your calendar and read all of your events it could also save and record them, which would be a breach of your privacy.
>
> Yeah, it would have to be one-way metadata from the site to the
> calendar app to counter security problems, and the selection of
> date(s) would need to be considered an input back to the page,
> something I think the calendar would/should be able to control.
>
>>
>> There has indeed been discussion for making native date pickers that work in browsers, but date pickers that actually display interactive calendars are still a ways off. First all of the browser implementers need to agree on how something should be displayed and what it should do, and how it should work, and how it should map, and how it should render, and how it should be configurable, and so on. To my knowledge nobody has tried to spec something like this out as yet. Perhaps some of the browser guys on this list may know of something in this regard.
>
> fingers crossed.
> _m
> > > >

From: Bryan Garaventa
Date: Fri, Nov 06 2015 11:50AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Thanks, those are all helpful. Luckily these are fairly simple to implement within any web UI.

Regarding the format, mm/dd/yyy or dd/mm/yyy, I agree it is confusing at times. This can be helped using supplementary description text or a placeholder at times.

Also, this can be addressed programmatically for some sites that span multiple countries. For example, the date format string for the WhatSock date picker simply uses a callback function when a date is selected, then the developer can use whatever parsing logic and string format they wish to populate the field, or even control the values of three individual select elements such as Day, Month, and Year, so this flexibility is easily achieved.

Typically I recommend both, the ability to manually enter the desired date, and an accessible date picker, because having both will ensure the greatest value for all user types.

> If you do the datepicker don't forget to style it so I can see it (one of the examples had a visual focus indicator of
> dark grey on black seemingly)

Probably my fault, I'm blind so this can slip past me at times. The source code is easily changed however for anybody who wishes to employ different styling and content.

All the best,
Bryan

From: Whitney Quesenbery
Date: Sat, Nov 07 2015 8:57AM
Subject: Re: Datepicker questions - are they useful?
← Previous message | Next message →

Dropping back a bit from the technical questions, there is not one simple
rule for how to collect dates in a form or interface.

The UK GDS has done some excellent work untangling this, thinking about
differences in how we might want to edit dates based on context -- and most
importantly, what we know about the date in question.

Their Design Pattern for Dates
<https://www.gov.uk/service-manual/user-centred-design/resources/patterns/dates.html>
discusses

- Memorable dates
- Copied dates
- Approximate dates
- Relative dates
- Calendar controls
- Formatting dates
- Validating dates

There is also a good article on asking for a date of birth (common need in
many govt forms). I value it for the reports of usability work on this
topic and how it shaped the design they now recommend.
https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/

One usability/accessibility problem in the article has been corrected in
the article, with the labels now outside of the form, where they belong.

It also points out that the reading (and visual) order should put any
instructions BEFORE they are needed, not AFTER - no matter how tempting it
might be.


On Fri, Nov 6, 2015 at 1:50 PM Bryan Garaventa < = EMAIL ADDRESS REMOVED = >
wrote:

> Thanks, those are all helpful. Luckily these are fairly simple to
> implement within any web UI.
>
> Regarding the format, mm/dd/yyy or dd/mm/yyy, I agree it is confusing at
> times. This can be helped using supplementary description text or a
> placeholder at times.
>
> Also, this can be addressed programmatically for some sites that span
> multiple countries. For example, the date format string for the WhatSock
> date picker simply uses a callback function when a date is selected, then
> the developer can use whatever parsing logic and string format they wish to
> populate the field, or even control the values of three individual select
> elements such as Day, Month, and Year, so this flexibility is easily
> achieved.
>
> Typically I recommend both, the ability to manually enter the desired
> date, and an accessible date picker, because having both will ensure the
> greatest value for all user types.
>
> > If you do the datepicker don't forget to style it so I can see it (one
> of the examples had a visual focus indicator of
> > dark grey on black seemingly)
>
> Probably my fault, I'm blind so this can slip past me at times. The source
> code is easily changed however for anybody who wishes to employ different
> styling and content.
>
> All the best,
> Bryan
>
>

From: Kevin Prince
Date: Tue, Nov 10 2015 2:42PM
Subject: Re: Datepicker questions - are they useful?
← Previous message | No next message

Thanks Whitney - that's really useful

Kev
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.



> On 8/11/2015, at 04:57, Whitney Quesenbery < = EMAIL ADDRESS REMOVED = > wrote:
>
> Dropping back a bit from the technical questions, there is not one simple
> rule for how to collect dates in a form or interface.
>
> The UK GDS has done some excellent work untangling this, thinking about
> differences in how we might want to edit dates based on context -- and most
> importantly, what we know about the date in question.
>
> Their Design Pattern for Dates
> <https://www.gov.uk/service-manual/user-centred-design/resources/patterns/dates.html>
> discusses
>
> - Memorable dates
> - Copied dates
> - Approximate dates
> - Relative dates
> - Calendar controls
> - Formatting dates
> - Validating dates
>
> There is also a good article on asking for a date of birth (common need in
> many govt forms). I value it for the reports of usability work on this
> topic and how it shaped the design they now recommend.
> https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/
>
> One usability/accessibility problem in the article has been corrected in
> the article, with the labels now outside of the form, where they belong.
>
> It also points out that the reading (and visual) order should put any
> instructions BEFORE they are needed, not AFTER - no matter how tempting it
> might be.
>
>
> On Fri, Nov 6, 2015 at 1:50 PM Bryan Garaventa < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thanks, those are all helpful. Luckily these are fairly simple to
>> implement within any web UI.
>>
>> Regarding the format, mm/dd/yyy or dd/mm/yyy, I agree it is confusing at
>> times. This can be helped using supplementary description text or a
>> placeholder at times.
>>
>> Also, this can be addressed programmatically for some sites that span
>> multiple countries. For example, the date format string for the WhatSock
>> date picker simply uses a callback function when a date is selected, then
>> the developer can use whatever parsing logic and string format they wish to
>> populate the field, or even control the values of three individual select
>> elements such as Day, Month, and Year, so this flexibility is easily
>> achieved.
>>
>> Typically I recommend both, the ability to manually enter the desired
>> date, and an accessible date picker, because having both will ensure the
>> greatest value for all user types.
>>
>>> If you do the datepicker don't forget to style it so I can see it (one
>> of the examples had a visual focus indicator of
>>> dark grey on black seemingly)
>>
>> Probably my fault, I'm blind so this can slip past me at times. The source
>> code is easily changed however for anybody who wishes to employ different
>> styling and content.
>>
>> All the best,
>> Bryan
>>
>>