RE: Metadata On Hover SC Text

Just a quick question. Since the original issue was that on iOS and Zoomtext it was an enlarged cursor pointer that was the item that was obscuring the title mouse over text, how does the informational content not obscuring other content solve that original problem?

Having the informational content that is available upon hover now be required to not be the only means of conveying that information does not solve the original problem and introduces further requirements for designers and developers and perhaps user agents to find some other means of conveying that information for visual users. Because, the main issue is for visual users, not screen reader users.

We have made a simple solution into a complex new requirement for designer and developers.

Stating that “the hover text not be covered over by the cursor” is the simplest wording for fixing the original issue. And from my  testing, two browsers already put the hover text above the cursor anyway.

Alan

Sent from Mail for Windows 10

From: Laura Carlson
Sent: Friday, November 18, 2016 2:18 PM
To: Jonathan Avila
Cc: public-low-vision-a11y-tf@w3.org
Subject: Re: Metadata On Hover SC Text

Hi Jonathan, Alastair, and all,

Okay. Sounds good, Jon. Thank you for your help and expertise. Always
very much appreciated.

Is there anyone who can not live with circling back to Alastair's not
relying on hover alone version?

I think the latest language was:

"Informational content that is only shown by hovering your mouse over
an element is not used as the only means of conveying information and
does not obscure other content."

Ideas for improvement?

Do we need the "and does not obscure other content" part if Wayne's
use case is addressed by the Resize Content SC? Wayne?

Kindest Regards,
Laura

On 11/18/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> Laura, I'm not sure where to go on this SC as I've had conflicts during the
> call time with another TF and there are good points on both sides.  While
> the author can't control standard tooltips they can make their own tooltips.
>  So for now I'll drop my comments until I have time to ponder this SC more
> -- I'd be fine if we took it back full circle to not rely on tooltips.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> Join SSB at Accessing Higher Ground This Month!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
>
> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
> Sent: Friday, November 18, 2016 10:09 AM
> To: Jonathan Avila
> Cc: public-low-vision-a11y-tf@w3.org
> Subject: Re: Metadata On Hover SC Text
>
> Hi Jon,
>
> I think the key may be to craft an air tight definition of "fully visible"
> to address what is required. The definition currently requires hover content
> to be:
>
> "Fully visible": content within the viewport that is 1. not covered (that
> was intended to mean not covered by cursors too.) 2. not obscured 3. not
> clipped or truncated 4. in the viewport as long as the user needs it.
>
> Ideas for improved verbiage? I like the your idea of adding a magnification
> level. How would you suggest doing that?
>
> Question for #4: To address Wayne's use case where the popup covers content
> in gmail and won't go away, should we add that hover content:
> "needs to go away when the user no longer requires it."?
>
> Thank you.
>
> Kindest Regards,
> Laura
>
> On 11/18/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>>> For each item of content that is shown by hovering your mouse over an
>>> element, check that the content shown on hover:
>> 1. is fully visible.
>> 2. available via any input method.
>>
>> I like this for a separate reason because I run into issues where
>> hover content often goes off the left edge or bottom of the screen and
>> scrolling removes it.
>>
>> But I'm not sure this addresses the issue with large mouse pointers
>> overlapping the hover content as it doesn't seem to require that.
>> Perhaps what we were requesting is that the hover content is
>> sufficiently far enough away from the pointer but not too far that it
>> would allow for up to 200% magnification of the pointer without overlap.
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com
>> 703.637.8957 (Office)

-- 
Laura L. Carlson