Replies: 29 comments 2 replies
-
cc @jcsteh |
Beta Was this translation helpful? Give feedback.
-
Original issue: primefaces/primefaces#11623 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
The width/height 0 rule has been in NVDA for about the same amount of time. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Interesting. Let me know what you find out. |
Beta Was this translation helpful? Give feedback.
-
Browser interop aside, there are some good reasons not to hide an interactive control like this:
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. |
Beta Was this translation helpful? Give feedback.
-
Agreed but I thought it did have ARIA attributes on the hidden accessible input? This has been tested in multiple other screen readers? |
Beta Was this translation helpful? Give feedback.
-
ARIA attributes aren't going to help visual highlight or touch screen/mouse tracking if it's hidden. |
Beta Was this translation helpful? Give feedback.
-
But the component does highlight properly and works on touch screen. Have you tried it? It works fine... |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@Weavelor can you confirm the questions above in NVDA and JAWS? |
Beta Was this translation helpful? Give feedback.
-
@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;
} |
Beta Was this translation helpful? Give feedback.
-
Sure I can provide more info: JawsCursor highlightChrome: frame is shifted to the left Clicking with mouseChrome: "basic checkbox checked to clear checkmark press spacebar" (silent at any click after that) TouchBoth the same: "basic checkbox checked to clear checkmark press space bar" (see my comment from 18.03.24 for more details) Select with tabBoth 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. NVDACursor highlightChrome: shifted to the left, just like JAWS Hover with mouseboth the same: no output at all Clicking with mouseChrome: weird behavior there, it says "basic checkbox checked/not checked", but sometimes opposite to the actual checkbox state Touchboth the same: just "checked/not checked" (see my comment from 18.03.24 for more details) Select with tabChrome: "basic checkbox not checked" without component name or label Hope this helps. Feel free to ask if you need any additional information. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@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? |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@melloware I tried it, but it doesn't seem to change anything |
Beta Was this translation helpful? Give feedback.
-
OK that is an improvment on the old jQuery code so i am not sure why Firefox is reporting 0px height and width. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Here is what BootStrap CSS does for screenreader only style its similar to PrimeFaces. |
Beta Was this translation helpful? Give feedback.
-
@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: JAWSChrome:
Firefox:
NVDAChrome:
Firefox:
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@melloware using width and height 0 is actually not recommended at all, not only from an accessibility perspective. But also search engines interpret websites with such elements, including elements with text font size = 0 as being malicious or at least they are added on a tracking list for malicious behavior. Even in this article, height and width of 0 is not recommended. Actually in my view having width and height of 0 for elements should not pass accessibility tests. cc: @aleventhal since this also affects Google websites, e.g. the basic html button on gmail which also has width and height = 0 and is not accessible for various screen readers. I also saw other problematic things at least in bottstrap documentation where it is allowed to use aria-hidden="true" together with tabindex="-1" where afterwards the aria-hidden atribute is removed by bootstrap via javascript, this definitely has undesired negative effects as well. |
Beta Was this translation helpful? Give feedback.
-
Simple answer for Bootstrap: it didn't come to that conclusion, which is why it's using 1px not 0 (as per #16398 (comment))
The perception is that "CSS is for visual styling, so won't affect how things are exposed/announced by screen readers". It's then browsers/screen readers who decided to implement "clever" heuristics to take styling hints to also decide when something is/isn't exposed.
If you can be more specific (where this behaviour occurs, and what the actual undesired negative effect is), I'm sure an issue submitted against bootstrap would help... |
Beta Was this translation helpful? Give feedback.
-
@patrickhlauke thanks for the quick reply, yeah I think I was confused by #16398 (reply in thread) Re: aria-hidden="true" and tabindex="-1", using aria-hidden atribute on a modal dialog and removing the aria-hidden atribute afterwards with javascript causes loss of focus for NVDA when closing or doing any actions in that dialog. |
Beta Was this translation helpful? Give feedback.
-
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:
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
Beta Was this translation helpful? Give feedback.
All reactions