In Firefox, NVDA just reads "blank" when a SelectBooleanCheckbox from PrimeFaces is focused with tab

[Weavelor]

Steps to reproduce:

Can be reproduced in the Primefaces Showcase using Firefox (123.0.1) and NVDA (2023.3.4).

Use Tab to select a checkbox.

Actual behavior:

When you use tab to select a checkbox, NVDA simply reads "blank." You then need to press the arrow down key to hear the itemLabel of the checkbox. In both cases, you can press space to check or uncheck the checkbox, so it's unclear where the focus lies the first time the screen reader reads "blank." When you click the checkbox with the mouse, it always says "blank," regardless of the checkbox's state.

exact outputs:

Chrome after focus with tab:
"Basic check box not checked "
arrow down key:
"clickable"
arrow down:
"clickable Basic"
arrow down:
"heading level 5 Remote"

Firefox after focus with tab:
"blank"
arrow down:
"clickable Basic"
arrow down:
"heading level 5 Remote"

This issue seems to only arise when using Firefox with NVDA:

• NVDA and selectBooleanCheckbox functions correctly with other browsers like Chrome or Edge.
• Other screen readers, such as Microsoft Narrator, function properly with selectBooleanCheckbox in Firefox.
• Other checkboxes, like those from Ant Design, work with NVDA and Firefox.

I already created an Issue to PrimeFaces and they have suggested that it might be an issue on your end. However, I also suspect it could be related to Firefox. Since I'm unsure where the problem lies, any help would be greatly appreciated.

Expected behavior:

NVDA should behave the same in Firefox as it does in Chrome.

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

2023.3.4.31265

Windows version:

Windows 11 Enterprise 22H2

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.

No, haven't tried

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

It's a fresh installation, so no add-ons installed

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

Yes

[lukaszgo1]

cc @jcsteh

[melloware]

Original issue: primefaces/primefaces#11623

[jcsteh]

It looks like the checkbox reports as offscreen in both browsers. However, in Firefox, it goes a step further and it reports as having a width and height of 0. NVDA will ignore anything with a width and height of 0, since this effectively makes it invisible.

I'm not sure why this checkbox reports as having a width and height of 0, but the fact that both browsers report it as offscreen is suspicious to me.

[melloware]

PrimeFaces uses a style called 'ui-hidden-accessible' to make the component visible to screen readers but then renders a different custom ui for the component.

So the ui-hidden-accessible makes it height and width 0.

It's been doing it like this since 2010 and we have never seen screen readers ever not read it.

[jcsteh]

The width/height 0 rule has been in NVDA for about the same amount of time.

[jcsteh]

Chrome somehow doesn't report a width and height of 0 in this case. I'm not sure how. If I can figure that out, we might be able to implement a similar hack in Firefox. But ultimately, width and height of 0 is going to cause problems somewhere along the line.

[melloware]

Interesting. Let me know what you find out.

[jcsteh]

Browser interop aside, there are some good reasons not to hide an interactive control like this:

1. If a screen reader user has some sight, they might be relying on the highlight drawn by some screen readers around the control of current interest. If the control exposed for accessibility is off-screen, that highlight may appear in the wrong place or not at all.
2. If a screen reader user is using a touch screen or the mouse, the control will not be spoken correctly when they mouse over it.

I realise you're using a hidden input because you want to use the native control but you want custom styling. However, if you're going to hide the native control, you're better off using ARIA on the custom control here so that its accessibility exposure matches up with its visual representation and coordinates. Remember, not all screen reader users always use keyboards and not all screen reader users are totally blind.

[melloware]

Agreed but I thought it did have ARIA attributes on the hidden accessible input? This has been tested in multiple other screen readers?

[jcsteh]

ARIA attributes aren't going to help visual highlight or touch screen/mouse tracking if it's hidden.

[melloware]

But the component does highlight properly and works on touch screen. Have you tried it? It works fine...

[jcsteh]

Is it read correctly by a screen reader when you move your mouse over the check box or directly touch the control on a touch screen? Is it highlighted correctly by a screen reader when the screen reader is set to highlight its cursor? From what I can see in Chrome, the former doesn't work. I'm blind, so I can't tell whether the latter does.

[melloware]

@Weavelor can you confirm the questions above in NVDA and JAWS?

[melloware]

@jcsteh i also looked and our ui-hidden-accessible CSS actually makes the component 1px height and width.

.ui-helper-hidden-accessible {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

[Weavelor]

Sure I can provide more info:

Jaws

Cursor highlight

Chrome: frame is shifted to the left
Firefox: frame is not visible at all

Clicking with mouse

Chrome: "basic checkbox checked to clear checkmark press spacebar" (silent at any click after that)
Firefox: "PrimeFaces showcase document" (clicking more times: "basic checkbox checked/not checked", sometimes just "not checked" and sometimes it says nothing at all)

Touch

Both the same: "basic checkbox checked to clear checkmark press space bar" (see my comment from 18.03.24 for more details)

Select with tab

Both the same: "basic checkbox not checked to check press space bar"

Did not know how to get JAWS to say what's under my cursor, so unfortunately I have no infos on that.

NVDA

Cursor highlight

Chrome: shifted to the left, just like JAWS
Firefox: frame exactly where the checkbox is

Hover with mouse

both the same: no output at all

Clicking with mouse

Chrome: weird behavior there, it says "basic checkbox checked/not checked", but sometimes opposite to the actual checkbox state
Firefox: it just says "blank"

Touch

both the same: just "checked/not checked" (see my comment from 18.03.24 for more details)

Select with tab

Chrome: "basic checkbox not checked" without component name or label
Firefox: just "blank"

Hope this helps. Feel free to ask if you need any additional information.

[Adriani90]

Chrome: weird behavior there, it says "basic checkbox checked/not checked", but sometimes opposite to the actual checkbox state

This is covered in #15854. @LeonarddeR is this a regression introduced by #15518? Note there is a difference when clicking on the control itself vs. clicking on the label withing the checkbox.

[Adriani90]

PrimeFaces uses a style called 'ui-hidden-accessible' to make the component visible to screen readers but then renders a different custom ui for the component.
So the ui-hidden-accessible makes it height and width 0.
It's been doing it like this since 2010 and we have never seen screen readers ever not read it.

@melloware I am pretty sure NVDA had always problems reading something like this correctly depending on which browsers you are testing it. it was never consistent. Height and width 0 is not really working in firefox, see for example also the "change to basic html" button on the google mail website.
Did you try to set the custom UI element with opacity:0 instead of defining height and width = 0? I think this might be rendered better for screen readers in any browser.

[melloware]

@Adriani90 we set width and height to 1px not 0. Sorry the CSS is here.

.ui-helper-hidden-accessible {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

But now you have me wondering if opacity:0 is better?

[melloware]

@Weavelor can you try this and open up that Showcase page in Firefox. Then press F12 to bring up the console and click on Style Editor tab and then click the PLUS icon in the upper right and paste this new style

.ui-helper-hidden-accessible {
    border: 0 !important;
    padding: 0 !important;
    margin: 0 !important;
    position: absolute !important;
    height: 1px !important;
    width: 1px !important;
    overflow: hidden !important;
    clip: rect(1px, 1px, 1px, 1px) !important; /* Legacy Browsers */
    clip-path: inset(50%) !important; /* Modern Browsers */
    white-space: nowrap !important;
}

now try NVDA is it better? This is supposed to be an improved version of the old Jquery code.

[Weavelor]

@melloware I tried it, but it doesn't seem to change anything

[melloware]

OK that is an improvment on the old jQuery code so i am not sure why Firefox is reporting 0px height and width.

[jcsteh]

Yeah, I'll look into the Firefox 1px issue when I can. It's definitely a bit odd.

Thanks for the test results, @Weavelor. Regarding touch, can I clarify whether this is what you heard when you touched the check box on the touch screen without double tapping it or whether this was after activating with a double tap? Once you double tap, the check box will probably get focus. For touch tracking, what we're interested in is whether tapping it reports the correct control without activating it, since that's where the screen coordinates matter.

[Adriani90]

In general opacity:0 seems to work well at least with Windows screen readers in any browser I've tested so far. But not sure it goes well with IOS or Android screen readers.

[melloware]

Here is what BootStrap CSS does for screenreader only style its similar to PrimeFaces.

https://github.com/twbs/bootstrap/blob/4219af2c0ef1bccb0408128ef4d34f3cea7a6da5/scss/mixins/_visually-hidden.scss#L8-L22

[Weavelor]

@jcsteh I think I just focused the checkbox with the tab key and then double tapped to activate it. Today I played around with it a bit more and here are my findings:

JAWS

Chrome:

• tapping on label: no focus frame, it says "basic"
• tapping checkbox does not work at all (no focus frame, no speech)
• double tap after tap on label: checkbox is focused, but focus frame is shifted to the left, checkbox get checked, it says "basic checkbox checked to clear check mark press space bar", double tap after that "checked/not checked"

Firefox:

• tapping on label: no focus frame, it says "basic edit"
• tapping checkbox does not work at all (no focus frame, no speech)
• double tap after tap on label: no focus visible, checkbox gets checked, "basic checkbox checked to clear check mark press space bar", double tap after that the checkbox gets checked and unchecked, but JAWS remains silent
• sometimes after double tapping, JAWS says "PrimeFaces Document", don't know how this happens, but at the same time I'm not familiar with JAWS and using it together with a touchscreen, so maybe I'm doing something wrong

NVDA

Chrome:

• tapping on label: focus on label and it says "basic text basic"
• tapping on checkbox only works when it is checked, focus frame is exactly around the checkbox, it says "text", but in the speech viewer you can see a special character, that looks like a dot but it's more in the upper half of the line (screenshot below),
  
• double tap while focus is on label: checkbox is focused, but focus frame is shifted to the left, checkbox gets checked, but NVDA says "activate basic checkbox not checked", double tap after that "activate checked/not checked"

Firefox:

• tapping on Label: focus on label and says "basic text"
• tapping on checkbox: same behavior like chrome, but focus frame is exactly around the checkbox
• double tap while focus is on label: checkbox is focused, focus frame around the checkbox, checkbox gets checked, it says "click ancestor blank", double tap after that "activate checked/not checked"

Again, I'm not familiar with using a screen reader with touch controls, so when you need any additional information or have suggestions, which things i can test, fell free to get back to me.

[seanbudd]

Converting this to a discussion. As-is, the issue around handling 0 width/height objects is intended behaviour. The rests of this discussion appears to have gone off to good authoring practices and web browsers bugs.