E-mail List Archives
Thread: Acessibility of a date picker?
Number of posts in this thread: 4 (In chronological order)
From: Sonja Weckenmann
Date: Thu, May 26 2016 3:02AM
Subject: Acessibility of a date picker?
No previous message | Next message →
Hello,
I'm evaluating a german airport-website. There are problems with the
date picker.
http://www.dortmund-airport.de/flugplan
I think keybord navigation is quite good when not using a screenreader.
When using NVDA/FF or JAWS/IE keybord navigation doesn't work:
- Navigation with up arrow and down arrow doesn't work.
- It isn't possible to activate the buttons for changing the month and
the two buttons "SchlieÃen" and "Löschen".
- I'm not quite sure, but I think it is also not easy to get the month
spoken with the screenreader?
- The date of each cell has an aria-label="27.05.2016" but it is not
spoken by the screenreader. I dont't know why.
Similar problems occur when trying to select the departure time for example.
Does anybody know whether it is a question of incorrect implementation
of ARIA or is it a scripting problem?
Why does keybord navigation work without screenreader and when using
screenreader it is bad?
Thanks a lot
sonja
--
Sonja Weckenmann
BIK für Alle
BITV-Test
c/o DIAS GmbH
Schulterblatt 36 / 20357 Hamburg
Telefon 040 43 18 75 18
Fax 040 43 18 75 19
www.bik-fuer-alle.de
www.bitvtest.de
From: Birkir R. Gunnarsson
Date: Thu, May 26 2016 4:11AM
Subject: Re: Acessibility of a date picker?
← Previous message | Next message →
Ach! Donnerwetter!
ARIA is not used properly.
The table with role="grid" has aria-readonly="true" which is probably
what is preventing screen readers from going into forms mode.
It uses aria-activedescendant to manage focus, I'd have to see the
JavaScript to determine whether the id target for that attribute is
being correctly updated as user presses the arrow keys (the ID should
be updated to point to the active cell in the grid as the user
navigates within it).
But I see a warning sign that the grid itself is not in focus order,
which is necessary for aria-activedescdnant to work, see:
http://www.w3.org/TR/wai-aria/states_and_properties#aria-activedescendant
The divs turn buttons you mention need to have both an onclick event
as well as an onkeypress listening for the appropriate keys (13 for
enter, 32 for spacebar).
This one will need some ARIA TLC.
On 5/26/16, Sonja Weckenmann < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> I'm evaluating a german airport-website. There are problems with the
> date picker.
>
> http://www.dortmund-airport.de/flugplan
>
> I think keybord navigation is quite good when not using a screenreader.
> When using NVDA/FF or JAWS/IE keybord navigation doesn't work:
>
> - Navigation with up arrow and down arrow doesn't work.
> - It isn't possible to activate the buttons for changing the month and
> the two buttons "SchlieÃen" and "Löschen".
> - I'm not quite sure, but I think it is also not easy to get the month
> spoken with the screenreader?
> - The date of each cell has an aria-label="27.05.2016" but it is not
> spoken by the screenreader. I dont't know why.
>
> Similar problems occur when trying to select the departure time for example.
>
> Does anybody know whether it is a question of incorrect implementation
> of ARIA or is it a scripting problem?
> Why does keybord navigation work without screenreader and when using
> screenreader it is bad?
>
> Thanks a lot
> sonja
>
> --
> Sonja Weckenmann
> BIK für Alle
> BITV-Test
>
> c/o DIAS GmbH
> Schulterblatt 36 / 20357 Hamburg
>
> Telefon 040 43 18 75 18
> Fax 040 43 18 75 19
>
> www.bik-fuer-alle.de
> www.bitvtest.de
> > > > >
--
Work hard. Have fun. Make history.
From: Jonathan Avila
Date: Thu, May 26 2016 7:55AM
Subject: Re: Acessibility of a date picker?
← Previous message | Next message →
> The table with role="grid" has aria-readonly="true" which is probably what is preventing screen readers from going into forms mode.
One additional thing many accessible date pickers use is the role of application to force Windows screen readers into forms mode. Generally we don't recommend this type of behavior but in some cases it may be needed. From my experience NVDA and Firefox seem to go into forms/focus mode when you focus a grid but as Birkir mentions with JAWS and Firefox JAWS will not go into forms mode when aria-readonly is set to true. If it is not set to true then JAWS will go into forms mode on a grid. So there would appear to be differences between ATs and perhaps browsers as well -- so that may be why in the past people resorted to wrapping the grid with role of application.
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: Birkir R. Gunnarsson
Date: Thu, May 26 2016 7:59AM
Subject: Re: Acessibility of a date picker?
← Previous message | No next message
That is precisely what we did with the Deque calendar widget in fact.
It was developed in late 2014, and it was necessary back then, screen
readers would not consistently go into forms mode.
I did a test more recently, and the grid role caused Jaws and NVDA
with IE and FF to go into application/forms mode, so it appears that
the application role is no longer needed (though it might still be
acceptable for backward compatibility).
And, yeah, it does make some sense that aria-readonly attribute on a
grid prevents Jaws from going into forms mode.
On 5/26/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> The table with role="grid" has aria-readonly="true" which is probably what
>> is preventing screen readers from going into forms mode.
>
> One additional thing many accessible date pickers use is the role of
> application to force Windows screen readers into forms mode. Generally we
> don't recommend this type of behavior but in some cases it may be needed.
> From my experience NVDA and Firefox seem to go into forms/focus mode when
> you focus a grid but as Birkir mentions with JAWS and Firefox JAWS will not
> go into forms mode when aria-readonly is set to true. If it is not set to
> true then JAWS will go into forms mode on a grid. So there would appear to
> be differences between ATs and perhaps browsers as well -- so that may be
> why in the past people resorted to wrapping the grid with role of
> application.
>
> 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!
>
>
>