Re: Is content on hover only a WCAG failure?

Also: https://www.w3.org/TR/WCAG20-TECHS/F54.html

On Tue, Oct 17, 2017 at 6:31 PM, John Foliot <john.foliot@deque.com> wrote:

> ​> 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
>



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

Advancing the mission of digital accessibility and inclusion

Received on Tuesday, 17 October 2017 23:32:41 UTC