Violation of 4.1.2 if AT output is correct on keyboard operation but not on hover with mouse?

[JAWS-test]

Web applications often use standard elements (e.g. for checkboxes, radio buttons and drop-down lists), but want to style them and therefore do not use the HTML elements for the visual presentation. I.e. in the source code there is e.g. a HTML checkbox, which also receives the keyboard focus and can be operated. Using CSS, the HTML checkbox is positioned outside the visible area. Then a purely visual checkbox is created via CSS. If I now operate the application with the keyboard, the AT works correctly. When I hover over the elements with the mouse, the AT cannot output the element type correctly because there is no checkbox under the mouse pointer, only a graphic created by CSS.

Criterion 4.1.2 does not state that the requirements only apply to keyboard operation. In practice, however, many test procedures seem to check 4.1.2 only with the keyboard. Therefore, I would like to clarify whether this is actually considered sufficient. Such elements are particularly problematic for visually impaired people who navigate with the mouse due to their residual vision, but still rely on a screen magnifier or screen reader to output the elements under the mouse pointer.

Another problem with these elements is that with keyboard operation, focus tracking with the screen magnifier does not work because the screen magnifier focuses on the invisible HTML checkbox and not the visually displayed checkbox. Again, the question would be whether this is a violation of 4.1.2, i.e., whether WCAG requires not only a visual focus indicator (SC 2.4.7) and programmatic transmission of the currently focused element (which would be satisfied for this type of element), but also programmatic transmission of the size and position of the focused element to the Accessibility API (as required by EN 301 549 for software)

[detlevhfischer]

@JAWS-test This is an interesting point. I can't see anything in the normative text of 4.1.2 that would limit the requirement to keyboard use. Interpreting it they way you suggest significantly raises the bar for all implementations that use styled custom controls. I'd be curious if there are best practices for using custom controls that would still ensure correct AT output with pointer hover (probably by sticking native controls below the custom ones instead of positioning them off-screen?)

[JAWS-test]

@detlevhfischer

There are several ways to avoid the problem:

• Use only standard HTML elements and style them with CSS.
• don't use HTML elements, but mark the custom elements correctly with ARIA
• position the keyboard focusable elements directly behind the custom controls (this would at least solve problem 2 with focus tracking, but depending on the AT not automatically the first problem with the output by AT, because it is not guaranteed that the AT recognizes elements that are obscured by others (because they are invisible)

However, I am not interested in finding a solution for the problem, but in clarifying whether the use of the elements I have described is evaluated as a violation of 4.1.2

[patrickhlauke]

personally, i think that's then getting a step too far, as it will severely impact situations where a more keyboard/AT friendly alternative is provided (think for instance a <canvas>, but with a visually hidden alternative behind it, or any other situations where extra "real" controls/information is provided). this would immediately make a large portion of the web non-compliant. the situation of having the mouse and announcing only what's visually immediately below to me falls under "ways in which users manipulate content at their end" that isn't really covered by WCAG. having WCAG mandate that you basically aren't allowed to do any of the things that are in widespread use right now would likely be a non-starter for any new SC, and i don't believe 4.1.2 Name, Role, Value ever intended to cover this particular case either.

[bruce-usab]

Thanks for this interesting example @JAWS-test!

This sounds like the sort of UI which I would test using ANDI and from your description, being keyboard-oriented, means my audit might miss a real barrier for people using screen magnification.

If I assess the behavior as problematic and ANDI (or code inspection) does not really justify a failure against 4.1.2 — I have no qualms failing what you describe against 1.3.1. There is enough of disconnect between the visual presentation and the programmatic one. Otherwise, I would give it a pass.

For me to fail the behavior, I would want to believe that the mouse-over text was essential (probably not true nowadays, thanks to the popularity of phones and tablets) and/or that people using products like ZoomText or MAGic were really at a disadvantage.

[patrickhlauke]

@bruce-usab I think you're misunderstanding the point being made. it's not about mouse-over text - it's not about tooltips or similar.

Web applications often use standard elements (e.g. for checkboxes, radio buttons and drop-down lists), but want to style them and therefore do not use the HTML elements for the visual presentation. I.e. in the source code there is e.g. a HTML checkbox, which also receives the keyboard focus and can be operated. Using CSS, the HTML checkbox is positioned outside the visible area. Then a purely visual checkbox is created via CSS. If I now operate the application with the keyboard, the AT works correctly. When I hover over the elements with the mouse, the AT cannot output the element type correctly because there is no checkbox under the mouse pointer, only a graphic created by CSS.

Randomly checked https://www.w3.org/WAI/ARIA/apg/example-index/checkbox/checkbox.html with NVDA set to track mouse pointer...and even these perfectly correct ARIA-based checkboxes, when hovered with the mouse, only announce their title, and nothing about their role nor their checked/non-checked state. So going purely by current behaviour, even this would be a failure you think?

[JAWS-test]

@patrickhlauke

Randomly checked https://www.w3.org/WAI/ARIA/apg/example-index/checkbox/checkbox.html with NVDA set to track mouse pointer...and even these perfectly correct ARIA-based checkboxes, when hovered with the mouse, only announce their title, and nothing about their role nor their checked/non-checked state

This is not quite correct. The role checkbox is always output by NVDA, the status unfortunately not. However, the checkbox role cannot always be heard completely, since the output may be interrupted by other outputs, e.g. by the output of the graphic or label. However, I see in the speech viewer that "checkbox" is output. Depending on the side and how fast I hover over the checkbox, I also hear checkbox acoustically. Regardless of the technical flaws of screen readers, the question still remains whether 4.1.2 refers only to keyboard operations. I have no problem with this (even if it is an accessibility limitation), but would like to get clarification here and then add an appropriate note in the Understanding.

[patrickhlauke]

This is not quite correct. The role checkbox is always output by NVDA, the status unfortunately not. However, the checkbox role cannot always be heard completely, since the output may be interrupted by other outputs, e.g. by the output of the graphic or label. However, I see in the speech viewer that "checkbox" is output. Depending on the side and how fast I hover over the checkbox, I also hear checkbox acoustically.

interesting. can't seem to reproduce this, but perhaps there's something else going on... (video of chrome+nvda with mouse tracking enabled - only seems to announce the label, not the fact it's a checkbox)

https://user-images.githubusercontent.com/895831/185918071-ffa94d78-2121-477a-a689-559b28ebb845.mp4

EDIT: ah, mystery solved...the "Report role..." checkbox was checked, but seems I hadn't hit "Apply". doh!

Regardless of the technical flaws of screen readers, the question still remains whether 4.1.2 refers only to keyboard operations.

I think it's less about applying to "only with keyboard", but rather not applying to non-standard situations where a tool is trying to announce whatever is underneath the mouse cursor, which may not represent the actual underlying structure of the page. not sure how to word that though...

[JAWS-test]

@patrickhlauke

I think it's less about applying to "only with keyboard", but rather not applying to non-standard situations where a tool is trying to announce whatever is underneath the mouse cursor,

Three things come to my mind:

• 4.1.2 just deals with non-standard situations. When 4.1.2 was written, the authors assumed that standard elements are always correctly submitted to the Accessibility API (because this is the browsers' job and if they don't do it, it's a violation of UAAG, but not of WCAG). 4.1.2 was written precisely for custom elements where the role or status are not automatically submitted.
• Also, the question would be whether mouse operation is such an unusual method for people using AT.
• And I described as an additional problem the incorrect focus display with screen magnifiers, which occurs with keyboard operation (unfortunately this is not covered by WCAG, but only by EN 301 549, 11.5.2.5, for software).

But if we want to describe such cases as not relevant for 4.1.2 in the Understanding (even if the normative wording does not explicitly exclude it), how would you phrase it?

[patrickhlauke]

probably taking a further step back, the assumptions (without going into another "what we actually meant when we wrote this 17 years ago" debacle) was likely:

• sighted (mouse and keyboard) users will interact with what's visually presented (with extra consideration for keyboard users to make sure that visually their focus/position is also visually clear)
• assistive technology users will interact with the underlying structure/what's exposed by browsers to the accessibility API

AT that do the "announce what's under the mouse" thing probably uncomfortably straddle these two models. As to how to phrase this...no idea just now.

The additional issue of screen magnification following the real focus and then not matching the "faked" content may, depending on the situation, possibly be already covered by Focus Visible, but this would warrant a separate discussion I'd say.

[JAWS-test]

@patrickhlauke

The additional issue of screen magnification following the real focus and then not matching the "faked" content may, depending on the situation, possibly be already covered by Focus Visible, but this would warrant a separate discussion I'd say.

I would have hoped the same, but unfortunately it was rejected (https://github.com/w3c/wcag/issues/952) and not completely fixed with the two new focus SCs.

[bruce-usab]

I think you're misunderstanding the point being made.

Sadly, probably not the last time...

it's not about mouse-over text - it's not about tooltips or similar.

It is a about a UI that is okay for typically sited people and people using screen reading software — but problematic for low-vision users. Is that correct?

I am am having trouble visualizing the issue. ToolTips was about all I could think of. I will read the comments more carefully. Thank you for your past and continued patience with me.

...and even these perfectly correct ARIA-based checkboxes, when hovered with the mouse, only announce their title, and nothing about their role nor their checked/non-checked state. So going purely by current behaviour, even this would be a failure you think?

Is the behavior problematic for someone with modern OS and AT? If so, yes, I would grade it as a failure. If pressed for the SC number, I have no problem citing an SC that only appears in 2.1.

I do appreciate that my testing environment is not typical. But if you have a manager/developer pushing back on a real barrier because the requirement is in EN 301 549 and not Section 508 — that is huge win in my experience. Worse case is I negotiate a hard date for it to be fixed and whose name in on the ticket. Also, I kind of like the subtle pressure for USA to catch up!

My own habit is to use code inspection only to pass content which is not in practice actually problematic. Similarly, I will use contemporary AT behavior to pass something flagged by code inspection.

Both of those are covered by our broad charging statute: E203 Access to Functionality

[JAWS-test]

@bruce-usab

It is a about a UI that is okay for typically sited people and people using screen reading software — but problematic for low-vision users. Is that correct?

It is primarily a problem for low vision users who use speech output, whether the speech output of the screen reader or the screen magnifier.

It can also be a problem for

• cognitively impaired users who use speech output.
• blind people who use the screen reader to explore the page by hovering the mouse over the screen (which is rare, but not excluded)