E-mail List Archives

Search E-mail List Archives for

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

From: Nisar A
Date: Thu, May 19 2016 7:52AM
Subject: Accessible Datepicker & NVDA Support
No previous message | Next message →

Hello experts,

I built up a datepicker using bits and pieces from other datepickers. Is
there a way I can verify if that datepicker is compliant with USDOT-508 /
meets the WCAG 2.1.1 guidelines?

Here is the working example for reference: https://jsfiddle.net/j49gz3g3/4/

Some people in the testing team say that it is not compliant since NVDA
screen reader reads out the date along with the column/row number. They
claim it should read only the date and not extra information.

Is that true?

Thanks,
Nisar

From: Meacham, Steve - FSA, Kansas City, MO
Date: Thu, May 19 2016 8:55AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Nice work so far on the keyboard-only accessibility. I haven't tested it sight-free. Here are some things you might want to address.

- The icons and drop-down for these don't appear visually for me using Internet Explorer 11, though the invisible controls still work;
- I haven't found a way to change the year alone and directly with only the keyboard; and
- The day-of-week is non-apparent.

I hope this helps,
Steve

From: Brandon Keith Biggs
Date: Thu, May 19 2016 10:10AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Hello,
NVDA users would be crazy if they used a date picker! (Not sure why they
exist). Just type MM/DD/YYY in the label. But that date picker is fine on
my end (although I would never use it because I have to go through every
day in every year!)
Thanks,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;

On Thu, May 19, 2016 at 6:52 AM, Nisar A < = EMAIL ADDRESS REMOVED = > wrote:

> Hello experts,
>
> I built up a datepicker using bits and pieces from other datepickers. Is
> there a way I can verify if that datepicker is compliant with USDOT-508 /
> meets the WCAG 2.1.1 guidelines?
>
> Here is the working example for reference:
> https://jsfiddle.net/j49gz3g3/4/
>
> Some people in the testing team say that it is not compliant since NVDA
> screen reader reads out the date along with the column/row number. They
> claim it should read only the date and not extra information.
>
> Is that true?
>
> Thanks,
> Nisar
> > > > >

From: Jonathan Avila
Date: Thu, May 19 2016 10:15AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

> (Not sure why they exist). Just type MM/DD/YYY in the label.

Date pickers are sometimes necessary because they can indicate dates that are unavailable/available/holiday and they provide additional information in tabular form such as the week a date falls on or for example whether a date is the first, two, third, etc. Thursday in the month.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

From: Meacham, Steve - FSA, Kansas City, MO
Date: Thu, May 19 2016 11:08AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

In my organization, I consider date pickers to be a "progressive enhancement" and don't even assess them for accessibility, so long as the user has the option to use them or ignore them and still specify a date.

From: Paul J. Adam
Date: Thu, May 19 2016 2:33PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

The first example is missing a role for the date picker elements and missing something to indicate a selected state to the screen reader user.

<td id="cell19-dt" class="day selectable curDay focus" data-value="19" aria-label="Thursday, May 19, 2016" tabindex="0">19</td>

Possibly make it a role=button and aria-pressed=true for the selected button. Right now it's speaking as a "group" to VoiceOver OS X which does not indicate it's an actionable control.

Here's an example of an accessible date picker that also works on mobile, https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

I'm not sure how you could exclude date picker widgets from Accessibility testing. Because in my view it's not equal access if you have to type the date manually MM/DD/YYYY but a mouse user can easily click the date they want and see if that day is a Friday or Sunday without pulling out their own calendar. I would not consider it progressive enhancement, I would consider it a custom HTML widget that can be developed with keyboard and screen reader accessibility. Everything on the web page must be accessible.

I think some screen reader users may avoid date pickers or think they don't have to be accessible because they may have never seen an accessible date picker actually used in the real world. Accessible date pickers can be created and should be created. I would say if you don't want to make the date picker accessible then don't use the date picker at all :)

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On May 19, 2016, at 12:08 PM, Meacham, Steve - FSA, Kansas City, MO < = EMAIL ADDRESS REMOVED = > wrote:
>
> In my organization, I consider date pickers to be a "progressive enhancement" and don't even assess them for accessibility, so long as the user has the option to use them or ignore them and still specify a date.
>
>

