Also on Speakerdeck
Yes, hiding content!
I'm Hidde. Contrary to popular belief, that isn't pronounced as Hayden or Heden.
As someone wrote on my cup the other day.
It's pronounced as hidden, which is ironic given the subject of my talk.
So, I'll talk about hiding content.
This is a matter of accessibility, because when you hide something you make it inaccessible to some or to everyone.
In the real world, accessibility is everywhere. It's things like tactile paving, so that blind people can use streets.
And escalators, so that people with strollers, suitcases and wheelchairs can access the train platform.
On the web, you can look at things like colours, make sure they have enough contrast and we don't just rely on colours.
And you can make sure your language is easy to understand.
Or you can optimise your code. That's what I'll cover today. I'll talk about markup.
Some of our work is writing markup. When the website is live and people visit it, the markup goes to the browser. Browsers generate two trees.
The first is the DOM tree, most of you will probably know this. It's a tree made of your markup, and if you had made any mistakes, like closing a tag that you shouldn't have, those are corrected. Well, I suppose you're all familiar with the DOM and interact with it daily.
Not as well known is the accessibility tree, this is a more recent concept. It is based on your DOM tree.
It exposes things like roles, for example button and slider. Many HTML elements have a role built in, like when you use a button element, it will come with a role of button.
The three also contains states of elements, like expanded and pressed.
And there are labels, also known as accessible names, they're things like the text on your buttons.
This tree makes things easier for people who use assistive technologies, or AT.
I'll explain for a bit how AT knows what to convey to users.
It knows what everything is, from Platform APIs. All platforms have them, and there are different ones for Mac, Windows and Linux.
Platform APIs know what's what on your platform, so they know the Start bar and the Dock and whatnot. They also know the browser window, its back button and favourites menu. What they don't know is the stuff inside the web page. This is where they look at the accessibility tree.
As I said, that tree is based off the DOM tree. And the DOM tree is based off YOUR markup, so that's where we come in.
So I'll cover three ways of hiding content today. The difference is in which people they hide for.
First, you can hide from screen. This is also known as visually hiding.
In this modal dialogue, if you can see its layout, you can see that the cross icon in the right top corner is probably there to close the dialogue, this makes sense from the visual context. If you can't see it though, you could benefit from label that describes the action. You can add that to your markup. Your designer might not want it to appear on the page, and this is when visually hiding comes in handy.
Another example is this required indicator. You can add the text required to the markup, but visually hide it from the screen.
This is one way to do it (and there are others available, like ones that use clip and clip-path). But position absolute does the trick well.
[video] So, as you can see, when I set position: absolute and left: 9999em to this button, it is no longer visible, but still in the accessibility tree.
You can also hide just from AT.
This may be helpful for things that are mostly decoration, like icons, in some cases.
Or in this example. There are three news items and they all have the same ‘Read more’ button.
Screenreaders have this options where you can ask it to read a list of all links. That list would read like this: Read more, Read more, Read more. Makes it impossible to choose which one to click.
This is where aria-hidden comes in. It is an attribute.
You can add it to a div to make it hidden to AT.
Please note that having to use aria-hidden could indicate there is something wrong with your page.
In this page you might want to fix it by getting rid of the Read more links for everybody.
[video] Here's a quick video demo. I'm adding aria-hidden to the button and as you can see it now shows as not exposed and aria-hidden.
The third and last way of hiding: hiding from everything.
An example of that is a modal panel that is not currently shown. When it is hidden, you probably want to hide it from everything.
Or a tab that is closed.
You can hide from everything by using display:none. This makes the element completely inaccessible to everything. This is mostly done temporarily.
If you like toggling, I know I do, you can also use the hidden attribute.
Again, you just put it on any element to completely hide it.
This attribute is well supported, almost 98% here in The Netherlands.
So, by hiding from everything, you're making sure the element is not exposed by the accessibility tree, not rendered and invisible to text search.
[video] As you can see, when I set this button to display:none, the accessibility node is shown as not rendered.
There's a fourth thing I'd like to talk about, it isn't really about hiding, it is about making an element unusable.
The inert attribute, brought to you by WICG, the people that gave us responsive images. It is not in any browsers yet and, I believe, still being specced.
So inert makes an element visible, but unusable.
This means the element won't have pointer events or focus, you can't search for it and it is impossible to select.
You might want to do that with the rest of your page while a modal is open.
Or with carousel items that are not the current one.
Or in this case, the shipping address when you've checked that box ‘Same as billing address’,
A very quick recap, as I'm almost out of time: you can hide from screen, from AT or from both, and soon you will be able to make something inert.
Some links so that you can read more once I share these slides:
Thanks for listening! Please tweet or email any questions or comments.
Made with Keynote Extractor.