RE: Popup interference reborn

Thanks for the response.  See answers below.

Steve

From: ALAN SMITH [mailto:alands289@gmail.com]
Sent: Tuesday, August 01, 2017 10:11 AM
To: Repsher, Stephen J <stephen.j.repsher@boeing.com>; Jason White <jason@jasonjgw.net>; 'David MacDonald' <david@can-adapt.com>; w3c-wai-gl@w3.org
Subject: 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.
[Steve] Yes, that was the original issue, but once we had time to discuss popup issues in further detail within the LVTF, more issues surfaced.  As for the title attribute, the only way to solve this from an author perspective is to never use title attributes.  I’d be okay with that, but I don’t think the WWW would be.  We seem to be setting a precedent within WCAG 2.1 that the UA needs to be responsible for what they offer to create, e.g. user agent control exceptions are in place for both Target Size and UI Component Contrast.


  *   Trigger: The Popup does not obscure any part of its trigger.
     *   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?

[Steve] See answer above.  In short, because that is what the author has control over.



  *   Hover: If the popup is triggered via pointer hover, then the pointer may be moved onto the popup without loss of popup visibility.
     *   Why are we moving the pointer ONTO the popup, should we not be moving it AWAY from the popup?
     *   A large hand pointer will cover parts of the popup.

[Steve] Moving it onto the popup without it disappearing allows for several scenarios as explained in the description on GitHub.  In short, magnified views  may need to be panned, a screen reader can respond to read the popup via mouse, and it mitigates large pointer issues by allowing movement to a less obscuring position.



  *   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.”

[cid:image002.png@01D30AB1.CCB4DA90]

Alan Smith

From: Repsher, Stephen J<mailto:stephen.j.repsher@boeing.com>
Sent: Monday, July 31, 2017 12:04 PM
To: Jason White<mailto:jason@jasonjgw.net>; 'David MacDonald'<mailto:david@can-adapt.com>; w3c-wai-gl@w3.org<mailto: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<mailto:david@can-adapt.com>>; Repsher, Stephen J <stephen.j.repsher@boeing.com<mailto:stephen.j.repsher@boeing.com>>; w3c-wai-gl@w3.org<mailto: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<mailto:stephen.j.repsher@boeing.com>>; w3c-wai-gl@w3.org<mailto: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<mailto: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<mailto: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
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://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<http://www.davidmacd.com/disclaimer.html>
--
Cheers,
David MacDonald



CanAdapt Solutions Inc.
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://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<http://www.davidmacd.com/disclaimer.html>