Category Archives: Presentations

Accessible presentations

Recent events have had me thinking a lot about accessible presentations at conferences and user groups. Myriad factors have kicked me into considering the topic seriously. Accessibility comes in many forms, and doesn’t just apply to people with disabilities. The core consideration is: Are you excluding anyone with the way you present your content?

To start with, I work with Sean Curtis, who is Atlassian’s resident accessibility expert. Sean has, among other things, been trying to educate everyone about better colour contrast in presentation slides, for both internal and external presentations.

Then Sean and I attended A11y Camp — a one-day event in Sydney dedicated to accessibility on the web. This event guaranteed there would be people with vision impairments attending (and presenting). Therefore all presenters had been asked to audibly describe any slides they were relying on for visual impact. The key point was to not ever rely on the visuals alone. I remember one presenter really forcing himself to read out quotes and describe images, which he said was so different from his normal presentation style, but it greatly helped the audience.

Recently I had the pleasure of presenting at JSConf EU, which uses live transcription services during all the presentations. As preparation for this I was asked to send through as much material for my talk as possible ahead of time. This would assist with building transcription dictionaries for the specific technical terms used at a developer-focused conference. This got me thinking about the accessibility of my talk for more reasons than just vision impairment.

I’ve also been reading a lot lately about vestibular disorders, which can result in certain types of visual motion making people physically ill. All of these factors combined to make me think hard about how I was going to present my talk. Some of the following tips are things I’ve always done, but others I had to put more conscious effort into.

Things I try to do for a presentation

1. Ensure text and images are readable

Large text, large images, high contrast between text and background colours. This is good practise anyway, regardless of accessibility considerations. Make sure someone sitting at the back of the room can still see what’s on your slides — we’re not all young programmers with perfect eyesight. This also applies to picking colours that don’t look the same for someone with colour blindness.

2. Describe any purely visual elements

How to get this wrong: show something on your slides, then point at it and say “and this is the result” with no further explanation. While it may seem funny or obvious to a majority of your audience, you still shouldn’t assume that everyone has understood the message. Thus, if the crux of your talk or the punchline of a joke involves pointing at an animated GIF with no description, that’s excluding anyone in the audience who can’t see it or who takes longer to process visual information (due to cognitive disabilities).

I like to think of it in the same was as putting an alt attribute on an image. On a web page, if the image is purely decorative and adds nothing to the content, it’s ok to have an empty attribute (alt=""), but in all other cases the image should have a description. It’s the same with a presentation. If the image is purely decorative and adds nothing to the content, it’s ok to not mention it, but in all other cases the image should be audibly described. This doesn’t have to be a clunkily-worded halting of your verbal flow in order to say “and on screen right now is an image of a squirrel”. If done right, the description of what’s on screen can be woven into the flow and narrative of your speech without ever feeling unnatural.

3. Only share slides online if they make sense on their own

Something I’ve quoted before, but is worth repeating here:

The gist is: our slides are not the talks, our slides aid the talks we are giving. They are a visual catalyst for the things we talk about. When you see something and you hear about it at the same time it is more likely to stick. It is as simple as that.

[…] If I look at the PDF of a talk a few weeks later and only see pretty images without remembering what they meant at that time I get confused and frustrated.

— Christian Heilmann, On controversial slides, talk distribution and lack of context

Your talk is about you talking. A talk should start from the words you say, with slides being a progressive enhancement. And because they are an enhancement, they don’t always make sense on their own, devoid of context. I only put slides online if I think there’s enough information in the slides alone to get a point across. For me, this only works for in-depth technical topics such as easing or gradients (in fact, I still added an initial explanation slide to the gradients presentation specifically for people reading the slides online later).

One technique I’ve seen that I really like is putting the slides online in the form of an article with slides and text side-by-side. Each slide is presented next to the words that were spoken for that section. It’s a great adaptation of a talk from an in-person presentation to an on-screen essay, changing the format to best suit the medium in which it’s published. The two people I’ve seen consistently do this well are Maciej Cegłowski and Bret Victor.

4. Limit animations

There are many people who don’t like lots of animations whizzing around on a screen. Slides with lots of fancy animation effects can make people with vestibular disorders feel sick. Personally, I don’t want to make my audience feel ill just because of how I’ve chosen to present something. And regardless of vestibular disorders, I often find the super-amazing 3D transform effects of slide transitions quite distracting. They’re cool/cute the first couple of times, but over the course of a whole talk they just get in the way and take attention away from what the presenter is saying.

5. Don’t just take my word for it

There is also a good list of tips for accessible presentations published by the W3C.

How did I do?

For my JSConf EU talk, my slides had almost no animations. I made sure to be conscious of describing what was on screen (although I know I failed at a couple of points). But I know I won’t always get these tips 100% right. I’m not perfect and I know I’ll make mistakes, but I’ll keep trying to improve.

Also, these tips aren’t necessarily going to work for every presentation. For example, a talk about colour blending is inherently visual and would be very hard to describe to someone who doesn’t see colours. But it’s worth trying to be as inclusive as possible.

Auto-detecting time zones at JSConfAU

Last week I was lucky enough to present at JSConfAU. My talk was titled “Auto-detecting time zones in JS” (with a sub-title of “Are you a masochist?”).

Part I – Technical details

Taking a tour of terrible temporal twists and turns

A lot of the talk delved into the history of time and time zones, pointing out various oddities and things that can trip you up if you try to deal with them. I won’t repeat all of them here – partly because I doubt anyone would read the whole lot, partly because I just want to focus on the two main points I made: Continue reading

Presentation: WebRTC / Web Audio at SydJS

I gave a presentation about WebRTC and the Web Audio API (titled “WebRTC: Look Ma, no Flash!”) at the SydJS tech meetup on February 20, 2013.

There is no video available of the presentation (fortunately or unfortunately, depending on your perspective), but the slides are online at http://gilmoreorless.github.com/sydjs-preso-webrtc.

The presentation was really just me showing a heap of examples and demos of using WebRTC and Web Audio to do fun things. Most of the examples were written by other people, but a few of them were mine, showing things I’ve been doing in my experiments repository.

Instead of just being lazy and leaving my experiments hidden away, I’m going to force myself to write some blog posts explaining some of them and how they work.

The first one should be up tomorrow. Should.