WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Data table, forms vs content mode

for

From: Birkir R. Gunnarsson
Date: Oct 30, 2017 7:09PM

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.