Fwd: Compromise on popup trigger visibility

forgot to reply all
---------- Forwarded message ----------
From: Jim Allan <jimallan@tsbvi.edu>
Date: Wed, Aug 9, 2017 at 11:09 AM
Subject: Re: Compromise on popup trigger visibility
To: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>


On Wed, Aug 9, 2017 at 10:08 AM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

> Yes, exactly.
>
>
>
> ESC being hit (or any explicit action, such as if the popup has a
> close/dismiss button), are currently covered on focus, but “persistence” on
> hover is on my list to clarify with some rewording.
>
>
>
​current
Hover
If the popup is triggered via pointer hover, then the pointer may be moved
onto the popup without loss of popup visibility.

Hover is a special case. having the popup overlap but not obscure content
makes it easier to move the pointer onto the popup and not have it vanish.
Base on my previous comment,
​
-- popup stays open until hover is off the content or ESC is hit
the popup would be persistent until the pointer is moved off of the
trigger/popup or ESC is hit.

Am I missing something?
 ​


> Steve
>
>
>
> *From:* Jim Allan [mailto:jimallan@tsbvi.edu]
> *Sent:* Wednesday, August 09, 2017 11:03 AM
> *To:* Repsher, Stephen J <stephen.j.repsher@boeing.com>
> *Cc:* public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
> *Subject:* Re: Compromise on popup trigger visibility
>
>
>
> I like the keyboard option.
>
> so, if the popup obscures the trigger, user hits ESC the popup closes and
> user can see the trigger.
>
> is this the only case or are the following allowed also
>
> ​​
> -- popup stays open until hover is off the content or ESC is hit
>
> -- popup stays open until focus is off trigger/content or ESC is hit
>
>
>
> On Wed, Aug 9, 2017 at 9:56 AM, Repsher, Stephen J <
> stephen.j.repsher@boeing.com> wrote:
>
> I’m looking for LVTF feedback on a proposed compromise to the trigger
> visibility condition.  Currently, the requirement is:
>
>
>
> “Trigger: The popup does not obscure any essential content within the
> trigger.”
>
>
>
> Based on this argument in a GitHub comment
> <https://github.com/w3c/wcag21/issues/75#issuecomment-321078500>, I’m
> proposing we offer an either/or situation like:
>
>
>
> “Trigger: Either the popup does not obscure any essential content within
> the trigger, or the popup may be closed via a standard keyboard method,
> such as escape.”
>
>
>
> What do you think?  Does that leave any accessibility hole?
>
>
>
> *Steve Repsher*
>
> Twitter <https://twitter.com/steverep> | LinkedIn
> <https://www.linkedin.com/in/steverepsherjr/> | GitHub
> <https://github.com/steverep>
>
>
>
>
>
>
>
> --
>
> Jim Allan, Accessibility Coordinator
>
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 <(512)%20206-9315>    fax: 512.206.9452
> <(512)%20206-9452> http://www.tsbvi.edu/
>
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>



-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 <(512)%20206-9315>    fax: 512.206.9452
<(512)%20206-9452> http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964



-- 
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964