-
Notifications
You must be signed in to change notification settings - Fork 55
Content on Hover or Focus (formerly Popup Visibility/Interference) #75
Comments
Even if I share and understand the need, this will basically make 99% of the site I know claiming conformance to wcag 2.0 AA not conforming anymore. I think it must be moved to AAA or wait for wcag 3.0. It also look to me more as a UAAG issue than authors issue for example If I remember well edge started to show tooltip on focus |
Your estimation of it's commonality is different from mine, I've checked around some sites and the only use that I could find was either ok (and not failing here) or mis-use that probably should fail (something). I was using this CSS to view titles (using a bookmarklet to append the CSS):
On the BBC homepage the only titles are on the 'remove' buttons. They don't assume you can access the title, and don't block other content. On Amazon.co.uk, there are quite a few in the product listings, but I think they've been JavaScripted-out of normal usage, they don't appear. Towards the bottom the rating stars have titles that duplicate the text, which overlap and would be caught. On the WhiteHouse.gov, there are a couple of titles on the top bar links, but they are spaced out and the titles don't overlap other content. The horizontal icons for social media also cause pop-overs that don't overlap. I'd agree it could be a user-agent issue, but as the focus aspect has been an open issue for over a decade, I think there's a case for incorporating it into the content guidelines. |
title attribute is explicitly mentioned in multiple wcag techniques as a possible solution, like : even if many people including myself doesn't think those techniques are best way of achieving the underlying success criteria it's still a possible solution to use and many sites use it. In France for example it's a very common practice (for example last two sites that receive a label from accessiweb use it : http://www.chu-toulouse.fr/ , http://www.sncf.com/fr/trains/ter and I can give you plenty. on amazon.co.uk the title do appear for me on the product listing and are failing this SC, on whitehouse.gov even if title don't overlap it's still no conforming with the current testing procedure My fear is that only to conform to this SC many will simply remove or change title to aria-label because it's far easier that implementing custom tooltips that anyway will be very annoying in mobile or changing the UI/UX to remove the need of a tooltip. We will end up with less accessible interface anyway because even if not perfect title was useful in many cases. |
The title attribute has support issues. Ref: Using the HTML title attribute by @stevefaulkner |
Thanks @lauracarlson i'm aware of that but it still something currently allowed in wcag 2.0 techniques. If in WCAG 2.1 title isn't allowed anymore fine but that mean that a lot of website conforming to WCAG 2.0 won't be able to conform without changing techniques used to conform and doing that we may end up with solution even less accessible that title like aria-label or hidden label or hidden text that have no visual feedback at all. So if you want to reject title as a possible technique for WCAG 2.1 you also need to reject all those other kind of solutions. Furthermore the only viable technique is to remove the need of metadata on hover by changing the UI because :
For me it look very costly to achieve that's why I think it's better to make it AAA in WCAG 2.1 and then move it back to AA in WCAG 3.0 to allow smooth transition |
A number of concerns and thoughts on this.
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. If users were given the option of displaying or not displaying tooltips, along with timing (how long before a display is triggered, how long does the tooltip persist), interaction (how to trigger and dismiss) AND how about the ability to override (making the non-persistent information appear persistently) the need for this SC would change. An ability to control different ways to indicate the existence of a tooltip would also be useful. All of those abilities should really be handled by the user agent. |
Here's another way of thinking about this. Currently there are 2 levels of link purpose: one where the link is clear from its surrounding context (2.4.4); one where the context is clear from the link text alone (2.4.9). Maybe another way of tackling non-persistent informational content is to create a new AAA where all informational content is provided persistently or without the need for additional user actions. That would have to be reworded since it has to accommodate progressive disclosure and dynamic content, but hopefully folks understand what I'm getting at. |
I would clearly separate requirements for the use of the title attribute from custom content displayed on hover. The example on the Perkins recruitment site is nasty but seems of another order. I agree with @goetsu that in 2.1 we should not invalidate the admittedly dated techniques served alongside WCAG 2.0, and with @mbgower that handling the title attribute is really more the responsibility of UAs. |
Updated the issue description to reflect the FPWD text. |
April 11Test for addressing. |
New related article: How to Make Your Website Accessible to People Who Use a Screen Magnifier by Frederik Creemers.
|
Related LVTF email: |
Hi - Below I have summarized both issues as they relate to mouse-hover content:
Link to view videos that capture the above described issues: |
Hi @Marla262 , Marla wrote:
Both are needs. I would be in favor of trying to get them both into the SC as you have techniques for both. Thanks, |
Meta Data on Hover / Popup Interference Wayne |
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 ***@***.***> 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
<#75 (comment)>, 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
|
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:
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, |
I have concerns with the addition of the two new bullets:
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. 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:
I think your language on "turn off" is bordering on this, but doesn't address all the other ways to control persistence, etc., I previously mentioned. It's also not clear to me whether you are going to accept the exisitence of User agent control as a means of meeting "turn of" or if you are intending that the author must in all cases offer this ability. Same goes for obscure. If one poor user agent implementation causes obscuring, does the author get failed? |
Hi @awkawk, I was going to make some of these changes now in GitHub but I see you beat me to it. I would have limited it to just the switch from "popup" to "additional content" and other minor changes. I cannot support some of these changes, and some reverse changes made to address the comments on the 1st survey.
|
Fine with me.
I'll take a look at this.
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.
If the new content is a modal dialog box, it may be large and users may need to use it, so it is critical that repositioning is allowed. For the tooltip case, I think that the requirement for keyboard users makes the reality of not obscuring the content very much in line with what you want. Keyboard users need a way to clear the additional content and they can't adjust the position of the keyboard focus, so they will need to be able to dismiss the content and the mouse users will be able to use the same functionality. |
If the new content is a modal dialog box then it isn't covered by this SC, because:
I'd describe that as a change of context, because the page you (were) on is blanked-out / blocked from use until the dialog is dealt with. If you mean a non-modal dialogue, then I think it should be positioned next to the trigger (like a drop-down menu), and the SC can apply. |
The first bit's readability confused me a bit, there are two "when"s. Could that be:
|
|
"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.
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.
I'm not sure I understand how this addresses my concerns with "repositioning" being allowed to satisfy the trigger visibility condition. Can you please clarify? |
OK, so first to update you and others on the call today. The WG agreed on the SC moving to the editor's draft. More responses:
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.
Typo. I meant non-modal.
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? |
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 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:
I don't think the 1st bullet undermines the 2nd, if "that content remains visible when the pointer is moved over it", you can view both the trigger and the content without loosing the content. If that content can then be moved, that's fine, it's optional for the user. |
@alastc and @awkawk, mixing quotes but grouping topics here: Repositioning
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.
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:
That defines what the user would need much better in terms of positioning. UI Component vs. Content
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:
Keep in mind, too, that since the 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? |
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. |
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!
The reward is that we are referring to an actionable item for what it is, and we already have a definition for it. For name/role/value it is important to recognize that depending on the type of component one or more of these might be achieved with no additional effort. The role of a paragraph with focus/hover is "text" and it is set automatically. I think that it is worth putting it out as it is and we will see if we get any feedback that makes us think more about this, and we will be able to revisit it. If we debate it too much longer, we will take away from other items or risk missing the August 22 date entirely. |
I 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.
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.
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 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.
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/
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. |
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:
And I'm simply arguing that option 3 has no guarantee to make the trigger visible, so it needs clarification on what that positioning must accomplish, which is to not obscure the trigger. If that's impossible, then options 1 or 2 are the way to go. |
I think 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:
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:
Can we not make that change? |
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. |
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.
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. |
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.
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. |
What you're describing is essentially a palette window where the additional content has tools or something else I need to interact with to use the target content behind it. I'd say that type of thing is mostly out of scope since it is unlikely to appear only on hover or focus, but more importantly the accessible thing to do is to allow me to choose if it is there or not. This example loses sight of the goal of seeing the target. The importance of the additional content is totally irrelevant. What is most troublesome to me is that this SC was meant to benefit users with low vision or low pointer accuracy in general, and that example is exactly the kind of thing we are trying to prevent. It is not an easy task for these users to move things around on screen, and it's even harder for them to be expected to put pieces of a puzzle together visually as they do it. Calling that accessible is not accurate when in fact it's closer to a nightmare. If there truly is a good reason why content only on hover or focus needs to obscure what triggered it with no option for user dismissal (and I have yet to hear it), then it should be formulated as an exception. |
@steverep and/or @allanj-uaag as your time permits, what do y'all think about changing the title of this issue to match the current name in WCAG 2.1...which I think is "Content on Hover or Focus". Also, it would be awesome to update that SC Shortname in the very first comment. I'm trying to make it easy to see all the issues in github (that have become proposed SC in WCAG 2.1 public working draft). |
@goodwitch I think the intent was to preserve the original name and content so that past comments made sense. There are direct links to the current wording at the top of the issue. i guess we could consider "Content on Hover or Focus (previously Popup Visibility)" |
This version is simply copied from #75 and will be updated to reflect not using "popup".
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:
Benefits
Testability
For each possible popup on the webpage, check that:
All must be true to pass.
Techniques
Related Existing Techniques
New Techniques
onclick
(accessible to keyboard and touch devices) to show popup contentSupport Material
The Low Vision Task Force wiki on Popup Interference contains a wealth of additional information and background.
The text was updated successfully, but these errors were encountered: