Even if I share and understand the need, this will basically make 99% of the site I know claiming conformance to wcag 2.0 AA not conforming anymore. I think it must be moved to AAA or wait for wcag 3.0. It also look to me more as a UAAG issue than authors issue for example If I remember well edge started to show tooltip on focus

Your estimation of it's commonality is different from mine, I've checked around some sites and the only use that I could find was either ok (and not failing here) or mis-use that probably should fail (something).

I was using this CSS to view titles (using a bookmarklet to append the CSS):

*[title] {outline: 2px red dashed !important;}

*[title]:after {
    content: attr(title) !important;
    color: #c55;
}

On the BBC homepage the only titles are on the 'remove' buttons. They don't assume you can access the title, and don't block other content.

On Amazon.co.uk, there are quite a few in the product listings, but I think they've been JavaScripted-out of normal usage, they don't appear. Towards the bottom the rating stars have titles that duplicate the text, which overlap and would be caught.

On the WhiteHouse.gov, there are a couple of titles on the top bar links, but they are spaced out and the titles don't overlap other content. The horizontal icons for social media also cause pop-overs that don't overlap.

I'd agree it could be a user-agent issue, but as the focus aspect has been an open issue for over a decade, I think there's a case for incorporating it into the content guidelines.

title attribute is explicitly mentioned in multiple wcag techniques as a possible solution, like :
https://www.w3.org/TR/WCAG20-TECHS/H33.html for links
https://www.w3.org/TR/WCAG20-TECHS/H64.html for iframe
https://www.w3.org/TR/WCAG20-TECHS/H65.html for form inputs
https://www.w3.org/TR/WCAG20-TECHS/H89.html for context sensitive help

even if many people including myself doesn't think those techniques are best way of achieving the underlying success criteria it's still a possible solution to use and many sites use it. In France for example it's a very common practice (for example last two sites that receive a label from accessiweb use it : http://www.chu-toulouse.fr/ , http://www.sncf.com/fr/trains/ter and I can give you plenty.

on amazon.co.uk the title do appear for me on the product listing and are failing this SC, on whitehouse.gov even if title don't overlap it's still no conforming with the current testing procedure

My fear is that only to conform to this SC many will simply remove or change title to aria-label because it's far easier that implementing custom tooltips that anyway will be very annoying in mobile or changing the UI/UX to remove the need of a tooltip. We will end up with less accessible interface anyway because even if not perfect title was useful in many cases.

The title attribute has support issues. Ref: Using the HTML title attribute by @stevefaulkner

Thanks @lauracarlson i'm aware of that but it still something currently allowed in wcag 2.0 techniques.

If in WCAG 2.1 title isn't allowed anymore fine but that mean that a lot of website conforming to WCAG 2.0 won't be able to conform without changing techniques used to conform and doing that we may end up with solution even less accessible that title like aria-label or hidden label or hidden text that have no visual feedback at all.

So if you want to reject title as a possible technique for WCAG 2.1 you also need to reject all those other kind of solutions.

Furthermore the only viable technique is to remove the need of metadata on hover by changing the UI because :

• using a JavaScript / CSS to provide a pop-over that works on hover and focus that does not cover other content -> doesn't work on mobile (and nobody want tooltip on touch)
• Using onclick (accessible to keyboard and touch devices) to show small pop-over content instead of title attributes (future technique). -> doesn't work for on links / button because onclick already used

For me it look very costly to achieve that's why I think it's better to make it AAA in WCAG 2.1 and then move it back to AA in WCAG 3.0 to allow smooth transition

A number of concerns and thoughts on this.
First, unless title is only used on a piece of text that is entirely separated from all content by a lot of whitespace, a tooltip is going to obscure something. That is its nature. So this SC as written ("does not obscure other content") would effectively make most uses of title fail WCAG. As a result, I suggest this language needs to be refined in some way.
Second, the use of tooltips via title forms an important part of potential assistance for users who need more context. I'm thinking here of things like its use for ABBR.
It took me multiple reads to understand that this SC is not intended to apply to icons and other controls. That needs to be spelled out more clearly. For instance, it's still not clear to me whether someone who uses TITLE to add additional explanatory information to a label regarding an input's purpose would be failing "informational content."
In my view, this is a prescriptive, technology-based reaction to a problem. History has shown that trying to overcome a technical limitation by limiting use of a technology can lead to problems later (think of the 'ban' on javascript in 1.0 or the 'ban' on CSS in 508).
Yes, the implementation of title by user agents has many problems. But is it not better to tackle that with UAAG than composing a workaround in WCAG?
So, if we stripped out the technical bias in this SC, what are we left with?

