This repository has been archived by the owner. It is now read-only.

Content on Hover or Focus (formerly Popup Visibility/Interference) #75

Closed
allanj-uaag opened this Issue Dec 1, 2016 · 123 comments

Comments

@allanj-uaag
Contributor

allanj-uaag commented Dec 1, 2016

Current versions of SC and Definitions

SC Shortname

Popup Visibility

SC Text

The following are true when a popup becomes visible, except where the visual presentation of the popup is controlled by the user agent and is not modified by the author:

  • Trigger: Either the popup does not obscure any essential content within the trigger, or the popup can be closed via a standard keyboard exit method, such as the escape key.
  • Hover: If the popup is triggered via pointer hover, then the pointer may be moved onto the popup without loss of popup visibility.
  • Focus: The popup remains visible while the trigger or any popup component has keyboard focus, unless the user takes an explicit action to close the popup.

Suggested Priority Level

Level AA

Related Glossary additions or changes

  • popup (and trigger): content which becomes visible only when associated content, called the trigger, gains keyboard focus or pointer hover

What Principle and Guideline the SC falls within.

Principle 1: Perceivable, Guideline 1.4: Distinguishable

Description

Popup content that appears only on focus or mouse hover can present many challenges for users with low vision and others whose mouse accuracy may be low. Techniques can be employed to successfully perceive and interact with popups as long as certain conditions are met when a popup is displayed.

First, if a popup is positioned to cover all or part of its triggering content, then the trigger can become much more difficult to perceive under magnification. In this situation, screen area that doesn't trigger the popup may be the minority, resulting in a difficult cycle to pan the screen without re-triggering the popup. The solution is to always position the popup adjacent to its trigger.

Next, a popup can be difficult or impossible to perceive if a user is required to keep their mouse pointer over the trigger. For large popups, magnified views may mean that the user needs to scroll or pan to completely view the popup, which is impossible unless the user is able to move their pointer off the trigger without the popup disappearing. Another common situation is when large pointers have been selected via platform settings or assistive technology. Here, the pointer can obscure a significant area of the popup. A technique to view the popup fully in both situations is to move the mouse pointer onto the popup itself. Ensuring this capability also offers advantages for users who utilize screen reader feedback on mouse interactions.

Finally, when a popup contains user interface components that can gain focus, a user technique can be employed to move focus onto the popup. As long as the popup remains displayed, the view can then be magnified, scrolled, or panned for optimal perception without regard to mouse position over the content. For popups with multiple clickable items, this also offers the advantage of being able to make and correct a clicking mistake without losing visibility of the popup.

This criterion does not attempt to solve such issues when the appearance of the popup is completely controlled by the user agent. A prominent example is the common behavior of browsers to display the title attribute in HTML as a small tooltip.

Additional notes to be clarified in Understanding:

  1. Dialogs cannot be popups because they would fail SC 3.2.1, On Focus, by gaining focus on only focus or hover.
  2. Add more detail to exception (basically when code is supplied but no styling).
  3. Explain that proximity is implied by hover condition.
  4. Add language to explain exception for focus condition when user has dismissed the popup and trigger still has focus.
  5. Explain that whitespace within the trigger is okay to obscure (only essential content).
  6. Explain rationale on allowing ESC to close popup.

Benefits

  1. Users who increase the size of mouse cursors via platform settings or assistive technology.
  2. Users who view content under magnification.
  3. Users with low mouse cursor accuracy due to low vision, motor impairment, etc.

Testability

For each possible popup on the webpage, check that:

  1. The triggering content is not obscured when the popup is visible
  2. Display the popup via hover if possible, and ensure the pointer can be moved onto the popup without loss of visibility.
  3. If the popup contains user interface components, then move focus to each to ensure the popup remains visible.

All must be true to pass.

Techniques

Related Existing Techniques

New Techniques

  • Positioning popups adjacent to triggering content (CSS)
  • Ensuring popups remain visible on hover or focus (CSS and JavaScript)
  • Using static content instead of popups for important information or controls
  • Using a JavaScript / CSS to provide a popup that works on hover and focus that does not cover other content
  • Using onclick (accessible to keyboard and touch devices) to show popup content

Support Material

The Low Vision Task Force wiki on Popup Interference contains a wealth of additional information and background.

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Dec 26, 2016

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

goetsu commented Dec 26, 2016

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

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 26, 2016

Contributor

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.

Contributor

alastc commented Dec 26, 2016

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.

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Dec 27, 2016

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.

goetsu commented Dec 27, 2016

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.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 3, 2017

Contributor

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

Contributor

lauracarlson commented Jan 3, 2017

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

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Jan 3, 2017

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

goetsu commented Jan 3, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

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.

Contributor

mbgower commented Jan 6, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

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.

Contributor

mbgower commented Jan 6, 2017

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.

@awkawk awkawk changed the title from Metadata On Hover - Ready for Review to Metadata On Hover Jan 9, 2017

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jan 20, 2017

Contributor

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.

Contributor

detlevhfischer commented Jan 20, 2017

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.

@joshueoconnor joshueoconnor assigned WayneEDick and unassigned alastc Feb 5, 2017

@awkawk awkawk changed the title from Metadata On Hover to Popup Interference Feb 27, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 27, 2017

Member

Updated the issue description to reflect the FPWD text.

Member

awkawk commented Feb 27, 2017

Updated the issue description to reflect the FPWD text.

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Apr 11, 2017

Contributor

April 11

Test for addressing.

Contributor

WayneEDick commented Apr 11, 2017

April 11

Test for addressing.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jun 11, 2017

Contributor

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...
Contributor

lauracarlson commented Jun 11, 2017

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...
@lauracarlson
Contributor

lauracarlson commented Jun 11, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@Marla262

This comment has been minimized.

Show comment
Hide comment
@Marla262

Marla262 Jun 18, 2017

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 -
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

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 5, 2017

Contributor

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

Contributor

lauracarlson commented Jul 5, 2017

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

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jul 6, 2017

Contributor

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

Contributor

WayneEDick commented Jul 6, 2017

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

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Jul 6, 2017

Contributor
Contributor

allanj-uaag commented Jul 6, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 7, 2017

Contributor

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

Contributor

lauracarlson commented Jul 7, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 7, 2017

Contributor

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?

Contributor

mbgower commented Jul 7, 2017

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?

@steverep steverep assigned steverep and unassigned WayneEDick Jul 27, 2017

steverep added a commit that referenced this issue Jul 27, 2017

Major revision to Popup Interference
Scopes issue #75 to key problem scenarios involving popups.
@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jul 28, 2017

Member

This criterion has been significantly revised and accepted by the Low Vision Task Force. New criterion language with a completely rewritten description, and other pertinent sections is in place. Please take a fresh look. Thanks.

Member

steverep commented Jul 28, 2017

This criterion has been significantly revised and accepted by the Low Vision Task Force. New criterion language with a completely rewritten description, and other pertinent sections is in place. Please take a fresh look. Thanks.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 28, 2017

Contributor

Dissecting new wording...

Except where popup presentation is controlled by the user agent, all of the following are true when popup content is visible:

So I assume this is worded like this to ignore Title hover behaviour of the user agent. That can likely be clarified in the Understanding document. The obvious counter to this wording is that the presentation of everything is controlled by the user agent. Would 'popup behaviour' be more precise?

Interesting notion of only covering "When popup content is visible"!


-Trigger: Popup content does not obscure any part of its triggering content.

By "triggering content" I assume you mean whatever div, button or whatever contains the trigger for the popup. I'm slightly concerned that anything on the source page could be construed as 'triggering content'. Is there a reason "triggering element" or just "trigger" wasn't used? I assume trigger will be or is already defined.


-Hover: If a popup is triggered via pointer hover, then the pointer may be moved onto the popup content without loss of visibility.

