Link to issue number:

Fixes #13897.

Summary of the issue:

Currently, in web browsers, NVDA treats controls with a 0 width or height and no children as invisible. While this makes sense in theory, there are quite a few instances in the wild where authors use off-screen content to expose something to screen readers without exposing it visually. Because it's not visible, they sometimes don't necessarily consider that the width or height is relevant and end up with 0 width/height, making it completely inaccessible in NVDA browse mode. This is most common for custom radio buttons and check boxes, but I've also seen it for custom text editors and some other controls.

I would argue this is misguided authoring on multiple levels, but ultimately, this is causing real problems for NVDA users across the web and our first responsibility is to users. This was implemented a long time ago when the web was a lot simpler and there has been a shift over the years towards trusting explicit semantics rather than fragile visual heuristics. Finally, as far as I've been able to determine, no other screen reader does this, which is problematic for interoperability. This means there is content which works in every other screen reader except NVDA.

Description of user facing changes:

In browse mode in web browsers, NVDA no longer sometimes treats controls with 0 visual width or height as invisible. This technique is sometimes used to make content accessible to screen readers without it being visible visually. Such controls will now be accessible in browse mode where they weren't before.

Description of developer facing changes:

None.

Description of development approach:

In the gecko_ia2 vbuf backend, removed the code which results in isVisible being set to false if width or height is 0.

Testing strategy:

In both Firefox and Edge:

1. Tested with the CodePen example from NVDA skips elements with zero width or height #13897 (comment). Before the change: radio buttons do not appear in browse mode. After the change: they do.
2. Tested with this simple test case:
   data:text/html,before<div role="radio" aria-label="control"></div>after
   Before the change: the radio button does not appear in browse mode. After the change: it does.
3. Loaded the Monaco Editor website. Before the change: quick nav to edit field often didn't find anything, though sometimes it would appear on the first load and then disappear when refreshed. After the change: quick nav to edit field always finds the editor.

Known issues with pull request:

@seanbudd noted in #13897 (comment) that NV Access supports making this a setting. While I understand the desire for caution here, there is currently no way to have settings like this that affect vbuf backends without a significant amount of work. It can't be done like layout tables because it needs to affect the content that is rendered into the buffer, not just what semantic information gets reported. It might be slightly more feasible to do this for pages loaded after the setting is changed, but that is probably confusing for users and is still a reasonable chunk of work. Meanwhile, this issue would remain unfixed and continue to cause problems for users, potentially on a daily basis.

I accept that if this causes unanticipated problems, it might need to be reverted. It's a simple enough change that this can be done without much churn.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.