The more general case is that any hidden information should not only be available to specific input types such as a mouse.

Even if this more general case was implemented (say, the author provides the display of title information on keyboard focus), it still doesn't resolve the obscuring of other information, nor does it address control of the information's persistence or location.
Putting the problem another way:
a mechanism is available to allow user control for the display of non-persistent textual information.

If users were given the option of displaying or not displaying tooltips, along with timing (how long before a display is triggered, how long does the tooltip persist), interaction (how to trigger and dismiss) AND how about the ability to override (making the non-persistent information appear persistently) the need for this SC would change. An ability to control different ways to indicate the existence of a tooltip would also be useful. All of those abilities should really be handled by the user agent.

Here's another way of thinking about this. Currently there are 2 levels of link purpose: one where the link is clear from its surrounding context (2.4.4); one where the context is clear from the link text alone (2.4.9). Maybe another way of tackling non-persistent informational content is to create a new AAA where all informational content is provided persistently or without the need for additional user actions. That would have to be reworded since it has to accommodate progressive disclosure and dynamic content, but hopefully folks understand what I'm getting at.

I would clearly separate requirements for the use of the title attribute from custom content displayed on hover. The example on the Perkins recruitment site is nasty but seems of another order. I agree with @goetsu that in 2.1 we should not invalidate the admittedly dated techniques served alongside WCAG 2.0, and with @mbgower that handling the title attribute is really more the responsibility of UAs.

Updated the issue description to reflect the FPWD text.

April 11

Test for addressing.

New related article: How to Make Your Website Accessible to People Who Use a Screen Magnifier by Frederik Creemers.

...

1. Leave tooltips and other mouse-triggered pop-ups visible while the mouse is on the displayed content.
2. Don't obscure content when the mouse is hovering over it...

Related LVTF email:

• Positioning Tooltips - Revisiting Hover SC (April 8, 2017 Thread) - Marla Runyan
• Lets Change Meta Data Back, and Put it on the agenda (April 11, 2017 Thread ) - @WayneEDick

Marla Runyan's Positioning Tooltips Above Triggers...and Keyboard Accessible Demos.

Hi -
Are we going to merge popup interference and the former "metadata on hover" SC in a single SC, or keep them separate?

Below I have summarized both issues as they relate to mouse-hover content:

1. The inability to perceive content that appears on hover.
   Examples:
   (a) Tooltip obscured by enlarged pointer. Default position of tooltip content created via the title attribute is below and right of the trigger element. This positioning results in an enlarged mouse pointer blocking all or part of the tooltip. Moving the mouse will cause the tooltip to disappear. This issue is most impactful when the tooltip is the only visual text label for a component.
   (b) Content disappears when mouse moves off trigger and moves on to displayed content. This occurs for tooltips created using the title attribute by default, but may also occur for larger containers of content of text that are unintentionally triggered as a user navigates a page. This issue can cause significant barriers for users who depend on screen magnification where the zoom window is dependent on mouse navigation. (The onmouseout event handler can cause this issue).
   AND
2. Content that appears on hover may block perception of triggered content. (See screenshot).

Link to view videos that capture the above described issues:
https://drive.google.com/open?id=0B6nh5-QGl_zLWUNvN1JJdXh1M28

Hi @Marla262 ,

Marla wrote:

Are we going to merge popup interference and the former "metadata on hover" SC in a single SC, or keep the m separate?

Both are needs. I would be in favor of trying to get them both into the SC as you have techniques for both.

Thanks,
Laura

Meta Data on Hover / Popup Interference
Informational content which appears on hover that is necessary for understanding must:
• be fully visible,
• be available on focus as well as hover
• be available via any input method.
• not be obscured, and
• not obscure important content that is related to the triggering event.
I looked at “Popup Interference” and the original Meta Data on Hover and realized that there was only one thing in Popup Interference that was not in the original wording. That is the last point:
Marla’s giant title contents example, “Div on Hover Obscuring Content Example”, falls into the “is obscured” category. The hover content is not obscured.
Question on clarity? Is it clear that all the information required on focus must also satisfy the other points. That is: Popups from focus different from hover popups and thus exempted from obscuring other content?

Wayne

Hi @allanj-uaag , @WayneEDick , @Marla262 , and all,

We will likely need a definition for the word "obscure". Maybe use or tweak UAAG's definition? It is:

To render a visual element in the same screen space as a second visual element in a way that prevents the second visual element from being visually perceived.

Do we want to expand that to include use cases other than just the "same screen space"?

The term "important information" is already listed in the 2.1 terms so we can just link to that.

Questions that will likely be raised and for which we should be prepared to answer:

• What is the technique to turn off the informational content? Do authors need to provide a mechanism?
• What are the other means of accessing the informational content?
• Others?

I would suggest removing the note as authors can indeed solve the title attribute issue in 2.1 with @Marla262 's techniques.

Thanks,
Laura

I have concerns with the addition of the two new bullets:

For informational content that appears on hover or focus, all of the following are true:
...
Other method
hover and/or focus are not the only means of accessing the informational content
Not important
does not include information necessary to perceive content

Since all must be true, this is saying that anything that appears on focus is disallowed. This would seem to rule out styling to indicate focus, which has the effect of forcing the user to operate with no visual feedback. I assume that's not the intent.
At the very least, you need to define "informational content" or modify it to be "textual content" or something. But I think there will be other cases that will become apparent where this SC's language are going to cause innovative design to fail.
I'm also very puzzled by why an ability to offer access only by focus is viewed as undesirable.

On other changes since I last commented. I appreciate that you've refined the 'obscure' language; I'll have to think whether this covers all the possible title scenarios. It seems to me if someone had a large link target, this would still cause a failure.

My other comments still stand, for instance, what is wrong with having an exception like this:

a mechanism is available to allow user control for the display of non-persistent textual information.

I think your language on "turn off" is bordering on this, but doesn't address all the other ways to control persistence, etc., I previously mentioned. It's also not clear to me whether you are going to accept the exisitence of User agent control as a means of meeting "turn of" or if you are intending that the author must in all cases offer this ability. Same goes for obscure. If one poor user agent implementation causes obscuring, does the author get failed?

Hi @awkawk,

I was going to make some of these changes now in GitHub but I see you beat me to it. I would have limited it to just the switch from "popup" to "additional content" and other minor changes. I cannot support some of these changes, and some reverse changes made to address the comments on the 1st survey.

1. "Visual presentation" was dropped to "presentation", which drew comments that all presentation is done by the user agent in a sense. Adding visual is minor, but is consistent with uses already in WCAG 2.0 and seemed to satisfy other members.
2. The bullets now refer to "trigger" and "additional content", but neither term is used in the sentence above the list which needs to define them. Several commenters wanted a clear definition of trigger and its relationship to the popup or additional content. I recommend sticking with something similar to what I originally proposed.
3. You've limited the trigger to being a user interface component, which I don't understand. Generally, the WCAG definition of UI components favors "clickable" things that perform a function, which is not always the case here. Think of an image showing a custom tooltip or a menu where the top level item is not a link. Recommend going back to trigger content.
4. I'm not sure what was discussed after I needed to drop off, but I do not remember coming to consensus on allowing "repositioning" to meet the trigger visibility condition, especially not in the way of the SharePoint tile example which requires a specific mouse position to achieve. Taking that example to something a bit more visually challenging, how is it accessible to me if I need to zoom to the bottom half of a picture, but my mouse needs to be on the top half to keep the tooltip out of the way, making it impossible to view since the mouse can't go off screen? This is a giant loophole, and I don't understand why we are creating it given that it is simple to implement one of the 2 original conditions (i.e. don't obscure or let me clear it). I didn't hear why that was such a concern. We're going to get so many questions on what that actually means, reposition how and to what extent (is 1 pixel okay?), and the only answer is that we needed to add it to make a SharePoint tile pass 2.1. The only change we agreed to make was to be more general about the action a user can take to dismiss the content and not limit to keyboard (e.g. clicking the tooltip).

"Visual presentation" was dropped to "presentation", which drew comments that all presentation is done by the user agent in a sense. Adding visual is minor, but is consistent with uses already in WCAG 2.0 and seemed to satisfy other members.

Fine with me.

The bullets now refer to "trigger" and "additional content", but neither term is used in the sentence above the list which needs to define them. Several commenters wanted a clear definition of trigger and its relationship to the popup or additional content. I recommend sticking with something similar to what I originally proposed.

I'll take a look at this.

You've limited the trigger to being a user interface component, which I don't understand. Generally, the WCAG definition of UI components favors "clickable" things that perform a function, which is not always the case here. Think of an image showing a custom tooltip or a menu where the top level item is not a link. Recommend going back to trigger content.

The definition of User interface Component is "a part of the content that is perceived by users as a single control for a distinct function" and that seems to describe this accurately. It is highly desirable to use existing definitions where ever we can.

I'm not sure what was discussed after I needed to drop off, but I do not remember coming to consensus on allowing "repositioning" to meet the trigger visibility condition, especially not in the way of the SharePoint tile example which requires a specific mouse position to achieve. Taking that example to something a bit more visually challenging, how is it accessible to me if I need to zoom to the bottom half of a picture, but my mouse needs to be on the top half to keep the tooltip out of the way, making it impossible to view since the mouse can't go off screen? This is a giant loophole, and I don't understand why we are creating it given that it is simple to implement one of the 2 original conditions (i.e. don't obscure or let me clear it). I didn't hear why that was such a concern. We're going to get so many questions on what that actually means, reposition how and to what extent (is 1 pixel okay?), and the only answer is that we needed to add it to make a SharePoint tile pass 2.1. The only change we agreed to make was to be more general about the action a user can take to dismiss the content and not limit to keyboard (e.g. clicking the tooltip).

If the new content is a modal dialog box, it may be large and users may need to use it, so it is critical that repositioning is allowed.

For the tooltip case, I think that the requirement for keyboard users makes the reality of not obscuring the content very much in line with what you want. Keyboard users need a way to clear the additional content and they can't adjust the position of the keyboard focus, so they will need to be able to dismiss the content and the mouse users will be able to use the same functionality.

If the new content is a modal dialog box, it may be large and users may need to use it, so it is critical that repositioning is allowed.

If the new content is a modal dialog box then it isn't covered by this SC, because:

• I've never come across a modal dialog that was triggered by hover/focus.
• It does not disappear when you move the mouse away or focus on the next item.

I'd describe that as a change of context, because the page you (were) on is blanked-out / blocked from use until the dialog is dealt with.

If you mean a non-modal dialogue, then I think it should be positioned next to the trigger (like a drop-down menu), and the SC can apply.

The first bit's readability confused me a bit, there are two "when"s.

Could that be:

For content that becomes visible when triggered by a user interface component receiving keyboard focus or pointer hover, the following are true, except where the visual presentation of the content is controlled by the user agent and is not modified by the author:

Visible trigger
Either the additional content does not obscure any essential content within the triggering user interface component, or the additional content can be closed or repositioned by the user.

Hover
The additional content remains visible when the pointer is moved over it, if it was triggered via pointer hover

Focus
The additional content remains visible while the triggering user interface component has keyboard focus, unless the user dismisses the additional content.

How does reading the content relates to moving the mouse?
You may have to move the mouse to put the tooltip in view in a zoomed or magnified environment.

The definition of User interface Component is "a part of the content that is perceived by users as a single control for a distinct function" and that seems to describe this accurately. It is highly desirable to use existing definitions where ever we can.

"Content" is also an existing definition, and I disagree that user interface component is more applicable given the other ways it is used in WCAG (e.g. 4.1.2 Name, Role, Value). An image, a heading, or a paragraph can all be triggers here, so the argument would have to be that these are not UI components, but if they show more content on hover or have a title attribute, then they become UI components? I doubt there would be consensus on that. Another example would be understanding the new UI Component Contrast SC - is a heading with a tooltip supposed to meet the text contrast requirements or the ones in the new SC? The lexical game here is completely unnecessary. Any content can be a trigger and the SC should be clear to cover all of it.

If the new content is a modal dialog box, it may be large and users may need to use it, so it is critical that repositioning is allowed.

As has been pointed out, this SC cannot possibly cover anything that is modal because it would fail 3.2.1. And even if it did, I have no idea what user problem you are talking about. Modals by definition take focus, and thus a magnified view will more than likely be shifted to it to deal with. Modals can obscure anything they want and that's desirable from a low vision perspective so it's clear what I have to interact with next.

For the tooltip case, I think that the requirement for keyboard users makes the reality of not obscuring the content very much in line with what you want. Keyboard users need a way to clear the additional content and they can't adjust the position of the keyboard focus, so they will need to be able to dismiss the content and the mouse users will be able to use the same functionality.

I'm not sure I understand how this addresses my concerns with "repositioning" being allowed to satisfy the trigger visibility condition. Can you please clarify?

OK, so first to update you and others on the call today. The WG agreed on the SC moving to the editor's draft.

More responses:

"Content" is also an existing definition, and I disagree that user interface component is more applicable given the other ways it is used in WCAG (e.g. 4.1.2 Name, Role, Value). An image, a heading, or a paragraph can all be triggers here, so the argument would have to be that these are not UI components, but if they show more content on hover or have a title attribute, then they become UI components? I doubt there would be consensus on that. Another example would be understanding the new UI Component Contrast SC - is a heading with a tooltip supposed to meet the text contrast requirements or the ones in the new SC? The lexical game here is completely unnecessary. Any content can be a trigger and the SC should be clear to cover all of it.

A UI component is "a part of the content that is perceived by users as a single control for a distinct function". How is that not accurate here?

Regarding the contrast requirement, if there is text in the UI component it needs to meet the existing SC, and if it is an image or otherwise covered by the new SC then it needs to work with that.

As has been pointed out, this SC cannot possibly cover anything that is modal because it would fail 3.2.1. And even if it did, I have no idea what user problem you are talking about. Modals by definition take focus, and thus a magnified view will more than likely be shifted to it to deal with. Modals can obscure anything they want and that's desirable from a low vision perspective so it's clear what I have to interact with next.

Typo. I meant non-modal.

I'm not sure I understand how this addresses my concerns with "repositioning" being allowed to satisfy the trigger visibility condition. Can you please clarify?

Sure. The tooltip/additional content might be a non-modal dialog that needs to be able to remain and be able to be moved out of the way, so it makes sense to have that. Similarly, other "additional content" could be repositioned in more custom ways (e.g. on windows there is a "move" item in window menus, and yes, that isn't on hover, but just as an example of how content could be repositioned). If we were to say that moving the mouse to another part of the triggering component counted then we would need to also provide a way to accomplish that type of movement from the keyboard (per 2.1.1).

I think that the reality is (and I checked with some developers here today as part of my validating this) that most ttooltip/overlay widgets are going to implement a keyboard shortcut to dismiss the content AND will also make it super easy to avoid overlapping the trigger component.

Does that help?

A UI component is "a part of the content that is perceived by users as a single control for a distinct function". How is that not accurate here?

I see Steve's point that pop-ups can be triggered by things that are not (seen as) link/controls, however, I'd argue the addition of a mouse-over or on-focus event makes the thing a control. At least enough for this purpose.

If we were to say that moving the mouse to another part of the triggering component counted then we would need to also provide a way to accomplish that type of movement from the keyboard (per 2.1.1).

The technique for that I'd recommend is putting the additional content next in the source-order. You could take a more complex approach (and might need to for non-markup languages), but that would be straightforward to do, I can think of a couple of clients with pop-up help text on forms that already do it that way without our persuasion/interference.

Regarding @steverep's point on repositioning:

how is it accessible to me if I need to zoom to the bottom half of a picture, but my mouse needs to be on the top half to keep the tooltip out of the way, making it impossible to view since the mouse can't go off screen?

I don't think the 1st bullet undermines the 2nd, if "that content remains visible when the pointer is moved over it", you can view both the trigger and the content without loosing the content.

If that content can then be moved, that's fine, it's optional for the user.

@alastc and @awkawk, mixing quotes but grouping topics here:

Repositioning

I don't think the 1st bullet undermines the 2nd, if "that content remains visible when the pointer is moved over it", you can view both the trigger and the content without loosing the content. If that content can then be moved, that's fine, it's optional for the user.

Perhaps I didn't explain the example very well. The impetus for allowing repositioning was the SharePoint example of the tooltip being positioned relative to the pointer. Simplifying that particular example, imagine a tooltip which displays on top of the Mona Lisa dependent on my pointer position. If the pointer is on the top half, I get a tooltip on top and vice versa for the bottom. Now, you could argue I can "reposition" it, but I cannot view an unobscured trigger when magnified, especially if I'm zoomed to see either the top or bottom half.

I think that the reality is (and I checked with some developers here today as part of my validating this) that most ttooltip/overlay widgets are going to implement a keyboard shortcut to dismiss the content AND will also make it super easy to avoid overlapping the trigger component. Does that help?

Yes, I completely agree that developing to not obscure and/or allow simple dismissal is much easier than creating a repositioning mechanism. I'm not against repositioning, I just think the parameters need to be defined. How about this:

• Either the additional content does not obscure any essential content within the triggering content, the additional content can be dismissed by the user, or the additional content can be positioned by the user to not obscure essential content of the trigger without requiring a specific pointer position.

That defines what the user would need much better in terms of positioning.

UI Component vs. Content

I see Steve's point that pop-ups can be triggered by things that are not (seen as) link/controls, however, I'd argue the addition of a mouse-over or on-focus event makes the thing a control. At least enough for this purpose.

The fact that such an argument needs to be made is my point. Why bother taking the risk that everyone will understand it that way? I certainly do not given the ways UI component is currently used in WCAG:

1. Contrast (1.4.3) has an exception for text as part of n inactive UI component. So does that mean text is not active unless its hover event is showing and therefore has no contrast requirement?
2. On Input (3.2.2) refers to the setting of a UI component. Is information being shown on hover a setting?
3. Name, Role, Value (4.1.2) of course is scoped only to UI components. So, does this now apply to a paragraph with a hover event? What would be the way to define its role? We could then use this to our advantage to require role="img" on font icons simply by adding a tooltip to them.

Keep in mind, too, that since the title attribute produces a tooltip, its content is thus a triggering UI component.

Ultimately this comes back to risk vs. reward. The risk of using UI component is confusion and interpretation as a subset of content types. What's the reward for using UI component, and what's the risk of being inclusive and saying content?

Perhaps I didn't explain the example very well. The impetus for allowing repositioning was the SharePoint example of the tooltip being positioned relative to the pointer. Simplifying that particular example, imagine a tooltip which displays on top of the Mona Lisa dependent on my pointer position. If the pointer is on the top half, I get a tooltip on top and vice versa for the bottom. Now, you could argue I can "reposition" it, but I cannot view an unobscured trigger when magnified, especially if I'm zoomed to see either the top or bottom half.

I don't think that this extra language is needed. When the position of the additional content is determined for placement with keyboard focus the same process will be used for placement on hover in most cases, and due to 2.1.1 that content shown on hover will need to be shown from the keyboard, which means that there will need to be a keyboard method (e.g. hitting esc to dismiss) as well as a pointer-based way to dismiss it. If someone tried to say that you could reposition the content by changing the position of the pointer on the trigger they would still fail unless they provided the keyboard-based way to do this and once they have they would be providing a way for pointer users also.

Someone could allow the user to drag a tooltip around also, but that is just one possible technique.

The fact that such an argument needs to be made is my point. Why bother taking the risk that everyone will understand it that way? I certainly do not given the ways UI component is currently used in WCAG:

In this discussion at one point I tried to make a point by asking what about a situation where as soon as you tab to something in the tab order that an alert (modal) pops up. I was rightly reminded that doing so would fail 3.2.1 ("When any component receives focus, it does not initiate a change of context."). So are you saying that since some focusable objects are not components that this type of behavior would be ok? I'm sure you aren't!

Ultimately this comes back to risk vs. reward. The risk of using UI component is confusion and interpretation as a subset of content types. What's the reward for using UI component, and what's the risk of being inclusive and saying content?

The reward is that we are referring to an actionable item for what it is, and we already have a definition for it.

For name/role/value it is important to recognize that depending on the type of component one or more of these might be achieved with no additional effort. The role of a paragraph with focus/hover is "text" and it is set automatically.

I think that it is worth putting it out as it is and we will see if we get any feedback that makes us think more about this, and we will be able to revisit it. If we debate it too much longer, we will take away from other items or risk missing the August 22 date entirely.

I don't think that this extra language is needed. When the position of the additional content is determined for placement with keyboard focus the same process will be used for placement on hover in most cases, and due to 2.1.1 that content shown on hover will need to be shown from the keyboard, which means that there will need to be a keyboard method (e.g. hitting esc to dismiss) as well as a pointer-based way to dismiss it. If someone tried to say that you could reposition the content by changing the position of the pointer on the trigger they would still fail unless they provided the keyboard-based way to do this and once they have they would be providing a way for pointer users also.
Someone could allow the user to drag a tooltip around also, but that is just one possible technique.

I agree, there is important interweaving with 2.1.1 and other criteria that deserves attention in Understanding. This covers the method of positioning though, rather than my issue with specifying the extents of the positioning. We need to say that it must be able to be positioned off the trigger so I can see it. And if it requires a specific pointer position, e.g. off the trigger while I'm operating the location with keyboard, then that's a problem.

So are you saying that since some focusable objects are not components that this type of behavior would be ok?

Of course I'm not, but 3.2.1 (on purpose or not) does not use "user interface component" and link to the glossary so I'd say that's not an issue. And does the argument work in reverse? If we say the trigger is "content", that does not exclude it from 3.2.1 at all.

I think that it is worth putting it out as it is and we will see if we get any feedback that makes us think more about this, and we will be able to revisit it. If we debate it too much longer, we will take away from other items or risk missing the August 22 date entirely.

First, the feedback is already coming from me as a working group member and someone who understands this situation from a user perspective very well as I live with it every day. Second, I'm not going to feel bad about taking time to discuss this because we're in a hurry, and the same argument applies for arguing against my suggested edits. The process broke down a little here since both surveys used "content" and neither had a response asking it to be changed to "user interface component". With the exception of using "popup", most approved already.

I agree, there is important interweaving with 2.1.1 and other criteria that deserves attention in Understanding. This covers the method of positioning though, rather than my issue with specifying the extents of the positioning. We need to say that it must be able to be positioned off the trigger so I can see it. And if it requires a specific pointer position, e.g. off the trigger while I'm operating the location with keyboard, then that's a problem.

I'm not understanding what is missing - we are saying that the additional content needs to not obscure the trigger, but as we've discussed there are cases where that may not be possible, so if obscuring the trigger area is necessary then the user needs to be able to close or reposition the additional content. If the additional content is large enough it may not be possible to position it off of all additional content, in which case the user might move the content a couple of times. For example, if there is a huge image of the mona lisa and the additional content provides extra information but always covers some of the image of the painting then that content will always be in the way but at least the user can move it around or close it.

Of course I'm not, but 3.2.1 (on purpose or not) does not use "user interface component" and link to the glossary so I'd say that's not an issue. And does the argument work in reverse? If we say the trigger is "content", that does not exclude it from 3.2.1 at all.

Actually, 3.2.1 does say that because we agreed that this was an error and it is in the WCAG 2.0 errata document: https://www.w3.org/WAI/WCAG20/errata/

First, the feedback is already coming from me as a working group member and someone who understands this situation from a user perspective very well as I live with it every day. Second, I'm not going to feel bad about taking time to discuss this because we're in a hurry, and the same argument applies for arguing against my suggested edits. The process broke down a little here since both surveys used "content" and neither had a response asking it to be changed to "user interface component". With the exception of using "popup", most approved already.

I'm not trying to make you feel bad about anything. In the survey, we reference the github version, and after Alex, Jim, you and me had a chance to talk I updated the github version and sent a note to the list to indicate that people should review it and update their responses.

I'm not understanding what is missing - we are saying that the additional content needs to not obscure the trigger, but as we've discussed there are cases where that may not be possible, so if obscuring the trigger area is necessary then the user needs to be able to close or reposition the additional content. If the additional content is large enough it may not be possible to position it off of all additional content, in which case the user might move the content a couple of times. For example, if there is a huge image of the mona lisa and the additional content provides extra information but always covers some of the image of the painting then that content will always be in the way but at least the user can move it around or close it.

Hmm... This response makes me think we're reading the criterion 2 verydifferent ways because I think you are implying that "close or reposition" is one single option... Is that right? I read this as 3 options to satisfy the trigger visibility condition:

1. Don't obscure in the first place
2. Allow me to quickly close it
3. Allow it to be repositioned

And I'm simply arguing that option 3 has no guarantee to make the trigger visible, so it needs clarification on what that positioning must accomplish, which is to not obscure the trigger. If that's impossible, then options 1 or 2 are the way to go.

I think you are implying that "close or reposition" is one single option... Is that right? I read this as 3 options to satisfy the trigger visibility condition:
Don't obscure in the first place
Allow me to quickly close it
Allow it to be repositioned

I think that we are reading it the same way, and even if "close or reposition" was one item that was an "or" to the option of not obscuring it in the first place then it would still come out as three items because there is an "or" between everything.

Your question makes me wonder if you are viewing the three options as "and's" where an author needs to do all three.

My view is that if an author makes additional text appear on hover/focus that:

1. If the content doesn't obscure the trigger it passes this part, even if it can't be closed or repositioned
2. if the content obscures the trigger and the user can close but not reposition it, it passes this part
3. if the content obscures the trigger and the user can reposition it but not close it, it passes this part.

Is that in line with your understanding?

Is that in line with your understanding?

Yes. So all I'm asking is that we state the conditions that need to be met by option 3 in order to successfully see the trigger content, rather than just accepting any repositioning. Those are:

1. It must be able to be positioned off any essential content of the trigger
2. It must not require a specific mouse position in order to see the trigger (pertinent if the additional content always follows the mouse pointer)

Can we not make that change?

Yes. So all I'm asking is that we state the conditions that need to be met by option 3 in order to successfully see the trigger content, rather than just accepting any repositioning. Those are:

It must be able to be positioned off any essential content of the trigger
It must not require a specific mouse position in order to see the trigger (pertinent if the additional
content always follows the mouse pointer)

I'm not sure that we should say off any essential content, because if the essential content is the entire view or very nearly so then it might be that the additional content needs to be moved to expose some content but it then obscures other content.

For the second item, I'm not sure what you mean by follow the mouse cursor - if the additional content follows the mouse cursor then the mouse user won't be able to move their mouse point on top of that content, so that would be a problem in the second part.

I'm not sure that we should say off any essential content, because if the essential content is the entire view or very nearly so then it might be that the additional content needs to be moved to expose some content but it then obscures other content.

Then it doesn't satisfy the user needs, so why would we say it's one of the acceptable options? In that situation, there's no real implementation issue with using option 2 to close it instead.

For the second item, I'm not sure what you mean by follow the mouse cursor - if the additional content follows the mouse cursor then the mouse user won't be able to move their mouse point on top of that content, so that would be a problem in the second part.

You're right, poorly stated on my part. I meant where the "target" is really broken up into smaller hover regions, and the initial position may be dictated by what region is hovered. if we are clear to note that these would be considered separate targets, each having to satisfy the SC, then there's no issue.

Then it doesn't satisfy the user needs, so why would we say it's one of the acceptable options? In that situation, there's no real implementation issue with using option 2 to close it instead.

It seems like this doesn't solve the user need in one fell swoop as nicely as one might want, but in a situation where the target is very large, and the additional content is important to access the user might need more than to just be able to close the content. If all they can do is close the content then it could be always positioned over a part of the target that the developer believes is less essential but that the user needs. Being able to reposition the content so that it exposes some content but hides other content might be needed. I'm thinking about something like a mapping application, where the entire map is likely to be regarded as essential, but since the user can reposition the obscuring content it is still functional.

if we are clear to note that these would be considered separate targets, each having to satisfy the SC, then there's no issue.

The problem with thinking about there being different targets on one button will make it confusing to indicate what the bounds of that target are and therefore what the essential content for that target is.

It seems like this doesn't solve the user need in one fell swoop as nicely as one might want, but in a situation where the target is very large, and the additional content is important to access the user might need more than to just be able to close the content. If all they can do is close the content then it could be always positioned over a part of the target that the developer believes is less essential but that the user needs. Being able to reposition the content so that it exposes some content but hides other content might be needed. I'm thinking about something like a mapping application, where the entire map is likely to be regarded as essential, but since the user can reposition the obscuring content it is still functional.

What you're describing is essentially a palette window where the additional content has tools or something else I need to interact with to use the target content behind it. I'd say that type of thing is mostly out of scope since it is unlikely to appear only on hover or focus, but more importantly the accessible thing to do is to allow me to choose if it is there or not. This example loses sight of the goal of seeing the target. The importance of the additional content is totally irrelevant.

What is most troublesome to me is that this SC was meant to benefit users with low vision or low pointer accuracy in general, and that example is exactly the kind of thing we are trying to prevent. It is not an easy task for these users to move things around on screen, and it's even harder for them to be expected to put pieces of a puzzle together visually as they do it. Calling that accessible is not accurate when in fact it's closer to a nightmare.

If there truly is a good reason why content only on hover or focus needs to obscure what triggered it with no option for user dismissal (and I have yet to hear it), then it should be formulated as an exception.

@steverep and/or @allanj-uaag as your time permits, what do y'all think about changing the title of this issue to match the current name in WCAG 2.1...which I think is "Content on Hover or Focus". Also, it would be awesome to update that SC Shortname in the very first comment.

I'm trying to make it easy to see all the issues in github (that have become proposed SC in WCAG 2.1 public working draft).

@goodwitch I think the intent was to preserve the original name and content so that past comments made sense. There are direct links to the current wording at the top of the issue. i guess we could consider "Content on Hover or Focus (previously Popup Visibility)"