WCAG 2.0 recommends to also use :focus
when :hover
is used on link elements to support keyboard navigation. This works well for link elements, but there are a couple of differences between the two.
:hover
state while only very few can be focusedThis question is strictly about css. Is there a way to simulate the behavior of :hover
(as described above) for keyboard navigation? Or are there any strong reasons why one would not want that?
To make it more clear here is an example:
html:
<div id="box">
foo bar
<a href="#">click me</a>
</div>
css:
#box {
opacity: 0.3;
}
#box:hover {
opacity: 1;
}
#box a:focus {
opacity: 1;
}
When using a mouse I will hover over the link element before using it. Since the :hover
state propagates upwards #box
will be fully opaque.
When using a keyboard I will focus the link element before using it. Since the :focus
state does not propagate upwards #box
will not be fully opaque.
This can be done in JavaScript with focusin/focusout events (they are just like focus
and blur
except they bubble). Here is a fiddle.
It boils down to this function:
var deepFocus = function(element, cls) {
cls = cls || 'deep-focus';
element
.on('focusin', function() {
element.addClass(cls);
})
.on('focusout', function() {
var value = !!element.find(':focus').length;
element.toggleClass(cls, value);
});
};
Update: There is a draft spec that contains the :focus-within
selector which would exactly do what is required here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With