Can you explain the purpose, both of "move" and "visibility"? Are you saying that as a user removes the pointer from over the trigger and onto the newly dispayed content, the new content must persist? If so, are there instances where a user would expect it to disappear when leaving the trigger, which may be harmed by this? I assume this is to address the use of magnification, where someone would need to move the viewport to read the popup text? I do have slight concerns that non-interactive popups normally disappear as soon as the trigger no longer meets onhover.
I assume by "visibility" you mean without the popup information going away. But there have been concepts around obscuring info, that this could also be driving at. Please clarify and consider slight rewording.


-Focus: Popup content remains visible while any of its components, including the trigger, have focus.

Hmm, I see some issues with this, especially if we are not very clear to distinguish between 'popup' and 'dialog'. Here's the scenario: If one assumes one can dismiss this new information by pressing ESC, which I suspect would be an acceptable implementation especially for a keyboard use, then when it disappeared, the trigger item still has focus, which immediately seems to fail the SC.
I think this "Focus" bullet needs more consideration.

Contributor

mbgower commented Jul 28, 2017

Dissecting new wording...

Except where popup presentation is controlled by the user agent, all of the following are true when popup content is visible:

So I assume this is worded like this to ignore Title hover behaviour of the user agent. That can likely be clarified in the Understanding document. The obvious counter to this wording is that the presentation of everything is controlled by the user agent. Would 'popup behaviour' be more precise?

Interesting notion of only covering "When popup content is visible"!


-Trigger: Popup content does not obscure any part of its triggering content.

By "triggering content" I assume you mean whatever div, button or whatever contains the trigger for the popup. I'm slightly concerned that anything on the source page could be construed as 'triggering content'. Is there a reason "triggering element" or just "trigger" wasn't used? I assume trigger will be or is already defined.


-Hover: If a popup is triggered via pointer hover, then the pointer may be moved onto the popup content without loss of visibility.

Can you explain the purpose, both of "move" and "visibility"? Are you saying that as a user removes the pointer from over the trigger and onto the newly dispayed content, the new content must persist? If so, are there instances where a user would expect it to disappear when leaving the trigger, which may be harmed by this? I assume this is to address the use of magnification, where someone would need to move the viewport to read the popup text? I do have slight concerns that non-interactive popups normally disappear as soon as the trigger no longer meets onhover.
I assume by "visibility" you mean without the popup information going away. But there have been concepts around obscuring info, that this could also be driving at. Please clarify and consider slight rewording.


-Focus: Popup content remains visible while any of its components, including the trigger, have focus.

Hmm, I see some issues with this, especially if we are not very clear to distinguish between 'popup' and 'dialog'. Here's the scenario: If one assumes one can dismiss this new information by pressing ESC, which I suspect would be an acceptable implementation especially for a keyboard use, then when it disappeared, the trigger item still has focus, which immediately seems to fail the SC.
I think this "Focus" bullet needs more consideration.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jul 28, 2017

Member

So I assume this is worded like this to ignore Title hover behaviour of the user agent. That can likely be clarified in the Understanding document.

Yes, see the last paragraph of the new description above.

The obvious counter to this wording is that the presentation of everything is controlled by the user agent. Would 'popup behaviour' be more precise?

True, but "presentation" is used purposely to coincide with the WCAG glossary definition. The distinction is that the author may control the content (i.e. the code of the title), but not the presentation of it visually. Perhaps an adverb like "completely" or "entirely" would solidify the intent better? Although the author may choose to omit styling, they certainly have great control over presentation of other content.

Interesting notion of only covering "When popup content is visible"!

Are you suggesting to remove this? In reality the bullets cannot be tested unless a popup is triggered, so that would need to be clarified on every bullet if removed.

I'm slightly concerned that anything on the source page could be construed as 'triggering content'.

Your interpretation of the triggering content is of course correct. You don't think "its trigger" covers this to separate it from just any other element on the page?

Here's the scenario: If one assumes one can dismiss this new information by pressing ESC, which I suspect would be an acceptable implementation especially for a keyboard use, then when it disappeared, the trigger item still has focus, which immediately seems to fail the SC.

