WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL] Text exposed on Hover

for

From: Radhika Soni
Date: May 25, 2021 2:23PM

Thanks for the feedback. Also, would like to know, that nowadays on many
ecommerce sites, we do see different product image on hover? What do you
think? Would you call them accessible? And if not, how can we make them
accessible? Any ideas would be appreciated.

Have a great week ahead!

Refer this site ( Check for product listing, as you hover on them you see
different image) -https://www.adidas.com/us/member_exclusive

Regards,
-Radhika


On Wed, May 19, 2021 at 1:56 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> A few things to think about:
> * A non-focusable element that requires a hover is a keyboard
> accessibility fail
> * An interactive control that only reveals text on hover but not on
> focus ditto (this can be fixed by listening for device independent
> events instead of, or in addition to, mouse events), but it's only a
> partial solution
> * an interactive element that requires focus to reveal text can be an
> "accessible name" fail in its initial state, a tool like axe will flag
> it as such. Also a screen reader user navigating by means other than
> the tab key will navigate to the element and see no text. This could
> be remediated by making the text visually hidden (instead of totally
> hidden) and change the CSS class from a visually hidden to a visible
> one on hover and focus, but it's still not perfect.
> * A mobile device does not have hover or focus events, so revealing
> text based on those events will likely cause major issues on mobile
> devices (for all users).
> * If the interactive element has a visible icon at all times but text
> only on hover/focus, you could say it's ok (as long as you use screen
> reader only text or aria-label to ensure text is always available to a
> screen reader user).
>
>
> So, based on the element, there are options, but I always come to the
> same conclution, relying on hover/focus events to display text is
> always going to cause complications and result in some sort of
> accessibility challenges. If the text is important enough to be
> visible to all, make it visible to all at all times. If not, wonder
> why the text is needed at all (if icon is sufficient, use screen
> reader equivalent).
>
> On 5/19/21, Mark Magennis < <EMAIL REMOVED> > wrote:
> > If the image is a focusable element (e.g. a button or a link) then all
> you
> > have to do is make sure the text is also exposed on focus (and ensure
> that a
> > screen reader announces it of course).
> >
> > But I suspect your image is not focusable. So you have a problem. You
> should
> > not make it focusable purely in order to cause it to show the text
> because
> > being focusable means it is interactive (it does something when you
> click on
> > it). So non-interactive elements should not receive focus while tabbing.
> The
> > same is true of making the text itself keyboard focusable. If it were to
> > appear and be given focus while tabbing, that would not be correct
> behaviour
> > because it is not an interactive element.
> >
> > An alternative is to make the image a button that is clicked to show the
> > text. This is sometimes referred to as a 'toggletip', which is a way to
> > solve the problems I've described of having tooltips attached to
> > non-interactive elements.
> >
> > Mark
> >
> >