NVDA cannot navigate a checkBox element with a width or height of 0 on the page in Chrome

[cary-rowen]

demo.txt
and as a codepen: https://codepen.io/reefturner/full/XWMZoeX

Steps to reproduce:

1. Download the demo.txt provided;
2. After downloading, change its extension to .html to demo.html;
3. Open in chrome;
4. Try to use the up and down arrows or Tab keys to navigate the page.

Actual behavior:

1. Press Tab key or up/down arrow can only navigate to "Submit" button
2. Use the navigation object to navigate to the checkBox but cannot interact with it.
3. Open demo.html in FireFox and everything is normal

Expected behavior:

Users navigate between checkBoxes, NVDA can read out the necessary information such as "C / C++, Python" just like in FireFox.

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

NVDA alpha-22975

Windows version:

Windows 10 21H1 (64位) build 19043.985

Name and version of other software in use when reproducing the issue:

Google Chrome 91.XX

Other information about your system:

None

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.

NVDA 2020.4 is the same,
But Narrator does not have such a problem.

If add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[feerrenrut]

If an element is has width or height of 0 it is not visible. Non-visible elements are typically made that way intentionally to omit them from the visual UI. It is intentional that NVDA does not report elements that have been intentionally omitted from the UI. I believe certain browsers don't even expose them via the accessibility APIs.

I'm going to close this issue. This may be part of a more elaborate example, if so please share more details and we'll consider looking at it further.

[cary-rowen]

Hi

I don’t understand why the behavior in FireFox and Chrome is so different, and why NVDA behaves differently from other screen readers? If NVDA is doing this deliberately, then the same behavior should be maintained in FireFox.
In addition, it cannot be ruled out that some default styles are hidden because of visual considerations. They may not meet the Accessibility specification, but without other obvious side effects, I still think that screen readers should provide users with an actionable way.

Thanks!
@feerrenrut

[feerrenrut]

It would help if you described the different behavior to confirm we have a shared understanding.

Hidden form controls have historically used widely on the web for holding state related to the form. Users are not meant to interact with these controls, hence they are not visible. Sighted users can't interact with the controls.

[cary-rowen]

Hello, this problem is the actual problem I encountered when filling out a survey form. What can be confirmed is that the CheckBox with a width of 0 can be used with people with normal vision, and it can also interact with NVDA on FireFox. , Narrator can interact with it on Chrome, but NVDA can’t.
The content of the questionnaire is in Chinese, and I do not guarantee that it can be opened in your area, but I am still willing to provide the URL: https://wj.capa.ac/fillin?id=193

[surfer0627]

2. Use the navigation object to navigate to the checkBox but cannot interact with it.

um, I got a similar issue in Firefox, not in Chrome.

Steps to reproduce (page in Chinese):

1. Open
   https://www.taishinbank.com.tw/eService/CreditCardAP/apply/index.jsp?pc=179
2. Press NVDA + ctrl + f to search string "行動生活 "
3. Press enter to expand it.
4. Press down arrow
   speech: Checkbox not check.
5. Press space
   Actual: no response
   Expected: Checkbox is checked.
   checkbox alternative text: 街口卡
   綁定街口APP指定通路：最高6%

note: This case works as expected in Chrome and MS Edge.

Thanks.

[XLTechie]

@surfer0627 is what you experienced similar to #12204?

[surfer0627]

@XLTechie Yes, good catch.
Thanks.

[XLTechie]

Okay, you might want to post your STR there and delete the one here, since I think the issue you and I experienced is not the same as this one. Our various comments can be hidden/deleted so as not to mess with this issue.

[cary-rowen]

I do not approve of closing this issue, and I would like to hear more people’s thoughts. I believe it is a very common situation for such CheckBox, and other screen readers can access it normally. NVDA users just can’t access it in Chrome.
@feerrenrut

[josephsl]

Hi, ultimately it is up to how the web browser (technically, rendering engine) communicates presence of checkboxes like this. If you know there is a checkbox but a web browser’s rendering engine doesn’t show that to screen readers, then there’s really nothing we can do apart from taking the document content apart and inserting what we think should be there (not recommended). As far as web document content is concerned, screen readers “follow” what web browsers tell them to show, which is ultimately the responsibility of the document author (take automatic language switching, for example; authors specify display language for a specific passage (through markup), which in turn is interpreted by web browsers (rendering engines) to display content in a specific way that can be understood by speakers of the intended language, which in turn is passed to screen readers through markup lookup or through an object model); although a web document is written once, how it is displayed on different web browsers, and in turn, how screen readers respond to content shown differently on different browsers is really the responsibility of the rendering engine. Therefore I think the best place to raise concerns like this would be talking to web browser vendors (Mozilla and Google, to name a few) and ask them to take a look at the website in question, and if browser vendors say it is up to web authors to resolve this, then we could assume that it is something beyond the scope of a screen reader as the issue has to do with content authoring. In short, I’m saying all this because not all web accessibility, usability, and navigation problems stem from misunderstandings from screen readers. Thanks.