search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 638 forks source link

Forms mode invoked when placed on table via Javascript #7718

Open escetic opened 7 years ago

escetic commented 7 years ago

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 data 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. The overlay allows for product selection then pressing "Compare", which places focus on the underlying data table for comparison results. Currently we plan to work around this issue by putting hidden text on the table saying "Press escape to exit forms mode" but this is a bandaid solution.

Expected Behaviour: As focus is on a data table element, not an interactive form element, forms mode should not be invoked.

Actual Behaviour: Forms mode is invoked as the focus is placed within the data table, the user does not know they are in forms mode, nor that they need to escape to navigate the table using ctrl-alt-arrow keys.

System configuration: NVDA version: 2016.3 and 2017.3 Windows version: Windows 7 Enterprise Browser versions: Chrome, FF, IE, Edge Note: We also tested on JAWS. This is not reproducible with JAWS, which seems to have implemented this differently.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Table Test</title>
    <script>
        function a(){
            document.getElementById("header1").focus();
        }
    </script>
</head>
<body>
    <h1>Table Test</h1>
    <p><a href="javascript:a()">test link</a></p>
    <table>
        <thead>
            <tr>
                <td ></td>
                <th scope="col" id="header1">Header 1</th>
                <th scope="col">Header 2</th>
                <th scope="col">Header 3</th>
                <th scope="col">Header 4</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <th scope="row">Row Header 1</th>
                <td >Content 1 1</td>
                <td >Content 2 1</td>
                <td >Content 3 1</td>
                <td >Content 4 1</td>
            </tr>
            <tr>
                <th scope="row">Row Header 2</th>
                <td >Content 1 2</td>
                <td >Content 2 2</td>
                <td >Content 3 2</td>
                <td >Content 4 2</td>
            </tr>
        </tbody>
    </table>
 </body>
</html>
LeonarddeR commented 7 years ago

Could you test this with disabled nvda browse mode preferences > Automatic focus mode for focus changes?

RichCaloggero commented 7 years ago

I tried this code with latest NVDA 2017.3.

With "automatic focus mode for focus changes" enabled, the "entering focus mode" sound is indeed played; when you turn it off, the sound is not played. In both cases, focus mode (forms mode) is turned on. I agree with the poster: this seems unexpected.

If you instead set focus to a cell inside the tbody tag, forms mode is not entered when "automatic focus mode for focus changes" is disabled. This is one possible fix, although I believe this is set by default, and many users may not know about this setting.

If you instead make the contents of the cell a focussable item (either natively such as a link, or via tabindex="-1"), then forms mode is not entered, regardless of the setting of the "automatic focus mode for focus changes" setting.

<th scope="row"><span id="header1" tabindex="-1">Row Header 1</a></th>

You can also see this behavior if you put tabindex="0" on a table cell and then just tab to it. Focus mode is enabled and sound is played (see above). If you do this for a normal paragraph however, focus mode is not enabled.

Adriani90 commented 5 years ago

@escetic, @RichCaloggero can you please test with NVDA 2018.4.1? Is this issue still reproducible? I have tested in Firefox 64.0.2, Chrome 71, IE11 and Edge and I cannot reproduce it.

RichCaloggero commented 5 years ago

This is still an issue. The reason it is not seen on the above code is because the function invoked by the link refers to an ID that doesn't exist.

The following code will exhibit the problem. Activating the first test link will jump focus to a th cell whose ID is "header1"; this cell has a tabindex="-1" which makes the cell itself focusable.

Activating the second test link jumps focus to the element with ID "header2"; this is a link within a header cell.

In the first case, forms mode is indeed activated; in the second case, forms mode is not activated.

I have "automatic focus mode for focus changes" enabled in NVDA browse mode settings (which is the default). This behavior is consistent with that setting. This insures that when one tabs to an text input element for instance, that forms mode is enabled automatically.

This is a long way of saying that if this behavior is not wanted, then shift focus to a button or a element (a link), rather than a table cell itself. Links and buttons are focusable, but they do not activate forms mode when they gain focus.

Updated Code

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Table Test</title>
    <script>
        function a(_id){
            document.getElementById(_id).focus();
        }
    </script>
</head>
<body>
    <h1>Table Test</h1>
    <p><a href="javascript:a('header1')">test 1 link</a></p>
    <p><a href="javascript:a('header2')">test 2 link</a></p>
    <table>
        <thead>
            <tr>
                <td ></td>
                <th scope="col" id="header1" tabindex="-1">Header 1</th>
                <th scope="col"><a id="header2" href="#">Header 2</a></th>
                <th scope="col">Header 3</th>
                <th scope="col">Header 4</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <th scope="row">Row Header 1</th>
                <td >Content 1 1</td>
                <td >Content 2 1</td>
                <td >Content 3 1</td>
                <td >Content 4 1</td>
            </tr>
            <tr>
                <th scope="row">Row Header 2</th>
                <td >Content 1 2</td>
                <td >Content 2 2</td>
                <td >Content 3 2</td>
                <td >Content 4 2</td>
            </tr>
        </tbody>
    </table>
 </body>
</html>
Adriani90 commented 5 years ago

cc: @jcsteh, @michaelDCurran

Adriani90 commented 5 years ago

Thanks @RichCaloggero for this update.

jcsteh commented 5 years ago

This occurs because NVDA treats focusable tables/rows/cells as interactive; i.e. they are expected to support their own keyboard navigation. This was done in order to support ARIA grids.

The question is whether it's appropriate to treat focusable table cells as "gridcells". On one hand, it wasn't explicitly marked with role="gridcell", so it's not a gridcell. On the other hand, if it's truly a data table, its cells arguably shouldn't be focusable; focusability suggests interactivity.

If we did want to differentiate, we can use the ARIA role. I'm not a fan of doing stuff specific to ARIA roles (really, this should be defined by the a11y API role). That said, we already use ARIA roles for dialog vs alertdialog, etc.

Adriani90 commented 4 months ago

Would it not be a solution to allow ctrl+alt+arrow keys to work also in focus mode? This does already work for lists in desktop apps where browse mode is not supported at all, Windows explorer for example. I wonder whether NVDA can extend ctrl+alt+arrow key script to work also in this focusable table cells example?

Alternatively, If I am not wrong, the web author can define ctrl+alt+arrow keys as commands to move the focus through the cells of a table if they are focusable. Ofcourse we end up with two ways of doing the same thing, but at least the muscle memory of users would be considered.