RE: Popup interference reborn

I’m confused with the exception since the original issue was the user agent placement of the title text (popup) was getting covered over with large cursors on some browsers. Since IE places the title text above the cursor that was one user agent that did it as we liked. Large cursors on Safari and Chromebooks are really bad. 

• Trigger: The Popup does not obscure any part of its trigger.
o If the user agent does not place the tooltip/title text far enough away from a trigger to not obscure ANY part of its trigger why are we requiring custom items to do so?
• Hover: If the popup is triggered via pointer hover, then the pointer may be moved onto the popup without loss of popup visibility.
o Why are we moving the pointer ONTO the popup, should we not be moving it AWAY from the popup?
o A large hand pointer will cover parts of the popup.
• Focus: The Popup remains visible while its trigger or any of its components have focus, unless the user takes an explicit action to close the popup.”



Alan Smith

From: Repsher, Stephen J
Sent: Monday, July 31, 2017 12:04 PM
To: Jason White; 'David MacDonald'; w3c-wai-gl@w3.org
Subject: RE: Popup interference reborn

I agree that the exception could be clearer, but ultimately I think both suggestions come back to the same problem.  I did try to address this using language accepted into other criteria (explained below).  Jason, I also agree with your other comments and have tried to address them.  Here are the changes that have been made:
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.

Here’s the new SC:

“Except where the visual presentation of a popup is controlled by the user agent and is not modified by the author, all of the following are true when a popup is visible:
• Trigger: The Popup does not obscure any part of its trigger.
• 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 its trigger or any of its components have focus, unless the user takes an explicit action to close the popup.”

Where “popup (and trigger)” is defined as “content which becomes visible only when associated content, called the trigger, gains focus or pointer hover”.

Steve

From: Jason White [mailto:jason@jasonjgw.net] 
Sent: Friday, July 28, 2017 4:23 PM
To: 'David MacDonald' <david@can-adapt.com>; Repsher, Stephen J <stephen.j.repsher@boeing.com>; w3c-wai-gl@w3.org
Subject: RE: Popup interference reborn

I support David’s comment – perhaps “except where the popup content is created by the user agent’s user interface”. Also, in the second item, where the proposal refers to “loss of visibility”, it isn’t clear whether this means loss of visibility of the pointer, of the popup content, of the triggering content, or any of the three.

In the definition of popup content, it might also be helpful to explain the term “triggering content”, or to introduce a separate definition for it.

The proposal seems essentially sound, from my perspective.

From: David MacDonald [mailto:david@can-adapt.com] 
Sent: Friday, July 28, 2017 3:39 PM
To: Repsher, Stephen J <stephen.j.repsher@boeing.com>; w3c-wai-gl@w3.org
Subject: Re: Popup interference reborn

I think the exception might have to be clearer...

Perhaps

Except where pop up is a user agent component...


Because all functionality is generated by the UA...

On Fri, Jul 28, 2017 at 3:33 PM David MacDonald <david100@sympatico.ca> wrote:
It's starting to feel like tax season with all the returns pouring in :)

On Fri, Jul 28, 2017 at 1:28 PM Repsher, Stephen J <stephen.j.repsher@boeing.com> wrote:
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 if you commented previously.
 
You can view & comment on GitHub here: https://github.com/w3c/wcag21/issues/75
 
And here’s the new SC language for reference:
 
“Except where popup presentation is controlled by the user agent, all of the following are true when popup content is visible:
•       Trigger: Popup content does not obscure any part of its triggering content.
•       Hover: If a popup is triggered via pointer hover, then the pointer may be moved onto the popup content without loss of visibility.
•       Focus: Popup content remains visible while any of its components, including the trigger, have focus.”
 
Where we define popup as “content which becomes visible only on focus or pointer hover”.
 
Thanks.
 
PS – This one had been assigned to Wayne, so with his deserved retirement I’m happy to take on its management.
 
Steve
 
-- 
Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
www.Can-Adapt.com
  
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy
-- 
Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Mobile:  613.806.9005
LinkedIn 

twitter.com/davidmacd
GitHub
www.Can-Adapt.com 
   
  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy