Presented at 21 June, 2017 at DEPT, Rotterdam
So… hiding content! Thanks everybody for joining this. My name is Hidde de Vries. I'm a freelance front-end developer based here in Rotterdam.
I have a website, it's got a blog full of stuff about front-end development.
My current project is at Wigo4IT. They are a cooperative of the four largest Dutch cities and work together to make software for their citizens. I work on a service that lets people apply for benefits.
You might know me from Fronteers, they're the Dutch professional association for front-end developers. I retired as a volunteer earlier this year after about eight years of involvement with conferences, meetups and workshops. They can always use new volunteers, get in touch if that sounds like fun!
This presentaton is about hiding content.
And it has got a lot to do with accessibility. So before we start, I will go into that for a bit.
If you're unfamiliar with accessibility, you may have seen lots of it in the physical world.
Like on the road, they've put in tiles with relief on them, so that it is easier to use the pavement for people who can't see it.
Or this example, of Rotterdam's train station: there are elevators to get to the platform. This has probably cost them lots of money to build, but it ensures more people can use the train service. For example, people with strollers, wheelchairs or heavy suitcases.
The great thing is: we can do these sort of optimisations on computers, too!
For example, we can make user we use colours with plenty of contrast and optimise for colour blindness.
Or we can make sure we use clear and concise language.
But as we're at a front-end developer's meetup, let's look at something else we can optimise: our code! With some knowledge of how your code is used by browsers and tools for people with needs, you can make your product easier to use!
So, I'm assuming we all write markup, ocassionally. When someone goes to your website, their browser generates two threes. Well, actually, a couple more, but we'll focus on two of them now.
There's the DOM tree, which I'm sure you're all familiar with. It is a tree based on your markup. If you've made little mistakes, say, you've forgotton to close a tag or use an end tag different from the start tag, your browser usually fixes that for you when it creates the DOM tree. Well, I suppose you all know how this one works.
But did you know modern browsers generate a tree for accessibility, too? It is based off the DOM tree. Where the DOM tree contains what stuff is on the page, in the accessibility tree, the browser tries to make sense of what stuff is. This is all so that it can expose that information to assistive technology.
So basically, assistive technology can do things like read out computer interfaces, or turn them into braille, that sort of things. To know what it should read out, it will refer to a platform's Accessibility APIs. All major platforms have them: Microsoft has couple, Mac OS has one, and then there are a number of Linux ones, too. These platform APIs know what platform specific things are, like your Start bar or your Dock, that kind of stuff. Of your browser, they know the back button or the Favourites menu. But not really what happens inside the browser. The web page itself. The stuff that we make! This is where the accessibility tree comes in. It exposes what stuff on the website is, to help assistive technology make sense.
So to recap: your markup becomes a DOM tree, which an accessibility tree is deduced off, which is then exposed to platform APIs, which is then used by assistive technologies.
At this point, you might think: can I see this tree? Yes, you can! The Chrome Accessibility Developer Tools let you inspect it, just like regular dev tools let you inspect elements. There's also The Paciello Group's Aviewer, which lets you look at what platform APIs expose.
So it all starts with markup. Here's a bit of markup. The DOM tree for this is simple: it's a p, which contains a strong tag, an a tag and some loose text.
The a tag here is especially interesting. It has a role of link. Role is a specific bit of information that gets exposed to the accessibility tree, for tags in your page that have specific meaning.
So here's a quick demo: I can create a new element in the dev tools. I'll create a button element. So, I'll just at this into the DOM. Now that it is in the DOM, I can inspect it in the accessibility dev tools. As you can see, it shows up with a role of button. I've only just created it, after the page has loaded. So yes, the accessibility tree is a live representation, it has that information near instant.
We've seen link and button, but there are lots of other roles, too!
And there are things like properties…
labels or names…
… and states that get exposed to the accesibility tree.
So with that bit of background information out of the way, let's look at hiding content.
I'll talk to you about three different ways of hiding content, and a fourth bonus way, which is not really hiding.
Let's look at visually hiding first.
This is something that is useful when there's content that you don't want to see, but you want to make it available to machines.
You could also see this as providing contextual cues that supplement visual clues.
This is useful when on your team, there's a visual designer and an accessibility engineer, and they both want different things. With visual hiding, you can have your cake and eat it too.
To put this into context, here are some examples.
This is a navigation bar. Now, maybe your page has several navigation mechanisms in place, and you think it would be useful to add a heading to each, so that it is clear what each one is for. Visually, this might be clear already, because of major design differences. But non-visually, a heading might be good. In this case, you could add the heading, but make it visually hidden.
Or maybe you have this cookie warning with a close button that only has an icon visually. You could still code it as a button that says ‘Close’, and then use CSS to get the text out of the way, and add the icon. I would recommend having ‘Close’ there as a visually hidden text. This isn't a lot of work, but it is helpful for people that need to use the button, but can't see it.
Another example is this red star that indicates a field is required. It would be great if we can add the word ‘required’ into the page, as that's what it means, and then style it as the red asterix. The text itself can then be visually hidden.
Or maybe your design has no visual label and relies on placeholders to indicate what users should put it. Always code the label anyway, so that the field can be used by more users.
But please don't do this. It works fine for blind users, as they'll hear the visually hidden label, but it is annoying for sighted users, as they can't see what field they're in, while they're in it.
Let's look at some ways to visually hide.
You could use a huge negative text indent.
A disadvantage of this is that it fails in right-to =left layouts as it can cause a huge scrollbar. It can also leave us with a very wide focus ring in some browsers (Firefox).
You could also set the width and/or height to zero.
This isn't great as it gets interpreted as no content by most screen readers, so it won't actually get read out.
You can also clip your content, this is a technique that is part of and popularised by HTML5 Boilerplate's visually hidden style.
This works well, but the clip property has been deprecated, and its predecessor, clip-path, is not supported very well at the moment.
Or you can just set position absolute and use a huge negative left. This is old fashioned, but it works very well and is widely accepted as a method to visually hide.
I'll quickly show how this works in the browser: I set the button we created to position absolute with a large negative left value. If I now go to the accessibility tree, you can see it still shows up there.
Let's get on to the second method of hiding: hiding only from screenreaders.
You can do this when you want to hide stuff from screenreader users, but not from other users.
This is useful, for example, if you have repeating text on your page, for example a block with three news items that each have a ‘Read more’ link.
With a screenreader, you can ask it to read you a list of all the links. If you do that to the example page, it will tell you there's Read more, Read more and Read more. Not particularly useful.
You could set these to be hidden from screen readers using aria-hidden.
(Addition: don't do this on visible, focusable elements)
This is an attribute that you can just set to elements you need to be hidden from screenreaders.
Note that if you have to use aria-hidden, it might indicate there is something wrong with your design or your page, it would be good to review whether the thing is needed at all.
In the case of the ‘Read more’ links, better button text could benefit (all users).
In the example, if we set the button to have an aria-hidden attribute, it shows up as aria-hidden in the accessibility tree.
The third way of hiding is to really hide stuff.
This is what you do when you want nobody to access a specific bit of content. Or when you don't want that yet.
An example is a modal panel, when it is not open, but sits in your DOM tree anyway.
Another example is a tab panel. The tabs that are closed are completely hidden from view.
You can really hide things by using
visually:hidden. A disadvantage of this approach is that the space the browser had reserved for the element will still be left, so this may look weird.
The best way to really hide stuff with CSS, is
Or you can use HTML's native
This attribute works by just adding it onto an element. The element is then made invisible.
This attribute is not so well known, I found when I talked to people about it. But it has fantastic browser support, about 97% here in The Netherlands. And polyfilling is easy… what browsers do when they implement
hidden, is that they add it to the user agent stylesheet with the attribute selector, and just set it to
display: none, the polyfill is to add that line of code to your own CSS.
display:none do, is to make sure the element does not get exposed to the accessibility tree, so it won' get read out to anyone. It is also not rendered and it is invisible to text search, too.
If we try this with our example button, we can see it shows up in the accessibility tree as ‘not exposed’ and ‘not rendered’.
There's one more type of hiding I wanted to talk about, and it is not really hiding, it is making stuff completely unusable.
This can be done using the
inert attribute, a new attribute invented by WHATWG when they were working on the spec for
dialog, it lets you do
dialog that without
This attribute makes a part of the page unusable, but leaves it visible. It's a bit like disabled inputs.
This means it doesn't do stuff like mouseover events, you can't focus it, find its contents with in page search or text select its contents.
Some examples of this. This could be useful to apply to the rest of the page while a modal is open.
Or to carousel items that are not the current item. Spotify on mobile does something similar to the next and previous songs: you can partly see them and definitely not interact with them (until you select them, that is).
Another example. You know on some websites, when you've supplied a billing address, for the shipping address you can check a box that says ‘Same as billing address’. For users, it might make sense to leave the shipping address area visible, but render it unusable, make it inert.
So a quick recap: we've looked at:
Note that where the slide says sighted users, that's for brevity, they are the people that don't use AT.
I've added a couple of links to these slides for you to visit after the presentation.
That's all for me! Any questions?
Made with Keynote Extractor.