From: Birkir R. Gunnarsson
Date: Thu, May 19 2016 3:52PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Well said Paul!
An accessible datepicker (laid out as a grid with keyboard navigation
to match) is easy to navigate. When you include info such as
availability or selectability it becomes a completely different widget
from a date input field where this info is not immediately available.



On 5/19/16, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> The first example is missing a role for the date picker elements and missing
> something to indicate a selected state to the screen reader user.
>
> <td id="cell19-dt" class="day selectable curDay focus" data-value="19"
> aria-label="Thursday, May 19, 2016" tabindex="0">19</td>
>
> Possibly make it a role=button and aria-pressed=true for the selected
> button. Right now it's speaking as a "group" to VoiceOver OS X which does
> not indicate it's an actionable control.
>
> Here's an example of an accessible date picker that also works on mobile,
> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
>
> I'm not sure how you could exclude date picker widgets from Accessibility
> testing. Because in my view it's not equal access if you have to type the
> date manually MM/DD/YYYY but a mouse user can easily click the date they
> want and see if that day is a Friday or Sunday without pulling out their own
> calendar. I would not consider it progressive enhancement, I would consider
> it a custom HTML widget that can be developed with keyboard and screen
> reader accessibility. Everything on the web page must be accessible.
>
> I think some screen reader users may avoid date pickers or think they don't
> have to be accessible because they may have never seen an accessible date
> picker actually used in the real world. Accessible date pickers can be
> created and should be created. I would say if you don't want to make the
> date picker accessible then don't use the date picker at all :)
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>> On May 19, 2016, at 12:08 PM, Meacham, Steve - FSA, Kansas City, MO
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> In my organization, I consider date pickers to be a "progressive
>> enhancement" and don't even assess them for accessibility, so long as the
>> user has the option to use them or ignore them and still specify a date.
>>
>>

From: Tim Harshbarger
Date: Fri, May 20 2016 6:46AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

> I'm not sure how you could exclude date picker widgets from Accessibility
> testing.
I agree. I personally would not exclude testing a date picker simply because the user can also enter the date in a textfield.

The reason I would choose to test the date picker is due to author intent. Whoever designed the form obviously intended to make the date picker available to users. Most likely, they are trying to facilitate the user's ability to pick a specific date. That might be due to users having some idea what day they want, but not sure which date that is. Maybe, the author doesn't want users leaving the page to go find that information because it negatively impacts conversion rates.

Whatever the reason, I would want to test the date picker because I feel my role as an accessibility expert is to help the "author" convey their intent to the users in as accessible manner as possible. I feel like the choice of whether or not to make something accessible belongs to the author alone--though my hope is always that the choice will be to make the component more accessible.

However, I would not necessarily throw stones at my colleagues that do not test things like date pickers. I know there can be situations where you need to limit the accessibility testing. Perhaps, you are working with people new to accessibility and want to start them on fixing easier problems. Maybe, an inaccessible date picker with an accessible edit field is a lower priority than some other problems. And I suspect there might be other reasons. But I would personally not limit my testing because I thought the edit field was good enough--again I personally feel that my role is to provide the information and then let the "authors" decide what they will do with it.

Thanks,
Tim

From: Chaals McCathie Nevile
Date: Sat, May 21 2016 4:40AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

On Thu, 19 May 2016 17:08:20 -0000, Meacham, Steve - FSA, Kansas City, MO
< = EMAIL ADDRESS REMOVED = > wrote:

> In my organization, I consider date pickers to be a "progressive
> enhancement" and don't even assess them for accessibility, so long as
> the user has the option to use them or ignore them and still specify a
> date.

For precisely the reasons Jonathan suggested, such as knowing what day of
the week some date three months in the future will be, or more generally
being able to annotate dates with more information, I suggest that it is
very helpful to consider the accessibility of date pickers.

I also recognise that they are a very common thing that it is very
difficult to make very accessible.

And since I am offline, I can't look at the specific example for another
day or so, but I'd be interested to see.

