Hiding content

Presented at 21 June, 2017 at DEPT, Rotterdam

Slide 1

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.

Slide 2

I have a website, it's got a blog full of stuff about front-end development.

Slide 3

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.

Slide 4

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!

Slide 5

This presentaton is about hiding content.

Slide 6

And it has got a lot to do with accessibility. So before we start, I will go into that for a bit.

Slide 7

If you're unfamiliar with accessibility, you may have seen lots of it in the physical world.

Slide 8

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.

Slide 9

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.

Slide 10

The great thing is: we can do these sort of optimisations on computers, too!

Slide 11

For example, we can make user we use colours with plenty of contrast and optimise for colour blindness.

Slide 12

Or we can make sure we use clear and concise language.

Slide 13

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!

Slide 14

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.

Slide 15

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.

Slide 16

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.

Slide 17

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.

Slide 18

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.

Slide 19

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.

Slide 20

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.

Slide 21

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.

Slide 22

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.

Slide 23

We've seen link and button, but there are lots of other roles, too!

Slide 24

And there are things like properties…

Slide 25

labels or names…

Slide 26

… and states that get exposed to the accesibility tree.

Slide 27

So with that bit of background information out of the way, let's look at hiding content.

Slide 28

I'll talk to you about three different ways of hiding content, and a fourth bonus way, which is not really hiding.

Slide 29

Let's look at visually hiding first.

Slide 30

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.

Slide 31

You could also see this as providing contextual cues that supplement visual clues.

Slide 32

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.

Slide 33

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.

Slide 34

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.

Slide 35

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.

Slide 36

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.

Slide 37

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.

Slide 38

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).

Slide 39

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.

Slide 40

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.

Slide 41

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.

Slide 42

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.

Slide 43

Let's get on to the second method of hiding: hiding only from screenreaders.

Slide 44

You can do this when you want to hide stuff from screenreader users, but not from other users.

Slide 45

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.

Slide 46

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.

Slide 47

You could set these to be hidden from screen readers using aria-hidden.

(Addition: don't do this on visible, focusable elements)

Slide 48

This is an attribute that you can just set to elements you need to be hidden from screenreaders.

Slide 49

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.

Slide 50

In the case of the ‘Read more’ links, better button text could benefit (all users).

Slide 51

In the example, if we set the button to have an aria-hidden attribute, it shows up as aria-hidden in the accessibility tree.

Slide 52

The third way of hiding is to really hide stuff.

Slide 53

This is what you do when you want nobody to access a specific bit of content. Or when you don't want that yet.

Slide 54

An example is a modal panel, when it is not open, but sits in your DOM tree anyway.

Slide 55

Another example is a tab panel. The tabs that are closed are completely hidden from view.

Slide 56

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.

Slide 57

The best way to really hide stuff with CSS, is display: none.

Slide 58

Or you can use HTML's native hidden attribute.

Slide 59

This attribute works by just adding it onto an element. The element is then made invisible.

Slide 60

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.

Slide 61

What hidden or 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.

This is great and exactly what you'd want when you hide something. I would recommend to only do this with JavaScript though, because removing the attribute or CSS can also only be done with JavaScript.

Slide 62

If we try this with our example button, we can see it shows up in the accessibility tree as ‘not exposed’ and ‘not rendered’.

Slide 63

There's one more type of hiding I wanted to talk about, and it is not really hiding, it is making stuff completely unusable.

Slide 64

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 dialog.

Slide 65

This attribute makes a part of the page unusable, but leaves it visible. It's a bit like disabled inputs.

Slide 66

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.

Slide 67

Some examples of this. This could be useful to apply to the rest of the page while a modal is open.

Slide 68

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).

Slide 69

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.

Slide 70

So a quick recap: we've looked at:

  • visibly hiding, which makes content accessible to AT, but not to sighted users
  • hiding from IT, which makes content accessible to sighted users, but not to AT
  • really hiding, which makes content accessible to nobody
  • inert, which makes content visible, but unusable

Note that where the slide says sighted users, that's for brevity, they are the people that don't use AT.

Slide 71
Slide 72

That's all for me! Any questions?

Made with Keynote Extractor.