WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility of a date picker?

for

From: Birkir R. Gunnarsson
Date: May 26, 2016 11:20AM

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 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 REMOVED>
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Thursday, May 26, 2016 7:00 AM
> To: WebAIM Discussion List < <EMAIL 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 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 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 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 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.