search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
142 stars 55 forks source link

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

Closed allanj-uaag closed 6 years ago

allanj-uaag commented 7 years ago

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:

Suggested Priority Level

Level AA

Related Glossary additions or changes

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

Support Material

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

goetsu commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

goetsu commented 7 years ago

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 :

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 commented 7 years ago

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 commented 7 years ago

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.

detlevhfischer commented 7 years ago

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.

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text.

WayneEDick commented 7 years ago

April 11

Test for addressing.

lauracarlson commented 7 years ago

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 commented 7 years ago

Related LVTF email:

lauracarlson commented 7 years ago

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

Marla262 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I just updated the wiki https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Metadata_On_Hover#Proposed : with something similar.

LVTF should resolve on list and get a final resolution on next thursdays (7/13) call. and go to survey the following tuesday AG call (7/18)

On Thu, Jul 6, 2017 at 2:41 PM, WayneEDick notifications@github.com wrote:

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

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/75#issuecomment-313498562, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL5JPBGSE2j4CJhrPW95lbgXFxz-6ks5sLThrgaJpZM4LB0zx .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

lauracarlson commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@DavidMacDonald wrote:

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

+1

Laura

mbgower commented 7 years ago

@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 commented 6 years ago

@mbgower, I've put some thought into your escape key scenario and distinction from a dialog versus a popup.

Without getting into a semantic debate, a dialog to me must gain focus when it becomes visible, otherwise it is not accessible to a screen reader. Since we are talking about content that pops up on hover or focus, we cannot be talking about dialogs in that sense because such content would then immediately fail SC 3.2.1, On focus. I've added a note above to the description to make sure that is discussed in Understanding.

However, the escape key is a viable scenario where the trigger has focus but the popup has been dismissed. But simply removing the trigger as a condition is a bad idea. Consider a navigation menu with popup sub-menus. If I give focus to the first trigger to open its sub-menu, I may have to zoom, pan, or scroll to perceive it fully. But in the course of doing so, I may hover over the trigger for the 2nd sub-menu, and the author's code could cause that to immediately close the first and open the 2nd, hence the problem. But if I press escape to explicitly close it, that's fine. So how about just adding an exception to the last condition like this:

Too vague? Could it be narrowed to just keyboard actions?

mbgower commented 6 years ago

@steverep, I agree that a dialog takes focus when the trigger is activated while a pop-up does not; I think we can use that as a means to help distinguish what does and does not constitute a pop-up. Of course in many more complex pop-ups, there are focusable elements that a user is intended to reach, thus putting focus into the pop-up. When IBM designers were trying to define expected behaviour for all these variations, we felt that it was essential to distinguish between a non-interactive popup and anything that has focusable elements. I think ARIA 1.1 has since tackled this area, and it might be worthwhile investigating what they came up with in the authoring practices. Your menu scenario sounds like a different beast than a basic pop-up, since of course any menu item can take focus. Thus I'd expect in most situations the user agent to handle keeping the item with focus in the viewport, etc. In fact, I've never thought of a menu as being a popup.

steverep commented 6 years ago

@mbgower, I hope there is not confusion here. This SC is certainly meant to cover both simple popups (that might usually be called tooltips), and more complex ones with interactive elements. In the mobile age, popups under this criterion's definition are becoming less prevalent, but are certainly not obsolete.

Your menu scenario sounds like a different beast than a basic pop-up, since of course any menu item can take focus. Thus I'd expect in most situations the user agent to handle keeping the item with focus in the viewport, etc. In fact, I've never thought of a menu as being a popup.

There are many menus still out there that work only on hover and focus. A screen reader user user traversing such a menu would see it just as a list of lists. They are popups for the purposes of this SC and I think all conditions are still applicable. As for the user agent keeping things in the viewport, that's impossible if it's too big for my magnified viewport. Furthermore, assistive technology magnifiers do not even keep the entire viewport itself in view, and mouse movement is required to pan. Whether or not a particular item of focus is in the viewport is irrelevant here.