I'm really hoping that Web Components will help us fix the problem that
input typeÚte failed to solve in HTML5. Figuring out what makes an
accessible date picker, and finding a *really* good one, gives us insight
into quite a lot of complex problems.

Challenges for the truly geeky - but which become really important when
talking about how to deal with dates.

1. I was at the world finals of ICPC, a programming competition, for the
last week. There was a big poster outside with a mascot-type figure, and
text that amounted, for me who doesn't read the local language's alphabet,
to

17-20 *something* 2559

What does it mean, and how is it relevant to the current discussion?

2. We have fairly reliable information - Shakespeare ;) - that Julius
Caesar was killed on the Ides of March, in 44 BC.

When was that exactly?

3. Why was the anniversary of the October Revolution celebreated in
November?

4. When does the month of Ramadan start and end this year?

cheers

Chaals

>

From: Bryan Garaventa
Date: Sat, May 21 2016 2:52AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Hi Chaals,

" Figuring out what makes an accessible date picker, and finding a *really* good one, gives us insight into quite a lot of complex problems."

Please test the following when you have a chance, it would be good to get your opinion on this one.
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm

Best wishes,
Bryan


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Chaals McCathie Nevile
Date: Sun, May 22 2016 2:43AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Hi Bryan,

On Sat, 21 May 2016 08:52:36 -0000, Bryan Garaventa
< = EMAIL ADDRESS REMOVED = > wrote:

> Hi Chaals,
>
> " Figuring out what makes an accessible date picker, and finding a
> *really* good one, gives us insight into quite a lot of complex
> problems."
>
> Please test the following when you have a chance, it would be good to
> get your opinion on this one.
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm

There's a lot to like, obviously. But some things are still really quite
hard.

As an example, I tried to select my birthday - if you want to send me a
card, please ask…. It seemed likely that I could put in a date, by hand,
and although there was no clue about the format I had hoped I would get
something in the right year when I popped up the date picker widget.
Instead it takes dozens of keystrokes, most with a 3-finger combination,
and I have to know the keyboard shortcut - which is unannounced except in
this example page.

The way I first tried to do it, tabbing around and hitting return on the
arrow that shifts years, which is easier than the dance for me to
genereate modified pageDn, shifted my focus from the button I was on -
previous year - back to the date. So that path was going to be hundreds of
keystrokes.

I tried it because I couldn't remember if the shortcut you had for
skipping years was one that already did something else in my normal set up.

Some things that could be improved.

1. Look at the value when you open the picker and see if you can parse it
2. Don't jump focus when the picker is open
3. Use a focusable dropdown that recognises typing for the year, so if I
start typing 156 it offers me the decade of the 1560s to select from.
4. Ditto for month, I guess.

I'd be interested to hear others' thoughts about this. It's really not a
simple topic about a couple of bugs in a piece of code. There are some
really hard issues in here.

cheers

> Best wishes,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>

From: Bryan Garaventa
Date: Sun, May 22 2016 1:51PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Thanks, that does help.

I see what you mean about the date format, though this is challenging because this is totally customizable in the setup, where a developer can literally do whatever they wish, such as "Saturday March 15, 2018", "2017-03-15", "03/15/2017", or anything else, and this can be tied to individual select elements for Month Day and Year, or to an edit field such as this. So writing an algorithm to predict anything a developer wants to do is impossible. That being said though, it is possible to manually set a date within the datepicker JavaScript object, so I can write instructions for doing this with a test page. Also putting a placeholder with the date string format would probably help, so I'll change this later this week.

Regarding the keystrokes, it is true there are a lot, yet this difficulty will be the same for all date pickers out there. I'll look into adding a help icon that can be used to pop these open, which should help.

I'll look into the other observations too, there is likely a way at present to control the datepicker from the edit field now, though I will need to build this from scratch. Even if I do this though, users still will not automatically know what all of the keystrokes are accept through trial and error, the same as all such datepickers out there.