Good point. So long as focus moves onto the dialog when it pops up, that's accessible. I think removing "including the trigger" may solve this and still meet user requirements. I'll sleep on that notion. I think it was included for a reason that is escaping me right now.

Can you explain the purpose, both of "move" and "visibility"? Are you saying that as a user removes the pointer from over the trigger and onto the newly dispayed content, the new content must persist? If so, are there instances where a user would expect it to disappear when leaving the trigger, which may be harmed by this? I assume this is to address the use of magnification, where someone would need to move the viewport to read the popup text? I do have slight concerns that non-interactive popups normally disappear as soon as the trigger no longer meets onhover.
I assume by "visibility" you mean without the popup information going away. But there have been concepts around obscuring info, that this could also be driving at. Please clarify and consider slight rewording.

Please take a look at the new description which explains the user's problematic scenarios. The first is magnification as you suspected, another is a large pointer, and finally it allows for screen reading using the mouse. As far as the expectation of losing visibility once the trigger is no longer hovered, it would be nice to see strong evidence of the harm done by allowing it to persist. The harm of not doing so is possibly a total inability to perceive it. Previous versions regarding obscuring other information were re-considered by the LVTF, but in reality, the best author practice for people with low vision is to not put anything in a popup at all, which would certainly be a "sufficient" technique here. I think we were trying to find a more compromising position than completely outlawing popups.

Member

steverep commented Jul 28, 2017

So I assume this is worded like this to ignore Title hover behaviour of the user agent. That can likely be clarified in the Understanding document.

Yes, see the last paragraph of the new description above.

The obvious counter to this wording is that the presentation of everything is controlled by the user agent. Would 'popup behaviour' be more precise?

True, but "presentation" is used purposely to coincide with the WCAG glossary definition. The distinction is that the author may control the content (i.e. the code of the title), but not the presentation of it visually. Perhaps an adverb like "completely" or "entirely" would solidify the intent better? Although the author may choose to omit styling, they certainly have great control over presentation of other content.

Interesting notion of only covering "When popup content is visible"!

Are you suggesting to remove this? In reality the bullets cannot be tested unless a popup is triggered, so that would need to be clarified on every bullet if removed.

I'm slightly concerned that anything on the source page could be construed as 'triggering content'.

Your interpretation of the triggering content is of course correct. You don't think "its trigger" covers this to separate it from just any other element on the page?

Here's the scenario: If one assumes one can dismiss this new information by pressing ESC, which I suspect would be an acceptable implementation especially for a keyboard use, then when it disappeared, the trigger item still has focus, which immediately seems to fail the SC.

Good point. So long as focus moves onto the dialog when it pops up, that's accessible. I think removing "including the trigger" may solve this and still meet user requirements. I'll sleep on that notion. I think it was included for a reason that is escaping me right now.

Can you explain the purpose, both of "move" and "visibility"? Are you saying that as a user removes the pointer from over the trigger and onto the newly dispayed content, the new content must persist? If so, are there instances where a user would expect it to disappear when leaving the trigger, which may be harmed by this? I assume this is to address the use of magnification, where someone would need to move the viewport to read the popup text? I do have slight concerns that non-interactive popups normally disappear as soon as the trigger no longer meets onhover.
I assume by "visibility" you mean without the popup information going away. But there have been concepts around obscuring info, that this could also be driving at. Please clarify and consider slight rewording.

Please take a look at the new description which explains the user's problematic scenarios. The first is magnification as you suspected, another is a large pointer, and finally it allows for screen reading using the mouse. As far as the expectation of losing visibility once the trigger is no longer hovered, it would be nice to see strong evidence of the harm done by allowing it to persist. The harm of not doing so is possibly a total inability to perceive it. Previous versions regarding obscuring other information were re-considered by the LVTF, but in reality, the best author practice for people with low vision is to not put anything in a popup at all, which would certainly be a "sufficient" technique here. I think we were trying to find a more compromising position than completely outlawing popups.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jul 28, 2017

Contributor

First glance looks not bad... no band width to dig deep this week... unfortunately it can't fix the main problem, which is the title attribute.

Contributor

DavidMacDonald commented Jul 28, 2017

First glance looks not bad... no band width to dig deep this week... unfortunately it can't fix the main problem, which is the title attribute.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 28, 2017

Contributor

@DavidMacDonald wrote:

unfortunately it can't fix the main problem, which is the title attribute.

+1

Laura

Contributor

lauracarlson commented Jul 28, 2017

@DavidMacDonald wrote:

unfortunately it can't fix the main problem, which is the title attribute.

+1

Laura

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 28, 2017

Contributor

@steverep

Interesting notion of only covering "When popup content is visible"!

Are you suggesting to remove this? In reality the bullets cannot be tested unless a popup is triggered, so that would need to be clarified on every bullet if removed.

No, I meant I thought it was a clever approach 👍

Contributor

mbgower commented Jul 28, 2017

@steverep

Interesting notion of only covering "When popup content is visible"!

Are you suggesting to remove this? In reality the bullets cannot be tested unless a popup is triggered, so that would need to be clarified on every bullet if removed.

No, I meant I thought it was a clever approach 👍

steverep added a commit that referenced this issue Jul 29, 2017

Add trigger language to definition of popup
Addresses comments on #75 to better explain the relationship between a trigger and its popup

steverep added a commit that referenced this issue Jul 29, 2017

Specify loss of visibility applies to the popup
Addresses a comment for #75 that the "loss of visibility" is ambiguous.  Also added link to presentation definition.
@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 9, 2017

Member

All,

It's becoming way too clear that there is not a term that everyone is going to agree on here. Given many folks being confused about clicks and modes, we could be more verbose and call it a "no-click nonmodal popup", but that seems pretty crazy. So, here's my attempt at a version that doesn't use any glossary term, referring to the popup only as "additional content" or "additions", and adding a note to describe the scope:

Hover and Focus Content Visibility: The following are true when additional content becomes visible after associated trigger content gains keyboard focus or pointer hover, except where the visual presentation of the addition is controlled by the user agent and is not modified by the author:

  • Trigger: Either the additional content does not obscure any essential content within the trigger, or the addition can be closed via a standard keyboard exit method, such as the escape key.
  • Hover: If the additional content is triggered via pointer hover, then the pointer may be moved onto the addition without loss of visibility of the addition.
  • Focus: The additional content remains visible while the trigger or any component of the addition has keyboard focus, unless the user takes an explicit action to close the addition.

Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion. Modal dialogs, in or out of the page, typically take focus and thus are not covered because such behavior would not meet success criterion 3.2.1, On Focus.

Please give a thumbs up or down reaction to this comment if you feel it's now clearer.

Member

steverep commented Aug 9, 2017

All,

It's becoming way too clear that there is not a term that everyone is going to agree on here. Given many folks being confused about clicks and modes, we could be more verbose and call it a "no-click nonmodal popup", but that seems pretty crazy. So, here's my attempt at a version that doesn't use any glossary term, referring to the popup only as "additional content" or "additions", and adding a note to describe the scope:

Hover and Focus Content Visibility: The following are true when additional content becomes visible after associated trigger content gains keyboard focus or pointer hover, except where the visual presentation of the addition is controlled by the user agent and is not modified by the author:

  • Trigger: Either the additional content does not obscure any essential content within the trigger, or the addition can be closed via a standard keyboard exit method, such as the escape key.
  • Hover: If the additional content is triggered via pointer hover, then the pointer may be moved onto the addition without loss of visibility of the addition.
  • Focus: The additional content remains visible while the trigger or any component of the addition has keyboard focus, unless the user takes an explicit action to close the addition.

Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion. Modal dialogs, in or out of the page, typically take focus and thus are not covered because such behavior would not meet success criterion 3.2.1, On Focus.

Please give a thumbs up or down reaction to this comment if you feel it's now clearer.

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli Aug 9, 2017

@steverep , there is some editorial issue where you used both "addition" and "additional content" to describe the same thing.

Can you explain the intent behind the OR condition in the Trigger requirement?

Why does it have to be a keyboard, and not a pointer, exit method?

alexswli commented Aug 9, 2017

@steverep , there is some editorial issue where you used both "addition" and "additional content" to describe the same thing.

Can you explain the intent behind the OR condition in the Trigger requirement?

Why does it have to be a keyboard, and not a pointer, exit method?

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Aug 9, 2017

Contributor
Contributor

allanj-uaag commented Aug 9, 2017

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 9, 2017

Member

I think that is a good direction but have some suggested edits:

Content on Hover or Focus:
When content becomes visible as a result of a part of the page receiving keyboard focus or pointer hover, the following are true, except where the presentation of the content is controlled by the user agent and is not modified by the author:

Trigger: Either the additional content does not obscure any essential content within the triggering user interface component, or the addition can be closed via a standard keyboard exit method, such as the escape key.
Hover: If the additional content is triggered via pointer hover, then the pointer may be moved onto the addition without loss of visibility of the addition.
Focus: The additional content remains visible while the trigger has keyboard focus, unless the user takes an explicit action to close the addition.

Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion.

Member

awkawk commented Aug 9, 2017

I think that is a good direction but have some suggested edits:

Content on Hover or Focus:
When content becomes visible as a result of a part of the page receiving keyboard focus or pointer hover, the following are true, except where the presentation of the content is controlled by the user agent and is not modified by the author:

Trigger: Either the additional content does not obscure any essential content within the triggering user interface component, or the addition can be closed via a standard keyboard exit method, such as the escape key.
Hover: If the additional content is triggered via pointer hover, then the pointer may be moved onto the addition without loss of visibility of the addition.
Focus: The additional content remains visible while the trigger has keyboard focus, unless the user takes an explicit action to close the addition.

Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion.

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli Aug 9, 2017

@allanj-uaag , let me backtrack your earlier comment on hover.

When using magnification you use the mouse to move your virtual viewport to
see content not within the viewport

What you are seeking isn't to ask the pointer to go into the additional content. You are asking the pointer to able to move away from the trigger in order to move the viewport and still see the additional content after the viewport movement, no?

alexswli commented Aug 9, 2017

@allanj-uaag , let me backtrack your earlier comment on hover.

When using magnification you use the mouse to move your virtual viewport to
see content not within the viewport

What you are seeking isn't to ask the pointer to go into the additional content. You are asking the pointer to able to move away from the trigger in order to move the viewport and still see the additional content after the viewport movement, no?

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 9, 2017

Member

there is some editorial issue where you used both "addition" and "additional content" to describe the same thing
That was done intentionally to save a bit on verbosity. I think they clearly refer to the same thing as you said.

Why does it have to be a keyboard, and not a pointer, exit method?
We're talking about users with low pointer accuracy in general. Having to find the close button is just one more visual task taking away from seeing and concentrating on the trigger. Is that really much of a concern? A keyboard handler would actually be easier to implement since nothing needs to be added to the DOM.

Member

steverep commented Aug 9, 2017

there is some editorial issue where you used both "addition" and "additional content" to describe the same thing
That was done intentionally to save a bit on verbosity. I think they clearly refer to the same thing as you said.

Why does it have to be a keyboard, and not a pointer, exit method?
We're talking about users with low pointer accuracy in general. Having to find the close button is just one more visual task taking away from seeing and concentrating on the trigger. Is that really much of a concern? A keyboard handler would actually be easier to implement since nothing needs to be added to the DOM.

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli Aug 9, 2017

@steverep , keyboard operation is already a requirement per 2.1.1. "... via a standard keyboard exit method" looks like an unnecessary duplication.

Repeating a question that you did not answer. Can you explain the intent behind the OR condition in the Trigger requirement?

alexswli commented Aug 9, 2017

@steverep , keyboard operation is already a requirement per 2.1.1. "... via a standard keyboard exit method" looks like an unnecessary duplication.

Repeating a question that you did not answer. Can you explain the intent behind the OR condition in the Trigger requirement?

@alexswli

This comment has been minimized.

Show comment
Hide comment
@alexswli

alexswli Aug 9, 2017

@allanj-uaag , I think I figure out what you're saying. You're saying that you want the point to go onto the "additional content" to keep it visible, assuming space allow, shift the viewport to make all the additional content visible by moving the pointer. Is that right?

alexswli commented Aug 9, 2017

@allanj-uaag , I think I figure out what you're saying. You're saying that you want the point to go onto the "additional content" to keep it visible, assuming space allow, shift the viewport to make all the additional content visible by moving the pointer. Is that right?

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 9, 2017

Member

Is that right?

That's it exactly.

Member

awkawk commented Aug 9, 2017

Is that right?

That's it exactly.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 9, 2017

Member

Here's what Alex, Jim, Crystal, and Andrew came up with after Steve left our call:

Content on Hover or Focus:
When content becomes visible as a result of a part of the page receiving keyboard focus or pointer hover, the following are true, except where the 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: If the additional content is triggered via pointer hover, then the pointer may be moved onto the additional content without loss of visibility of the additional content.
Focus: The additional content remains visible while the triggering user interface component has keyboard focus, unless the user dismisses the additional content.

Note: Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute.
Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion.

Member

awkawk commented Aug 9, 2017

Here's what Alex, Jim, Crystal, and Andrew came up with after Steve left our call:

Content on Hover or Focus:
When content becomes visible as a result of a part of the page receiving keyboard focus or pointer hover, the following are true, except where the 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: If the additional content is triggered via pointer hover, then the pointer may be moved onto the additional content without loss of visibility of the additional content.
Focus: The additional content remains visible while the triggering user interface component has keyboard focus, unless the user dismisses the additional content.

Note: Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute.
Note: Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 10, 2017

Member

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).
Member

steverep commented Aug 10, 2017

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).
@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 10, 2017

Member

"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.

Member

awkawk commented Aug 10, 2017

"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.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Aug 10, 2017

Contributor

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.

Contributor

alastc commented Aug 10, 2017

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.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Aug 10, 2017

Contributor

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.

Contributor

alastc commented Aug 10, 2017

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.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Aug 10, 2017

Contributor

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.

Contributor

mraccess77 commented Aug 10, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 10, 2017

Member

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?

Member

steverep commented Aug 10, 2017

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?

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 11, 2017

Member

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?

Member

awkawk commented Aug 11, 2017

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?

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Aug 11, 2017

Contributor

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.

Contributor

alastc commented Aug 11, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 11, 2017

Member

@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?

Member

steverep commented Aug 11, 2017

@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?

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 11, 2017

Member

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.

Member

awkawk commented Aug 11, 2017

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.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 11, 2017

Member

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.

Member

awkawk commented Aug 11, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 11, 2017

Member

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.

Member

steverep commented Aug 11, 2017

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.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 11, 2017

Member

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.

Member

awkawk commented Aug 11, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 11, 2017

Member

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.

Member

steverep commented Aug 11, 2017

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.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 12, 2017

Member

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?

Member

awkawk commented Aug 12, 2017

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?

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 14, 2017

Member

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?

Member

steverep commented Aug 14, 2017

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?

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 14, 2017

Member

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.

Member

awkawk commented Aug 14, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 14, 2017

Member

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.

Member

steverep commented Aug 14, 2017

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.

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Aug 14, 2017

Member

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.

Member

awkawk commented Aug 14, 2017

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.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Aug 15, 2017

Member

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.

Member

steverep commented Aug 15, 2017

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.

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Aug 18, 2017

Contributor

@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).

Contributor

goodwitch commented Aug 18, 2017

@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).

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Aug 18, 2017

Contributor

@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)"

Contributor

mbgower commented Aug 18, 2017

@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)"

@steverep steverep changed the title from Popup Visibility to Content on Hover or Focus (formerly Popup Visibility/Interference) Aug 18, 2017

@awkawk awkawk closed this Aug 24, 2017

steverep added a commit that referenced this issue Sep 19, 2017

Initial draft intent and benefits for Content on Hover or Focus
This version is simply copied from #75 and will be updated to reflect not using "popup".
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.