WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Data table, forms vs content mode

for

From: KellyFord
Date: Oct 30, 2017 6:41PM

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.