steverep commented 6 years ago

The following changes have been made to this SC to address comments:

  1. In Hover condition, specify loss of visibility applies to the popup.
  2. Definition of popup now also includes its relationship to the trigger, and "trigger" also links to the glossary. An editorial adjustment to remove "content" from the SC was also made since this is part of the definition.
  3. The exception for popup presentation controlled by the user agent has been rewritten using language from other criteria. Scope is now to "visual presentation of the popup controlled by the user agent and not modified by the author". In other words, the author is only providing code or markup, but either not supplying or cannot style it. This should cover the title attribute and also more esoteric things like the <tooltip> tag in XUL.
  4. For the Focus condition, added an exception when the user explicitly closes the popup, such as by pressing escape. In this scenario, the trigger would still have focus after it is dismissed.

The latest language can be found above in the 1st issue comment.

mbgower commented 6 years ago

There are many menus still out there that work only on hover and focus.

We need to be careful here. You said:

we are talking about content that pops up on hover or focus

In a traditional menu implementation, a submenu would not appear on focus, and thus would not be covered by this from a keyboard user's perspective. Instead, the submenu appears on activation, and focus is always moved to the first item in the submenu. There is no way by keyboard to make a submenu appear except with either an Enter key or a right arrow key, both of which open the submenu and move focus.

This is consistent with what is in the ARIA 1.1 Authoring Practices:

When a menu opens, or when a menubar receives focus, keyboard focus is placed on the first item.

So I'm slightly concerned with this SC being used to justify some wacky menu that shows subitems on the parent's focus instead of on activation.

Maybe this comes back to the definition:

content which becomes visible only when associated content, called the trigger, gains focus or pointer hover

I don't know if there is a problem here with scoping or not with that "or". Given there is a separate bullet listing what happens with things triggered by focus, I think it is probably okay, but I think there is the potential for some confusion over what is brought in scope as a consequence.

steverep commented 6 years ago

In a traditional menu implementation, a submenu would not appear on focus, and thus would not be covered by this from a keyboard user's perspective.... This is consistent with what is in the ARIA 1.1 Authoring Practices

Yes, nor would it appear on hover, and thus it doesn't meet the definition of popup here. However, in no way does WCAG only allow these types of navigation menus or enforce ARIA Authoring Practices.

So I'm slightly concerned with this SC being used to justify some wacky menu that shows subitems on the parent's focus instead of on activation.

That's fair, but I think the logical extension there is not to make anything happen unless I activate it, which eliminates the use of popups altogether. I'm okay with that, but I doubt the world is ready :). I guess the keyword that is used is "remains". So we're not advocating how to make things appear, but rather what some of their properties should be if they jump at me without my asking.

I'd be happy if the Understanding docs also dissuaded the use of popups in general given the lack of usability for touchscreen users.

mbgower commented 6 years ago

So we're not advocating how to make things appear, but rather what some of their properties should be if they jump at me without my asking....I'd be happy if the Understanding docs also dissuaded the use of popups in general given the lack of usability for touchscreen users.

Okay, thanks for clarification.

steverep commented 6 years ago

Hi @alexswli,

It is my understanding that you have objected to this criterion on the August 1 conference call primarily because of clarity in the exception. You wrote on the survey:

What is "visual presentation of a popup is controlled by the user agent and is not modified by the author" suppose to include and exclude?

It is meant to exclude any code or markup where the browser has assumed full control over what is shown visually to the user. The biggest example for content shown on hover is the title attribute in HTML being shown as a tooltip. Older versions of IE also used to display image alt text in the same way. It can also cover more esoteric things like the <tooltip> element in XUL.

The wording borrows from both WCAG 2.0, where "visual presentation" is used a number of times, and also from two proposed criteria accepted into the 2.1 editor's draft:

  1. Target Size (#60) has an exception for "User agent control: The appearance of the target is determined by the user agent and is not modified by the author."
  2. User Interface Component Contrast (#10) has the exception for "User agent control: The color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author."

Does this explanation resolve your objection? If not can you suggest alternate wording? Thanks.

steverep commented 6 years ago

Hi @kwahlbin,

You wrote on this week's survey that

We need a better definition of popup and trigger

Can you explain what you feel is not clear about the current glossary definition so it can be addressed? Thanks.

steverep commented 6 years ago

Hi @awkawk,

You wrote on this week's survey:

I'm wondering about the hover item - I'm not sure what this is trying to solve. I suspect that we are concerned that it is sometimes hard to move the pointer from the trigger onto the popup items, and I've seen it be difficult but never impossible to do so. This SC text doesn't prohibit "difficult"

That's a fair point. I think the crux of the issue is that many authors create this content in such a way that only the trigger responds to hover, making it impossible to move the pointer at all to increase visibility. I'm not sure how to introduce language to force the author to also make it "easy". Any suggestions?

steverep commented 6 years ago

Many folks are uncomfortable with using the term "popup" here, despite the proposed glossary definition. I've done some research, and it indicates that many UI frameworks and documents do not use various terms in exactly the same way, and "popup" is often used as a generic term to begin a definition for a more specific term. For example, ARIA defines a tooltip as "A contextual popup that displays...", and bootstrap has a similar definition which uses "popup".

Some have suggested using "tooltip" instead; however, this has significant drawbacks. A tooltip is defined in most places as not containing any interactive (clickable) components, and sometimes even as text only. This criterion is meant to cover items including and beyond traditional tooltips, such as menus which operate on hover and focus.

I'd like to propose using the term "hoverbox", which currently has a Wikipedia definition that is almost exactly what we're after. This term is not in widespread use, which may work to our advantage by not creating confusion with mainstream terms. "Hover" is right there in the word, and the reader needs to go to the glossary for a clear definition.

What do others think?

alliMSFT commented 6 years ago

@steverep, take a look at these two screen shots. The "triggers" (we call them tiles at Microsoft) are very big, which is consistent with Windows 10 design language. In one case, I hover on near the center of the tile and the tooltip shows up above the tile. In the other case, I hover near the bottom of the tile and the tooltip shows up in the middle of the tile. Now, I'd argue it much easier for users to associate the tool tip with the tile if the tooltip shows up closer to the point instead far away. I honestly don't understand what harm it does to have the tooltip show up near the center of the tile when the pointer hover near the bottom.

2017-08-08 1 2017-08-08 2

goodwitch commented 6 years ago

+1 for hoverbox

glenda sims | team a11y lead | deque.com | 512.963.3773

web for everyone. web on everything. - w3 goals

On Tue, Aug 8, 2017 at 9:57 AM, Steve Repsher notifications@github.com wrote:

Many folks are uncomfortable with using the term "popup" here, despite the proposed glossary definition. I've done some research, and it indicates that many UI frameworks and documents do not use various terms in exactly the same way, and "popup" is often used as a generic term to begin a definition for a more specific term. For example, ARIA defines a tooltip as "A contextual popup that displays...", and bootstrap has a similar definition which uses "popup".

Some have suggested using "tooltip" instead; however, this has significant drawbacks. A tooltip is defined in most places as not containing any interactive (clickable) components, and sometimes even as text only. This criterion is meant to cover items including and beyond traditional tooltips, such as menus which operate on hover and focus.

I'd like to propose using the term "hoverbox", which currently has a Wikipedia definition https://en.wikipedia.org/wiki/Hoverbox that is almost exactly what we're after. This term is not in widespread use, which may work to our advantage by not creating confusion with mainstream terms. "Hover" is right there in the word, and the reader needs to go to the glossary for a clear definition.

What do others think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/75#issuecomment-320982145, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWnro7B2nI4H8FpbW0H1uVqt_wVfEks5sWHdKgaJpZM4LB0zx .

mraccess77 commented 6 years ago

@alexswli wrote I honestly don't understand what harm it does to have the tooltip show up near the center of the tile when the pointer hover near the bottom.

It would cover up the text/icon contents of the tile. I think that is one of the issues we are trying to address is that the pop-up doesn't block you from seeing that trigger content.

mraccess77 commented 6 years ago

-1 to Hoverbox. The content can appear on focus as well and this is a non-standard term that I feel will cause confusion.

steverep commented 6 years ago

Hi @mraccess77, I do agree that there can be content that appears on focus only, but that is generally reserved for content that appears on text entry fields, and is not nearly as problematic as hover content. I'm not sure using "hoverbox" could possibly generate more confusion than "popup" seems to be doing. Do you have another suggestion?

steverep commented 6 years ago

Hi @alexswli,

Thanks for the example above. It is very difficult for me personally to see the screenshots even under magnification, so I'm going to reply based on your words. In case 1, the criterion would be met of course. In case 2, the problem is that if a user has already oriented their vision to the tile, likely under magnification, then the hover content disrupts that orientation and the user may have to start the "vision process" all over. Furthermore, if I need to magnify the tile quite a bit, the screen real estate for my pointer to be off the tile may be the minimum, making it difficult to visualize the tile at all.

mraccess77 commented 6 years ago

@steverep in my opinion any popup/hover content that was more than an equivalent for the icon/text would need to be available on focus as well whether interactive or not.

mraccess77 commented 6 years ago

Seems like the issue with popup obscuring trigger is only problem when it covers content -- it's ok if it covers empty area.. Perhaps we could update it to allow overlap as long as it doesn't block content of the trigger.

DavidMacDonald commented 6 years ago

I agree that there are some situations where we don't want to forbid the popup from overlapping the trigger. Especially large triggers. I think as long as part of the trigger is exposed it's ok... I'd also suggest that since these are custom popups, we explore requiring the esc key to close it while it has focus. (in addition to it closing when focus leaves.)

Pros for requiring esc key: quick way to close Con: extra coding and the user can just hit the tab to close it anyway

steverep commented 6 years ago

Seems like the issue with popup obscuring trigger is only problem when it covers content -- it's ok if it covers empty area.. Perhaps we could update it to allow overlap as long as it doesn't block content of the trigger.

@mraccess77, I think this is already implied by the wording, and this type of situation is exactly why I did not want to specify the position of the popup within the criterion. I don't think your suggestion improves clarity here since the trigger is defined as "content" as well. Perhaps we could add a note to clarify?

alastc commented 6 years ago

Would the 1st bullet need to be something like:

The Popup does not obscure any content within its trigger.

So in a large, mostly blank box it would be ok for the popup to be over a blank area.

mraccess77 commented 6 years ago

@alastc that works for me. And as this SC is doing double duty now we should make the short name and description clear about the goals although I can't think of a proper name just now.

alliMSFT commented 6 years ago

@steverep , just so we are talking apples and apples. Here are screen shots with 250% zoom. Both of the tool tips are dictated by the user agent and not in scope, but I want to fully understand what you are getting at. The tool tips shows up in relationship to where the pointer hovers. If it is high up on the tile, the tool tip is high. In the first screen shot, it overlaps the tile just a tiny bit. So, how does the appearance of the tool tip "disrupt orientation" any more or less than the second second screen shot where the entire tool tip goes inside the tile? Where would you like the tool tip to show up? The top of the tile is pretty far away from the pointer. If you have high enough of magnification on, it may way go outside of the screen. That does not sound like a good solution...

You also wrote, "I need to magnify the tile quite a bit, the screen real estate for my pointer to be off the tile may be the minimum, making it difficult to visualize the tile at all." I am not sure I understand that sentence. When you magnify, the tilt gets bigger, but you pointer does not move as a result. The tool tip is still there. How does not asking the tool tip show up outside of the tile change your user experience?

2017-08-08 4 2017-08-08 5

alastc commented 6 years ago

Also a suggestion for defining popup or hoverbox, trying to cut the wikipedia one down:

"An element that appears over other content when the mouse is placed over a triggering element, or the keyboard focus is on the triggering element."