1.4.13 Content on Hover or Focus - hoverable requirement, clarification of point "persistent"

[detlevhfischer]

When transient content is brought up via hover, we offer as one option the use of the keyboard to close it (press ESC), so we mix input modes here. However, when content is brought up via keyboard focus, we do not seem to require that it is pointer-hoverable since the SC text says

"If pointer hover can trigger the additional content, then the pointer can be moved over the additional content".

Is that the correct reading? I.e. if something like a drop-down menu is brought up by tabbing to it, there is no requirement that the user can move the pointer over it and interact with it?

Finally, the SC text says

The additional content remains visible until the hover or focus trigger is removed(...).

I think the intention was to say "until the hover or keyboard focus on the trigger is removed". If so, this is not clear, so the text would be a candidate for errata. If however the formulation is deliberate, I don't understand it (the triggering element will rarely be completely removed ).

[alastc]

First point: Jon will take to the LV task force, seems unlikely to be a serious issues (compared the complexity of the other way around), but need to check.

Second point: Someone needs to think about the nitty-gritty of what the errata would be for the second point.

[mraccess77]

I think there is a case where the user might bring something up with the keyboard and the item doesn't fit in the magnified area. The user may want to use the mouse to pan to the content -- but moving the mouse causes it to go away. The user then must move the point over the hover trigger then it get it to come up again but this causes the user to have to move out of the magnified area.

[mbgower]

@mraccess77 I'd like to pinpoint the issue here, and flag the potential danger I anticipate trying to adjust to address your concern.

First, let's talk about what results from the existing language requirements:

1. When I am navigating by keyboard, new information appears on focus. I can dismiss it by keyboard.
2. Depending on my level of magnification, all some or none (with high magnification) of this information appears in the viewport.
3. Need to confirm, but I believe should users need to see content outside the viewport, in most situations they can use a cursor key (e.g., right arrow or specialized combo) to reposition the viewport to see the additional information. Since they are arrowing, the focus of the object isn't affected.

If users wishes to adjust the viewport by mouse, depending on how their mouse tracking is set (see below) when they touch the mouse, it either reorients the mouse to the current viewport or makes the current location of the pointer the new point of regard in the viewport.

It sounds like you are suggesting that this SC require that the viewport not change when they touch the mouse, but that seems to me to not only potentially break the paradigm of the SC but be overly prescriptive to AT behaviour.

My experience is that magnifiers have an ability for the user to set the bias for the magnification point of regard. The controls to this tend to allow a user to let point of regard/focus track to either mouse, keyboard or both. I believe there are also functions to allow the pointer to be brought to the current point of regard. I'm just going to install the latest zoomtext and confirm that is still the case. I have to reboot to complete the install, so I'm going to post this and add my findings.

[mbgower]

Okay, so not to suggest that one AT's implementation should dictate our policy, but here are my findings. Out of the box, Zoomtext 2019 reorients the pointer to the current viewport (the user's point of regard). So, when I am navigating by keyboard through interactive controls, if I consciously navigate so my pointer is not in the viewport and then I touch my mouse, the pointer is immediately brought to the current viewport, in fact directly to my focus point.

As well, Zoomtext has a number of settings that allow the user to modify this behaviour. I can make the focus never follow mouse or keyboard, etc. There is also a dedicated navigation setting, which for the mouse offers to "Route pointer into view when it is moved" (the default,) and/or "Route pointer over the active control" (so it would always track with the current keyboard focus).

In short, in its default configuration, the AT handles the scenario you are concerned with. I've had less experience with other magnifiers but I would anticipate similar functions and features.

If you don't find this persuasive, let me know as I'd like to then outline my concerns with a scenario which forces authors to maintain the overlay's presence until the mouse is moved back over the target and again moved away (which would seem to me to be the only way to implement what you are seeking).

[mbgower]

@detlevhfischer, to your original point

Is that the correct reading? I.e. if something like a drop-down menu is brought up by tabbing to it, there is no requirement that the user can move the pointer over it and interact with it?

I've heard of lots of times where overlays were only triggered by pointer and not keyboard, but never the opposite. If someone implements an overlay that only appeared on focus and not hover, then pointer interaction is irrelevant (since moving it is not going to either trigger or dismiss the content). I'll also mention that would be the same experience for all mouse users, and so is not an accessibility issue per se. Finally, the 'hoverable' bullet covers all scenarios where a pointer does trigger content.

For magnfication users in particular, I also don't see this the scenario of a keyboard-only overlay as an issue per this SC, as they would still be able to move their viewport by mouse using their magnifiers in order to read the entirety of the additional information.

To your second point

I think the intention was to say "until the hover or keyboard focus on the trigger is removed". If so, this is not clear, so the text would be a candidate for errata.

