The Web Needs a Native .visually-hidden
I agree with the reasoning here—a new display
value would be ideal.
I agree with the reasoning here—a new display
value would be ideal.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.
Worse still, sometimes we kill off essential content.
I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.
They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.
Of course! I slapped my forehead. How could I have missed this?
It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.
Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.
I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:
One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of
select
elements within a form.
The problem was in my feature detection:
There’s a little bit of mustard-cutting going on: does the
dragula
object exist, and does the browser understandquerySelector
? If so, theselect
elements are hidden and the drag’n’drop is enabled.
The logic was fine, but the execution was flawed. I was being lazy and hiding the select
elements with display: none
. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.
It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.
I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!
When to use aria-hidden="true"
, and when you might need display: none
:
aria-hidden
by itself is not enough to completely hide an element from all users, if that is the end goal.
When to use role="presentation"
(or role="none"
):
Where
aria-hidden
can be used to completely hide content from assistive technology, modifying an element’srole
to “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.
Comparing different ways to hide content accessibly:
There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.
- Temporarily Hidden Content
- Purposefully Visually Hidden Content
- Purposefully Visual-Only Content