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)
>
>
>
> -----Original Message-----
> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
> Sent: Friday, November 18, 2016 9:25 AM
> To: Jonathan Avila
> Cc: public-low-vision-a11y-tf@w3.org
> Subject: Re: Metadata On Hover SC Text
>
> Hi Jon and all,
>
> So maybe we are back to:
>
> == SC Text ==
>
> Informational content which appears on hover that is necessary for
> understanding must be:
>
> * fully visible
> * available via any input method.
>
> == Related Glossary additions or changes ==
>
> Fully visible: content within the viewport that is not covered, obscured,
> clipped, or truncated and remains in the viewport as long as the user needs
> it.
>
> == Testability ==
>
> 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.
>
> Expected Results
>
> * Check #1, #2 are true.
>
> What do you think? Would that work? Ideas for improvement?
>
> Thank you.
>
> Kindest Regards,
> Laura
>
> On 11/18/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>>> I would be very happy with it but am not sure if others would be.
>>> What kinds of push back could we anticipate?
>>
>> I'd imagine people would ask about fly out menus, modal dialogs, roll
>> overs,
>> etc.    I'd assume if something appeared on focus and remain apparent on
>> focus then it would pass this requirement?
>>
>> I'm concerned about the text "does not obscure other content" because
>> any hamburger menu or dialog will obscure other content.
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com
>> 703.637.8957 (Office)
>>
>>
>>
>> -----Original Message-----
>> From: Laura Carlson [mailto:laura.lee.carlson@gmail.com]
>> Sent: Friday, November 18, 2016 8:10 AM
>> To: Alastair Campbell
>> Cc: public-low-vision-a11y-tf
>> Subject: Re: Metadata On Hover SC Text
>>
>> Hi Alastair and all,
>>
>> Thank you. I agree it is an issue for both use cases. The cleanest way
>> to address it would be to use your latest proposed language as there
>> would be no testing.
>>
>> For everyone that SC language again is:
>>
>>> Informational content which only appears on-hover *must not be*
>>> necessary for understanding and *must not obscure other content*.
>>
>> I would be very happy with it but am not sure if others would be. What
>> kinds of push back could we anticipate?
>>
>> Thoughts everyone?
>>
>> Kindest Regards,
>> Laura
>>
>> On Nov 17, 2016 4:57 PM, "Alastair Campbell" <acampbell@nomensa.com>
>> wrote:
>>
>>> Hi Laura,
>>>
>>>> The original issue was the cursor overlapping the tooltip content
>>>> making the tooltip text unreadable.
>>>
>>> Ah, I thought we had established previously that is a user-agent issue?
>>> Apologies, looking back it was a common issue, just not universal.
>>>
>>> So if we try to cover cursor overlapping, then logically if someone
>>> relies on tooltips then it will happen. There is no need to test, it
>>> will occur.
>>>
>>> Therefore, tooltips should not be relied on. At all.
>>>
>>> Also, the first part of the evidence included someone doing testing
>>> that showed the tooltip obscured an important link, and I think Wayne
>>> mentioned that as an issue as well?
>>>
>>> It is an issue both ways – the tooltip being obscured, and the
>>> tooltip obscuring other content.
>>>
>>> In which case we can simplify to:
>>>
>>> ------------
>>>
>>> Informational content which only appears on-hover *must not be*
>>> necessary for understanding and *must not obscure other content*.
>>>
>>> ------------
>>>
>>> I.e. it shouldn’t matter if it is visible, readable or not.
>>>
>>> That seems to cover the evidence/benefits on the wiki, is it too harsh?
>>>
>>> -Alastair
>>
>>
>
>
> --
> Laura L. Carlson
>


-- 
Laura L. Carlson

Received on Friday, 18 November 2016 15:09:47 UTC