I agree completely, and I think your suggested rewording is a non-intrusive errata. Another possible wording might be:

"...until the hover or keyboard focus is removed from the trigger or additional content..." but I think yours is less wordy and fixes the main concern with the current language.

[detlevhfischer]

Hi Mike, Thanks for the testing you have done. I agree with all what you have said. If the LVTF does not confirm a use case where it is important that stuff brought about by keyboard focus should remain visible when the user grabs the mouse to move the focus over the new content, there is no need for the Sufficient Tech example to support that case (we can the use the live example provided by Jon). Best, Detlev Sent from phone

Am 16.01.2019 um 20:10 schrieb Mike Gower notifications@github.com:

@detlevhfischer, to your original point

Is that the correct reading? I.e. if something like a drop-down menu is brought up by tabbing to it, there is no requirement that the user can move the pointer over it and interact with it?

I've heard of lots of times where overlays were only triggered by pointer and not keyboard, but never the opposite. If someone implements an overlay that only appeared on focus and not hover, then pointer interaction is irrelevant (since moving it is not going to either trigger or dismiss the content). I'll also mention that would be the same experience for all mouse users, and so is not an accessibility issue per se.

For magnfication users in particular, I also don't see this as an issue as they would still be able to move their viewport by mouse using their magnifiers in order to read the entirety of the additional information.

To your second point

I think the intention was to say "until the hover or keyboard focus on the trigger is removed". If so, this is not clear, so the text would be a candidate for errata.

I agree completely, and I think your suggested rewording is a non-intrusive errata. Another possible wording might be:

"...until the hover or keyboard focus is removed from the trigger or additional content..." but I think yours is less wordy and fixes the main concern with the current language.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mraccess77]

Hi @mbgower for the record I was not the one who requested this and I totally understand the impact of keeping additional content on-screen. I was responding to Detlev's request and did share the situation with the LVTF list to get their opinion. Regarding the ATs and ZoomText -- most users with low vision are not using screen magnification software and likely would be using browser zoom or some other method such as custom style sheets -- so any support that ZoomText specifically provides could only be assumed if that was available. But again -- I understand the issues you mention and wasn't asking the WG for that scenario -- just responding to Detlev's questions. I believe the negatives outway the positives and given that if AT is available it can assist is enough to answer the question.

[jake-abma]

Hi @mraccess77 , do you have research on this somewhere:

Regarding the ATs and ZoomText -- most users with low vision are not using screen magnification software

Our experience with user testing shows most people with low vision DO have "screen magnification software" (80/90%) and often don't even know they can zoom in / viewing the next media query version.

In the survey on Webaim the numbers are:

45.2% of respondents use a screen reader, 48.4% screen magnification software, and 44% browser zoom controls. Other types of settings and AT are commonly used.

About 50/50 while this is not our experience with the user tests (80/90% screen magnification software)

Just wondering what your experience is here, thanks!

[alastc]

Hi @jake-abma, sounds like there might be skew from the recruitment? We tend to recruit based on technology use, so we're asking for people who use a particular technology like magnification software. That would lead you to getting about 90%! (Even when trying, we don't get 100% due to confusion on terminology.)

In that sense, the webaim survey is more general. From research we did for a TV project, there's a very wide range of usage across the continuum, Jon's claim wouldn't surprise me. I mean, some people with very low vision wouldn't use a mag, some with mild would, it didn't correlate in a way you'd logically expect...

[mraccess77]

Hi @jake-abma while the WebAIM survey shows a simple majority for low vision users do not rely on screen magnification software -- my assertion that even less rely on it is that in my experience many folks with low vision are older and likely have limited or no exposure to assistive technology and training. Most people with low vision do need enlargement -- and for those who know of the settings platform settings, browser, zoom, etc. can be the preferred way. That is the reason why we had SC 1.4.10 Reflow passed -- to allow for reflow which magnification software doesn't allow for. Your experience may be based on many users being instructed to use magnification software over other settings because their is a lack of awareness of the other settings or the other settings are not large enough for them. The WebAIM survey points out that most use 2 ATs and a significant number use 4 ATs frequently. So users will use different methods in different situations. Personally I find screen magnification dizzying and it's something I would only use when there is no other options -- and sometimes there is no other option. My point is that that we need to consider people may be using things in a certain way -- not because it's the best way -- but because that's what is available or only what works. If you are a student and you can't get a textbook or article in a format that reflows and your education system says they won't enlarge the material in a way that supports reflow then you may be stuck using a video magnifier to pan through the material for reading. As @WayneEDick has pointed out this is a very slow and ineffective way of reading. The WCAG SC 1.4.1.0 should help to promote reflow and reduce the need for magnification software on sites that are WCAG 2.1 conformant (at least for some users).

[mbgower]

Thanks for the interesting ancillary discussion on habits and use of magnification, folks.

So, it sounds like we have an agreement that point 1 of this issue:

if something like a drop-down menu is brought up by tabbing to it, there is no requirement that the user can move the pointer over it and interact with it?

does not need to be addressed with any change.

Rationale: The mouse/hover interactions for content on hover or focus are covered by the second bullet of the normative text ("hoverable"). Since it is highly rare to find a scenario where the keyboard-focus activation of additional content lacks equivalent hover affordance, the language in hoverable should apply in virtually all situations and is adequate, as per my prior comments. (I'll also mention that where keyboard-only interaction does apply, it could potentially be a failure of 2.5.6 Concurrent Input Mechanisms). On the second consideration raised, there also seems to be agreement that user re-orientation to the current point of regard based on changing modalities between keyboard and mouse is outside the scope of this SC.

For the second point regarding wording in the Persistent bullet, there is agreement that an erratum should take place:

I think the intention was to say "until the hover or keyboard focus on the trigger is removed". If so, this is not clear, so the text would be a candidate for errata.

I offered language that is potentially more precise than @detlevhfischer ("...until the hover or keyboard focus is removed from the trigger or additional content...") since it does not create a conflict between Hoverable and Persistent. On reconsideration, I believe an even easier modification of the language will achieve the desired effect, and that is the removal of the word "trigger" so that the erratum should make the Persistent bullet read:

Persistent The additional content remains visible until the hover or focus is removed, the user dismisses it, or its information is no longer valid.

A possible alternative that involves a more noticeable change but is more readable is to still remove "trigger" and swap the order of this last part. I believe this is the best erratum:

The additional content remains visible until the user dismisses it, its information is no longer valid, or the hover or focus is removed.

[detlevhfischer]

+1 to simplified language suggestion by @mbgower Agree that the other issues are resolved. Still need to replace the current live example in the Technique with the one offered by @mraccess77 ...

[steverep]

I agree with everyone on point 1 of the original issue, i.e. it's not an issue for this SC.

Regarding the second point, I disagree there's an error because it is simply a misreading of the word "trigger". If you define trigger as the "content that must be hovered or focused to cause additional content", then yes it is an erratum.

If you define trigger as simply the hover or focus action (and not a piece of content), then it makes more sense. Note that the word trigger is used 2 other times in the SC and this latter meaning is the one that applies.

I think this could easily be cleared up with a sentence in the Understanding doc, but that said, I understand the confusion and wouldn't oppose a simple language change instead.

[mbgower]

hi @steverep, been awhile so welcome back! I agree the issue arises because "trigger" can potentially be read as either a noun or a verb, and that one can argue it can stand as is without really confusing the issue. (Would anyone interpret this to mean you must eliminate the triggering element from the page?) Since the context is introduced in the first phrase of the SC ("Where receiving and then removing pointer hover or keyboard focus..." -- my emphasis), I think if we simply take away "trigger" from the Persistent text, we eliminate some of the issue because the language then reflects the opening prhase (" hover or focus is removed") I altered the order of the elements in the last phrase because I wanted to ensure it was obvious that "it" referred to the "additional content".

If we get pushback on treating this as an erratum, I agree a possible solution is just to add a note to the Understanding document to clarify.

@awkawk I believe we have enough support on this to take it to a survey vote.

[mbgower]

I have done the PR for the erratum. https://github.com/w3c/wcag/pull/603

[mbgower]

@awkawk I had offered to rewrite the Understanding doc to clarify this. Having reviewed it, in my opinion the existing wording fully addresses this. Under the Persistent subsection, it states:

Persistent The intent of this condition is to ensure users have adequate time to perceive the additional content after it becomes visible. Users with disabilities may require more time for many reasons, such as to change magnification, move the pointer, or simply to bring the new content into their visual field. Once it appears, the content should remain visible until:

-The user removes hover or focus from the trigger and the additional content, consistent with the typical user experience; -The user dismisses the additional content via the mechanism provided to satisfy the Dismissable condition; or -The information conveyed by the additional content becomes invalid, such as a 'busy' message that is no longer valid.

I believe any potential confusion from the use of the word "trigger" in the existing SC is clarified by this text and there is no need for an erratum.

[detlevhfischer]

I would prefer to have an unambiguous SC text without needing to resort to the Understanding text. For me, it still reads odd the way it is, but I am not going to insist on this if others think it is fine.

[alastc]

Hi @detlevhfischer (and for posterity), the group accepted the point that we should leave the erratum for the moment, and the understanding document addresses the context.

However, we can (more) easily make an editorial update in a 2.2, so putting a 'deferred' label on it.