E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Accessibility of a date picker?

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

From: Moore,Michael (Accessibility) (HHSC)
Date: Thu, May 26 2016 7:41AM
Subject: Accessibility of a date picker?
No previous message | Next message →

Deque has a very good example of how to properly implement a date picker.

https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, May 26, 2016 5:12 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Acessibility of a date picker?

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

--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Thu, May 26 2016 9:12AM
Subject: Re: Accessibility of a date picker?
← Previous message | Next message →

Actually the behavior that aria-readonly="true" on a grid as not going into Forms Mode is a screen reader bug.

A grid is an interactive construct according to the spec, regardless whether it is readonly or not, and it is meant to be interacted with using the keyboard.

If the intent is to build a data table instead, then the developer should be using role=table and it's associated roles in accordance with the table mappings at
http://whatsock.com/training/matrices/#table
This is why the table role was added to the spec, to provide an accessible construct for non-interactive tables.

Since aria-readonly is supported on role="gridcell, role=columnheader, and role=rowheader cells for example, you could easily have a table where some cells marked as column or row header cells are meant to be readonly but others are not, and if you are not allowed to enter Forms Mode on some but not others or if Forms Mode gets booted out when you arrow to a readonly cell, it will impair intuitive navigation.

Please file this behavior as a bug if you notice this happening.

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

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, May 26, 2016 7:00 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Acessibility of a date picker?

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!
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Thursday, May 26, 2016 6:12 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Acessibility of a date picker?
>
> 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-activedescend
> ant
>
> 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
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >

--
Work hard. Have fun. Make history.

From: Birkir R. Gunnarsson
Date: Thu, May 26 2016 11:20AM
Subject: Re: Accessibility of a date picker?
← Previous message | Next message →

True.
But the table role is new and, in my most recent testing, is not
supported anywhere (well, IE/FF with Jaws/NVDA).
I have had to recommend building a read-only grid once or twice where
there was no way of implementing an HTML table.
That being said, I totally agree with you Bryan, that a grid is an
interactice construct and should cause a.t. to go into forms mode.
Unfortuantely the is a discontted in that the ARIA spec makes no user
agent recommendation for different roles.
I know people are working on supporting documentation to address this
gp, though I am not well versed in the details. But I know it is
needed.
-B

On 5/26/16, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Actually the behavior that aria-readonly="true" on a grid as not going into
> Forms Mode is a screen reader bug.
>
> A grid is an interactive construct according to the spec, regardless whether
> it is readonly or not, and it is meant to be interacted with using the
> keyboard.
>
> If the intent is to build a data table instead, then the developer should be
> using role=table and it's associated roles in accordance with the table
> mappings at
> http://whatsock.com/training/matrices/#table
> This is why the table role was added to the spec, to provide an accessible
> construct for non-interactive tables.
>
> Since aria-readonly is supported on role="gridcell, role=columnheader, and
> role=rowheader cells for example, you could easily have a table where some
> cells marked as column or row header cells are meant to be readonly but
> others are not, and if you are not allowed to enter Forms Mode on some but
> not others or if Forms Mode gets booted out when you arrow to a readonly
> cell, it will impair intuitive navigation.
>
> Please file this behavior as a bug if you notice this happening.
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Thursday, May 26, 2016 7:00 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Acessibility of a date picker?
>
> 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!
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Thursday, May 26, 2016 6:12 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Acessibility of a date picker?
>>
>> 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-activedescend
>> ant
>>
>> 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
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > >

--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Thu, May 26 2016 11:53AM
Subject: Re: Accessibility of a date picker?
← Previous message | Next message →

In recent tests, role=table is now supported in IE11 using JAWS17 plus in Firefox and Chrome, plus in NVDA in Chrome. This should also now work in Safari via webkit.

The only variable that still needs to be worked out by JAWS and NVDA is the proper support of aria-owns as reflected in the accessibility tree, or in the case of IE11 as the attribute is meant to be used with multiple ID refs and how this affects the reading order.

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

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, May 26, 2016 10:20 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility of a date picker?

True.
But the table role is new and, in my most recent testing, is not supported anywhere (well, IE/FF with Jaws/NVDA).
I have had to recommend building a read-only grid once or twice where there was no way of implementing an HTML table.
That being said, I totally agree with you Bryan, that a grid is an interactice construct and should cause a.t. to go into forms mode.
Unfortuantely the is a discontted in that the ARIA spec makes no user agent recommendation for different roles.
I know people are working on supporting documentation to address this gp, though I am not well versed in the details. But I know it is needed.
-B

On 5/26/16, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Actually the behavior that aria-readonly="true" on a grid as not going
> into Forms Mode is a screen reader bug.
>
> A grid is an interactive construct according to the spec, regardless
> whether it is readonly or not, and it is meant to be interacted with
> using the keyboard.
>
> If the intent is to build a data table instead, then the developer
> should be using role=table and it's associated roles in accordance
> with the table mappings at
> http://whatsock.com/training/matrices/#table
> This is why the table role was added to the spec, to provide an
> accessible construct for non-interactive tables.
>
> Since aria-readonly is supported on role="gridcell, role=columnheader,
> and role=rowheader cells for example, you could easily have a table
> where some cells marked as column or row header cells are meant to be
> readonly but others are not, and if you are not allowed to enter Forms
> Mode on some but not others or if Forms Mode gets booted out when you
> arrow to a readonly cell, it will impair intuitive navigation.
>
> Please file this behavior as a bug if you notice this happening.
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Thursday, May 26, 2016 7:00 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Acessibility of a date picker?
>
> 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!
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Thursday, May 26, 2016 6:12 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Acessibility of a date picker?
>>
>> 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-activedescen
>> d
>> ant
>>
>> 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
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >

--
Work hard. Have fun. Make history.

From: Birkir R. Gunnarsson
Date: Thu, May 26 2016 3:15PM
Subject: Re: Accessibility of a date picker?
← Previous message | No next message

Whoops, I guess it is time to upgrade my Jaws to 17 *grin*.
Thanks for the info.

On 5/26/16, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> In recent tests, role=table is now supported in IE11 using JAWS17 plus in
> Firefox and Chrome, plus in NVDA in Chrome. This should also now work in
> Safari via webkit.
>
> The only variable that still needs to be worked out by JAWS and NVDA is the
> proper support of aria-owns as reflected in the accessibility tree, or in
> the case of IE11 as the attribute is meant to be used with multiple ID refs
> and how this affects the reading order.
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Thursday, May 26, 2016 10:20 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility of a date picker?
>
> True.
> But the table role is new and, in my most recent testing, is not supported
> anywhere (well, IE/FF with Jaws/NVDA).
> I have had to recommend building a read-only grid once or twice where there
> was no way of implementing an HTML table.
> That being said, I totally agree with you Bryan, that a grid is an
> interactice construct and should cause a.t. to go into forms mode.
> Unfortuantely the is a discontted in that the ARIA spec makes no user agent
> recommendation for different roles.
> I know people are working on supporting documentation to address this gp,
> though I am not well versed in the details. But I know it is needed.
> -B
>
>
> On 5/26/16, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>> Actually the behavior that aria-readonly="true" on a grid as not going
>> into Forms Mode is a screen reader bug.
>>
>> A grid is an interactive construct according to the spec, regardless
>> whether it is readonly or not, and it is meant to be interacted with
>> using the keyboard.
>>
>> If the intent is to build a data table instead, then the developer
>> should be using role=table and it's associated roles in accordance
>> with the table mappings at
>> http://whatsock.com/training/matrices/#table
>> This is why the table role was added to the spec, to provide an
>> accessible construct for non-interactive tables.
>>
>> Since aria-readonly is supported on role="gridcell, role=columnheader,
>> and role=rowheader cells for example, you could easily have a table
>> where some cells marked as column or row header cells are meant to be
>> readonly but others are not, and if you are not allowed to enter Forms
>> Mode on some but not others or if Forms Mode gets booted out when you
>> arrow to a readonly cell, it will impair intuitive navigation.
>>
>> Please file this behavior as a bug if you notice this happening.
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> = EMAIL ADDRESS REMOVED =
>> 415.624.2709 (o)
>> www.SSBBartGroup.com
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Thursday, May 26, 2016 7:00 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Acessibility of a date picker?
>>
>> 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!
>>>
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> Behalf Of Birkir R. Gunnarsson
>>> Sent: Thursday, May 26, 2016 6:12 AM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Acessibility of a date picker?
>>>
>>> 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-activedescen
>>> d
>>> ant
>>>
>>> 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
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > >

--
Work hard. Have fun. Make history.