RE: Is content on hover only a WCAG failure?

Ø  My initial reaction to  ​Steve's  scenario is "No - all of the buttons would need to be keyboard

If all five of the buttons perform the same operation and 4 are not operational with the keyboard the function is still keyboard operable.    WCAG does not make any distinction on where the on page alternative is located or how many tab stops it must be.    WCAG indicates that alternative pages don’t even need to have a one-to-one equivalence – that is a non-conforming page can have links to two pages where the alternatives are found.

Whether this is equivalent access is a separate discussion than does it meet the conformance requirements.  WCAG allows pages to contain non-conformant content as long as the content isn’t relied on for the conformance claim – because there is an alternative or because it’s not a technology that is relied on – as long as it does not interfere..

Jonathan

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Wednesday, October 18, 2017 1:54 PM
To: Jonathan Avila
Cc: James Nurthen; Repsher, Stephen J; WCAG
Subject: Re: Is content on hover only a WCAG failure?

Hi Jon,

I think there is a bit of a disconnect here. It isn't whether or not the additional content is in-page, or linked content (you
​r​
@longdesc example), but rather the following use-case:

> Again, let’s extend that logic… Does that mean that if I have 5 buttons on the page that perform the same function, I only need to make one of them keyboard accessible? (Steve R)

(Remember, this thread started with the question "If content appears only on hover, i.e. the trigger is not focusable, does that *always* constitute a WCAG 2.0 failure?")

My initial reaction to
​Steve's
scenario is "No - all of the buttons would need to be keyboard
​ ​
accessible" (even though, as
​<
button
​>​
s, they already are)
​. But extending upon that, if supplemental information (content) for those buttons​ *is* being provided via @title on all five of those 'widgets', then yes, all 5 widgets need to expose that information (even if it is the same information for all 5 instances), which seems to be in disagreement with James' assertion.
Or do others disagree with that?
​ (I am also assuming we agree that onmouseover=”showTooltip()”​ alone is insufficient and a failure of 2.1.1)

The problem then is getting to the content, not how the content is functionally being provided in code (which, sadly, is why even though @longdesc is a conformant attribute, its lack of universal user-agent support significantly weakens its usefulness in production. But hey, with regard to @longdesc, I tried. :-) )

​JF​


On Wed, Oct 18, 2017 at 12:14 PM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
I agree with James – the WCAG conformance requirements indicate that alternative content can be used on the same or different page to make the page conformant as long as it does not interfere.  This is a core principle of WCAG – so it is a little alarming that this coming up in 2017.

Sometimes, supplemental information may be available from another page for information on a page. The longdesc attribute in HTML is an example. With longdesc, a long description of a graphic might be on a separate page that the user can jump to from the page with the graphic. This makes it clear that such content is considered part of the Web page, so that requirement #2 is satisfied for the combined set of Web pages considered as a single Web page. Alternatives can also be provided on the same page. For example creating an equivalent to a user interface control. (https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html)

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>
703.637.8957<tel:(703)%20637-8957> (Office)
Visit us online: Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>
Looking to boost your accessibility knowledge? Check out our free webinars!<http://www.ssbbartgroup.com/webinars/>

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.

From: James Nurthen [mailto:james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>]
Sent: Wednesday, October 18, 2017 12:43 PM
To: Repsher, Stephen J; John Foliot
Cc: WCAG
Subject: Re: Is content on hover only a WCAG failure?




On 10/18/2017 6:27 AM, Repsher, Stephen J wrote:
But title doesn't show on focus for mouse users (except on IE/Edge with recent windows) so the text is not available to most keyboard users. However, in this example it is not a problem as the title element is not really providing any content which is useful.
[Steve] Following that logic through to technology independence, that means you feel a custom tooltip using the onmouseover event only is okay in some situations?  Does that not contradict F54?
If it isn't providing a "function" then it would be ok - or if the same "function" were available in another way then yes it would be ok. F54 talks about being the only means to invoke the scripting function. If the scripting function is to display some information then so long as there is another way to display this information this would be ok.



If I had provided a useful title in this example then it would be a failure except if I could get to that information easily in another way. So again - if content only appears on hover - it is not always a failure. It is not a failure if that information is either useless or easily available in another way for keyboard users.
[Steve] But if I follow the letter of the law in 2.1.1, there is no such exception.  It seems we must decide either the display of hover content is part of the functionality or it isn’t.  If you argue it isn’t then I suppose the question falls to 1.3.1, but again there’s no exception for useless or repetitive information.
2.1.1 talks about functionality of the content where functionality is "processes<https://www.w3.org/TR/2008/REC-WCAG20-20081211/#processdef> and outcomes achievable through user action" and processes are "

series of user actions where each action is required in order to complete an activity

Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

Example 2: An account registration page requires successful completion of a Turing test before the registration form can be accessed."



If the content provided by hover is provided in another way then the processes and the outcomes are achievable through user action.



Regards,

James








--
Regards, James

James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto: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>
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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion