WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Data table, forms vs content mode

for

From: escetic@gmail.com
Date: Oct 31, 2017 12:30PM

Léonie, thank you for confirming this seems to be an NVDA specific issue. I will raise a ticket with them and see what they say. Meanwhile, your train of thought led me to a bandaid solution of having hidden text asking the user to press escape to exit forms mode. It's ugly but I'd rather the user be able to navigate the table properly.

Birkir, this is a good question. I think the tabindex was legacy code, the table cells aren't intended to be interactive although there are links in some <th>'s and just outside the table which take the user to an overlay. Indeed, the tabindex may be interfering with the operation of the links, now that I think of it.

Kelly, yes, there is a product selection overlay with 4 slots, the user adds/removes products, then clicks "compare" which takes them to the underlying page with the comparison results table. We're using Javascript .focus to allow the user to easily switch between overlay and comparison table.

The nature of the table data is such that it's critical to be able to use arrows or a nonvisual user will seriously miss the comparison context, there is a lot of info and the table cells are even aligned with the product comparison overlay, so a nonvisual user needs to always know which product is in the scope of the column. Otherwise they're forced to memorize a huge amount of info which is not feasible.

Thank you for these questions and answers, this is extremely helpful.

Rob C


Sent from my iPad

> On Oct 30, 2017, at 9:09 PM, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
>
> Why are all the elements in the table focusable?
> Does activating them with the keyboard (or clicking them with the
> mouse) do something?
>
>
>
>> On 10/30/17, KellyFord < <EMAIL REMOVED> > wrote:
>> Can you expand on this paragraph:
>>
>> The link invokes the javascript getsElementByID and places focus accordingly
>> because we must move between this table and an overlay, which is removed
>> here for clarity.
>>
>> What do you mean by move between thee two items? Are you expecting that
>> focus moves outside the table to some overlay?
>>
>> Kelly
>>
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of Léonie Watson
>> Sent: Monday, October 30, 2017 2:35 PM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >; <EMAIL REMOVED>
>> Subject: Re: [WebAIM] Data table, forms vs content mode
>>
>>
>>> On 30/10/2017 18:39, <EMAIL REMOVED> wrote:
>>>
>>> Using NVDA and IE, Chrome and FF I'm able to arrow correctly through this
>>> table (code below), in other words move between the individual cells with
>>> ctrl-alt-arrow.
>>>
>>> But if I press the link, it places focus within the table but puts us into
>>> forms mode (which I don't think is announced). The user thus finds
>>> themselves in a table but unable to move around with the usual
>>> ctl-alt-arrows, which I think is unexpected. Also, the user won't know to
>>> ESC, since I don't think they hear they're in forms mode.
>>
>> I can confirm this behaviour in NVDA. The usual "clunk" audio cue is given
>> when NVDA switches into forms mode, but I agree that the lack of
>> navigability is unexpected (not to mention inconvenient).
>>>
>>> The link invokes the javascript getsElementByID and places focus
>>> accordingly because we must move between this table and an overlay, which
>>> is removed here for clarity.
>>>
>>
>> It seems to be something NVDA is doing in response to having keyboard
>> focused moved using .focus(). The problem doesn't happen if you use the tab
>> key to move focus to the table or one of its headers, it only happens when
>> the JavaScript link is used.
>>
>> Changing the tabindex on the target header to tabindex="-1" doesn't make
>> any difference, nor does stripping out all other instances of the tabindex
>> attribute.
>>
>> The problem exists with NVDA in FF, Chrome, and IE. It isn't exhibited by
>> Jaws in any of those browsers, which suggests the issue may not be with
>> either the browser or the JavaScript.
>>
>>> In forms mode, ctl-alt-arrow behavior on a table seems suspended.
>>
>> Yes it is. This is because in forms mode the screen reader passes all
>> navigation back to the browser (so only basic keyboard commands like tab,
>> enter, space, and up/down/left/right arrows are available).
>>
>>>
>>> Any thoughts or solutions? I would fail this on 1.3.1. The dev says
>>> this is about 2.1.1 and since 2.1.1 says keyboard-only but doesn't specify
>>> key combinations, merely being able to tab through the table should be
>>> sufficient. I don't think the user will even know to tab here.
>>>
>>
>> I agree that tabbing through a table is unlikely to occur to screen reader
>> users. It can also be argued that making non-interactive content tabbable is
>> rarely a good thing. It requires keyboard users who don't use a screen
>> reader to tab a lot to get through/past the table.
>>
>> Léonie.
>>
>> >> >> http://webaim.org/discussion/archives
>> >>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > >