NVDA acting differently with regard to a web table when viewing same page in Firefox vs. Chromium-based browsers

[britechguy]

Steps to reproduce: Open webpage https://nvda.groups.io/g/nvda/search?q=vocalizer in Firefox, then in a Chromium based browser (I've used MS-Edge and Brave and Chrome, and the behavior is the same in all three). Hit B to land on the first button in the body of the page, followed by T to land on the first table.

Actual behavior: In all Chromium-based browsers, there is a table, and you land in row one, column one, which so happens to be blank, with the real data immediately afterward. It appears these are used as place holders, but the T shortcut always finds a table.

In Firefox, no table is found and NVDA says, "Nonex Table," which I presume is shorthand for non-existent table

Expected behavior: Given that we're dealing with the same webpage in all browsers, I would expect the structure of the page to be identical regardless of browser in use, and that the T quick navigation would find a table. I am not certain whether this is an NVDA bug, a Firefox bug, a Chromium-related bug, or some combination.

System configuration

NVDA installed/portable/running from source: Installed

NVDA version: 2020.3

Windows version: Win10 20H2, also occurred under 2004

Name and version of other software in use when reproducing the issue: Most recent versions of all above noted browsers. I keep all constantly updated to their latest versions when these are indicated as being available

Other information about your system: HP 15-ba011cy, 12 GB RAM, 1TB SSD, AMD A12-9700P APU

Other questions

Does the issue still occur after restarting your computer? Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

If addons are disabled, is your problem still occuring?

Did you try to run the COM registry fixing tool in NVDA menu / tools? No

[lukaszgo1]

cc @jcsteh

[jcsteh]

Firefox has heuristics which treat this as a layout table. This is not unreasonable in this case, since the table serves no semantic purpose whatsoever; the first column is entirely blank, so there's no point in having rows and columns at all. Chromium has heuristics for determining layout tables as well, but they're slightly different to Firefox's. If you don't like this, you can enable "Include layout tables" in NVDA's browse mode settings, but note that you'll get a lot of extraneous nonsense if you do.

[britechguy]

The problem being, the exact same webpage is behaving differently under Firefox and Chromium-based web browsers using NVDA.

Your suggestion does nothing to address the underlying inconsistency, which should not exist, period.

I should not have to adjust NVDA settings on a by-browser-I'm-using basis for something like this.

No solution has been achieved, including in the suggested course of action. This issue still requires addressing, as it will certainly not be limited to this specific instance. NVDA should do the same thing, on the same page, regardless of the browser in which a given page is open.

I don't really care if "the Firefox behavior" is carried over to Chromium-based browsers, or vice-versa, but this is not something that should ever be presented to an end-user for workaround. The web page should behave exactly the same way regardless of browser used.

[jcsteh]

In areas like these where guesswork heuristics are used, there is always going to be some inconsistency because guesswork heuristics are inherently not standardised across browsers. They're provided to help the user where possible. If you want to argue that full consistency and standards compliance should always be the goal, all tables should technically be treated as tables, in which case you should enable inclusion of layout tables, after which you will get a fully consistent experience.

I guess NVDA could do its own layout table detection and not rely on the browser, but that would be up to the NVDA core developers, of which I am not one. I will reopen this on that basis and let them triage.

[britechguy]

Thank you.

I understand what you're saying, including the part about potential for inconsistency, but feel this is not an instance where there should be one.

There is just no way that any typical user is going to understand why there is a huge difference between how NVDA interacts with the same page in different browsers. And I can't figure out why, if both browsers actually give NVDA the information that there is a layout table, that NVDA does not act consistently based upon that information. Of course, both browsers may not be, but an end user wouldn't know that, either.

[jcsteh]

To clarify (I guess this wasn't clear), figuring out whether something is a layout table is guesswork if the web author doesn't explicitly specify (which 99% of the time they don't). Different browsers have different heuristics for making that guess; as I said, it's a guess, so it can't be standardised. Technically, standardisation would dictate that this guesswork shouldn't exist at all, but pragmatically, this hurts users more than it helps them. The author could also fix this by explicitly specifying that this is a data table (or a layout table, whichever they believe to be true).

[Adriani90]

The design of the website changed and the table seems accessible now both in Firefox and Chromium browsers. Closing as works for me. if you are still having this issue, please comment and we can reopen.

[BabyElias]

Hey, can someone let me know about what changes needed to be done in the table to be accessible in firefox as well? Facing the same issue.

[Adriani90]

Please provide a minimal test case, otherwise it is difficult to give any competent advice.

[BabyElias]

@Adriani90 , This is how the table is read in Chrome, without any issues. With all contents within the table properly read out.

This is how the table reads like in firefox. The contents of the table are not read out by NVDA and there's an unnecessary 'Not selected' attribute coming from no idea where.

[Adriani90]

Here are alot of blind developers., so please describe your screenshots.By minimal test case I mean a html or any code snippet for this table. You can create one on codepen for example.Von meinem iPhone gesendetAm 10.07.2024 um 08:07 schrieb Anoushka Jha ***@***.***>: This is how the table is read in Chrome, without any issues. With all contents within the table properly read out. image.png (view on web) This is how the table reads like in firefox. The contents of the table are not read out by NVDA and there's an unnecessary 'Not selected' attribute coming from no idea where. image.png (view on web) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[BabyElias]

Didn't have an idea about that.
The code sample can be found here : https://github.com/BabyElias/kolibri-design-system/blob/gsoc-table/lib/KTable/index.vue
and the tables can be viewed at this link : https://deploy-preview-669--kolibri-design-system.netlify.app/playground/
The problem as mentioned in the screenshots is,
With Chrome browser, the screen reader output is perfect. It highlights the cell contents when placed over the cell. But with firefox browser, it announces "not selected row x column y column header" and not the actual cell content. The 'not selected' text is also very ambiguous since there is no such code-piece that has a checked attribute in the table.

[Adriani90]

@BabyElias your issue seems rather a duplicate of #12997. I will post the link there as well.