FYI, you can scan through the years by holding down Alt+PageUp or Alt+PageDown.


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Mike Barlow
Date: Sun, May 22 2016 2:41PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Bryan, nice looking Date Picker but one thing I would probably do would be
to add a couple of other keyboard shortcuts and enhancements:
Alt-Y - Puts you into a "Year" field where the year is displayed and allow
you to enter a specific year (for example if I have to "Alt-PageDown" from
2016 to 1950 that's a lot of keystrokes
Alt-M - Same for a "Month" field.

And is there any "standard" way (other than simply putting the instructions
on the page) to inform a user what the keyboard shortcuts are for a
particular custom widget like this?

*Mike Barlow*
Web Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.835-7557
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

On Sun, May 22, 2016 at 3:51 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> Thanks, that does help.
>
> I see what you mean about the date format, though this is challenging
> because this is totally customizable in the setup, where a developer can
> literally do whatever they wish, such as "Saturday March 15, 2018",
> "2017-03-15", "03/15/2017", or anything else, and this can be tied to
> individual select elements for Month Day and Year, or to an edit field such
> as this. So writing an algorithm to predict anything a developer wants to
> do is impossible. That being said though, it is possible to manually set a
> date within the datepicker JavaScript object, so I can write instructions
> for doing this with a test page. Also putting a placeholder with the date
> string format would probably help, so I'll change this later this week.
>
> Regarding the keystrokes, it is true there are a lot, yet this difficulty
> will be the same for all date pickers out there. I'll look into adding a
> help icon that can be used to pop these open, which should help.
>
> I'll look into the other observations too, there is likely a way at
> present to control the datepicker from the edit field now, though I will
> need to build this from scratch. Even if I do this though, users still
> will not automatically know what all of the keystrokes are accept through
> trial and error, the same as all such datepickers out there.
>
> FYI, you can scan through the years by holding down Alt+PageUp or
> Alt+PageDown.
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>

From: Mike Barlow
Date: Sun, May 22 2016 2:55PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Bryan - Although, after my previous posting on this topic, I notice that
there is an "aria-practices" document that has the "recommended(?)"
keyboard interaction for a Date Picker Widget that was put up by the W3C -
https://www.w3.org/WAI/PF/aria-practices/#datepicker (though I still
maintain that Alt-Y and Alt-M could be used to allow a user to edit the
month/year of a date)

*Mike Barlow*
Web Application Developer
Web Accessibility/Section 508 SME

Lancaster, Pa 17601
Office: 732.835-7557
Cell: 732.682.8226
e-mail: = EMAIL ADDRESS REMOVED =

On Sun, May 22, 2016 at 4:41 PM, Mike Barlow < = EMAIL ADDRESS REMOVED = > wrote:

> Bryan, nice looking Date Picker but one thing I would probably do would be
> to add a couple of other keyboard shortcuts and enhancements:
> Alt-Y - Puts you into a "Year" field where the year is displayed and allow
> you to enter a specific year (for example if I have to "Alt-PageDown" from
> 2016 to 1950 that's a lot of keystrokes
> Alt-M - Same for a "Month" field.
>
> And is there any "standard" way (other than simply putting the
> instructions on the page) to inform a user what the keyboard shortcuts are
> for a particular custom widget like this?
>
> *Mike Barlow*
> Web Application Developer
> Web Accessibility/Section 508 SME
>
> Lancaster, Pa 17601
> Office: 732.835-7557
> Cell: 732.682.8226
> e-mail: = EMAIL ADDRESS REMOVED =
>
> On Sun, May 22, 2016 at 3:51 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Thanks, that does help.
>>
>> I see what you mean about the date format, though this is challenging
>> because this is totally customizable in the setup, where a developer can
>> literally do whatever they wish, such as "Saturday March 15, 2018",
>> "2017-03-15", "03/15/2017", or anything else, and this can be tied to
>> individual select elements for Month Day and Year, or to an edit field such
>> as this. So writing an algorithm to predict anything a developer wants to
>> do is impossible. That being said though, it is possible to manually set a
>> date within the datepicker JavaScript object, so I can write instructions
>> for doing this with a test page. Also putting a placeholder with the date
>> string format would probably help, so I'll change this later this week.
>>
>> Regarding the keystrokes, it is true there are a lot, yet this difficulty
>> will be the same for all date pickers out there. I'll look into adding a
>> help icon that can be used to pop these open, which should help.
>>
>> I'll look into the other observations too, there is likely a way at
>> present to control the datepicker from the edit field now, though I will
>> need to build this from scratch. Even if I do this though, users still
>> will not automatically know what all of the keystrokes are accept through
>> trial and error, the same as all such datepickers out there.
>>
>> FYI, you can scan through the years by holding down Alt+PageUp or
>> Alt+PageDown.
>>
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> = EMAIL ADDRESS REMOVED =
>> 415.624.2709 (o)
>> www.SSBBartGroup.com
>>
>>

From: Bryan Garaventa
Date: Sun, May 22 2016 11:50PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

Thanks, I'll look into these suggestions as well.

It is important to note here however that all of the things we have been talking about, as well as the comments from Chaals, are in regard to usability modifications, not accessibility. This datepicker is already accessible, which follows the paradigms of correct focus movement to ensure keyboard accessibility, plus role and labelling for correct textual equivalents, plus the use of ARIA to ensure the correct browse modality for screen reader users when activated.

Specifically there is a dedicated focusable triggering element, when activated focus moves into the datepicker grid, at which point the arrow keys plus Home and End can be pressed to move between dates, the PageUp and PageDown keys can be used to move by month, and Alt+PageUp and Alt+PageDown can be used to navigate by year. Enter can be pressed to save the date, or Escape or Tab can be pressed to close the datepicker, at which point focus is set back to the triggering element.

It is not actually necessary to press and release every keystroke to scroll the datepicker for every increment, so in your example to navigate to 1950, you can simply press Alt+PageDown and hold these keys down to scroll the datepicker to the correct date. I just tried this in Firefox and it took about 5 seconds. The same is true for all of the other keystrokes, for instance you can press and hold the Down or Up arrow keys to scroll by week across many months at a time, or the PageUp or PageDown keys to do the same by month. This occurs because as you hold these keys down, the assigned functions for navigation fire repeatedly.

This too is accessible on touch screen devices by tapping the datepicker button to open the date picker and tapping the desired date to save, or the date picker can be closed by tapping on any static text outside of the datepicker to cancel and close it.

"And is there any "standard" way (other than simply putting the instructions on the page) to inform a user what the keyboard shortcuts are for a particular custom widget like this?"

We are currently working on a way of doing this using ARIA for standard controls via the aria-keyshortcuts attribute
http://www.w3.org/TR/wai-aria-1.1/#aria-kbdshortcuts
(aria-kbdshortcuts will be changed to aria-keyshortcuts for better understandability in the future)

However something like this probably would not be much good for a datepicker, because if all possible shortcuts are set on all focusable dates, they would be announced every time focus is moved in the datepicker, which would be overkill and quite annoying, and they would still not be perceivable by sighted keyboard only users.

The simplest and most effective way to do this is to put a focusable questionmark help icon with a role of link or button plus aria-expanded next to the Datepicker icon, so that a user can tab to one then the other to activate it, which would pop open an overlay that shows all of the possible key conbinations. Here is an example of a popup that works like this:
http://whatsock.com/tsg/Coding%20Arena/Popups/Popup%20(Internal%20Content)/demo.htm


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Bryan Garaventa
Date: Sun, May 22 2016 11:57PM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | Next message →

That's true, though it's important for everybody to keep in mind that we are in the process of rewriting the APG as version 1.1, which is meant to replace the 1.0 draft that was never truly finished, viewable at
http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/

For example, we still need to review the Datepicker section at
http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#h-datepicker
Which we have not gotten to as yet.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Mike Barlow
Date: Mon, May 23 2016 5:12AM
Subject: Re: Accessible Datepicker & NVDA Support
← Previous message | No next message

Thanks Bryan, all good to know.
On May 23, 2016 1:58 AM, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
wrote:

> That's true, though it's important for everybody to keep in mind that we
> are in the process of rewriting the APG as version 1.1, which is meant to
> replace the 1.0 draft that was never truly finished, viewable at
> http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/
>
> For example, we still need to review the Datepicker section at
> http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#h-datepicker
> Which we have not gotten to as yet.
>
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
>