E-mail List Archives
Thread: Data table, forms vs content mode
Number of posts in this thread: 6 (In chronological order)
From: escetic
Date: Mon, Oct 30 2017 12:39PM
Subject: Data table, forms vs content mode
No previous message | Next message →
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.
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.
In forms mode, ctl-alt-arrow behavior on a table seems suspended.
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.
Thanks in advance!
Rob C
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="widthÞvice-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ieÃge" />
<title>Table Test</title>
<script>
function a() {
document.getElementById("header1").focus();
}
</script>
<body>
<h1>Table Test</h1>
<p><a href="javascript:a()">test link</a></p>
<table tabindex="0">
<thead>
<tr>
<td tabindex="0"></td>
<th tabindex="0" scope="col" id="header 1">Header 1</th>
<th tabindex="0" scope="col">Header 2</th>
<th tabindex="0" scope="col">Header 3</th>
<th tabindex="0" scope="col">Header 4</th>
</tr>
</thead>
<tbody>
<tr>
<th tabindex="0" scope="row">Row header 1</th>
<td tabindex="0">Content 1 1</td>
<td tabindex="0">Content 2 1</td>
<td tabindex="0">Content 3 1</td>
<td tabindex="0">Content 4 1</td>
</tr>
<tr>
<th tabindex="0" scope="row">Row header 1</th>
<td tabindex="0">Content 1 2</td>
<td tabindex="0">Content 2 2</td>
<td tabindex="0">Content 3 2</td>
<td tabindex="0">Content 4 2</td>
</tr>
</tbody>
</table>
</body>
</html>
From:
Subject: Re: Data table, forms vs content mode
← Previous message | Next message →
On 30/10/2017 18:39, = EMAIL ADDRESS 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.
From: KellyFord
Date: Mon, Oct 30 2017 6:41PM
Subject: Re: Data table, forms vs content mode
← Previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Mon, Oct 30 2017 7:09PM
Subject: Re: Data table, forms vs content mode
← Previous message | Next message →
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 ADDRESS 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
>
>
>
>
From: Brandon Keith Biggs
Date: Tue, Oct 31 2017 4:12AM
Subject: Re: Data table, forms vs content mode
← Previous message | Next message →
Hello,
This is probably a bug in NVDA. NVDA should make the chirp for entering in
edit mode.
This is also an UX problem. No blind person would ever want to tab through
a table (yes, screen reader users have a user experience). There should be
WCAG for sighted users, then devs like this can see what a different
interpretations of a standard without UX can feel like.
Table cells don't have tabindex by default and there is a reason for this.
Thanks,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
On Mon, Oct 30, 2017 at 6:09 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS 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 ADDRESS 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
> >
> >
> >
> >
From: escetic
Date: Tue, Oct 31 2017 12:30PM
Subject: Re: Data table, forms vs content mode
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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
>>
>>
>>
>>