WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Data table, forms vs content mode

for

From: Date: Oct 30, 2017 1:35PM

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.