Re: Is content on hover only a WCAG failure?

​> If content appears only on hover, i.e. the trigger is not focusable,
does that *always* constitute a WCAG 2.0 failure?

Yes, because it is a failure of* 2.1.1 Keyboard: *All functionality of the
content is operable through a keyboard interface.​


​​> Not showing any additional information (i.e. <button title="press this
to save">save</button> )

Except "*<button title="press this to save">save</button>*" is already
focusable
​ (as a button element)​
​,​
and further,
​using @title like that ​
will likely be a Success Technique
​ ​
for
​
Success Criterion 1.3.4 Purpose of Controls
​ - the weakest option available to be sure, but still valid (as long as
another mechanism is providing the accessible name, which will also be
required to ensure @title meets the requirement asked for by 1.3.4)​, so I
echo Patrick: yes and yes.
​

(See Also: https://www.w3.org/TR/WCAG20-TECHS/SCR2.html)

​JF​

​

On Tue, Oct 17, 2017 at 5:45 PM, James Nurthen <james.nurthen@oracle.com>
wrote:

> IMO it is a WCAG failure except in the situation where the content is
> redundant
>
>    - Shown elsewhere (for example the text from the hover is "easily
>    available" somewhere else)
>    - Not showing any additional information (i.e. <button title="press
>    this to save">save</button> )
>
> Regards,
> james
>
>
> On 10/17/2017 10:14 AM, Repsher, Stephen J wrote:
>
> I’m looking for some conformational feedback on a simple question: If
> content appears only on hover, i.e. the trigger is not focusable, does that
> *always* constitute a WCAG 2.0 failure?  In the context of 2.1.1, I suppose
> this asks whether the ability to show the content is considered
> “functionality” and thus must be keyboard operable.  One example might be
> where a help icon is used to show extra info for a form field and is piped
> to the accessible description:
>
> <label>Reason<input type=”text” … aria-describedby=”tooltip”></label><img
> src=”help-icon.png” … onmouseover=”showTooltip()”>
>
>
>
> Depending on your answer above…
>
>
>
> If you answered yes, then doesn’t that translate to saying that any
> element with a title attribute must be focusable, either by default from
> its semantics or manually via setting its tab index?  For example:
>
> <img … alt=”blah” title=”more blah” tabindex=”0”>
>
>
>
> If you answered no, then can you offer examples and explain why they are
> fully accessible (I don’t think mine above actually is)?
>
>
>
> *Steve Repsher*
>
> Twitter
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_steverep&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=ELX2morANsauwtoroVrFb2wD7s1u7PsR47DTXqRvJ34&m=rDabxaZai9ryVfyFx5uL-mdD3Y4F2v1CdagJiIbVIBg&s=uQOWc66g0av_ximRdvH2vonJid3JH7tUfNd18N1TrGw&e=>
> | LinkedIn
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_steverepsherjr_&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=ELX2morANsauwtoroVrFb2wD7s1u7PsR47DTXqRvJ34&m=rDabxaZai9ryVfyFx5uL-mdD3Y4F2v1CdagJiIbVIBg&s=u3nXTBAi1rTXoMcJzLEoHkYt3kUYZ4klwRThK41mICA&e=>
> | GitHub
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_steverep&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=ELX2morANsauwtoroVrFb2wD7s1u7PsR47DTXqRvJ34&m=rDabxaZai9ryVfyFx5uL-mdD3Y4F2v1CdagJiIbVIBg&s=1o4NvAogS-yA8pmMFSzDZ3np5jn8UwUqcskc22nzkoQ&e=>
>
>
>
>
> --
> Regards, James
>
> <http://www.oracle.com> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065
> <https://maps.google.com/?q=500+Oracle+Parkway+%7C+Redwood+City,+CA+94065&entry=gmail&source=g>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion