#btconf Berlin, Germany 07 - 09 Nov 2016

Tim Kadlec

Tim is a web technology advocate pushing for a faster web at Akamai. He is the author of Implementing Responsive Design: Building sites for an anywhere, everywhere web, and was a contributing author for Smashing Book #4: New Perspectives on Web Design, and Web Performance Daybook Volume 2.

Want to watch this video on YouTube directly? This way, please.


What you don’t know can’t hurt you, at least that’s the old saying. But on the web, it is precisely the things that you don’t know and can’t see that can cause the biggest headaches. The web is an unstable and unpredictable environment and every day there are complications that go unnoticed and unseen—but not by the people trying to use your site. Building a stable, usable experience online means anticipating these issues as much as possible, making some of the more commonly overlooked components of development more visible in the process.


Tim Kadlec: Yeah, the feeling is absolutely mutual. Marc does an amazing job at this event. I love this event. Like I remember coming away last time.

Before I even came to the events, I had asked around. I’m like, you know, who should – you know, who’s been here in the past? How is it? And everybody kept saying, “It was a special event. It was a special event. It was a special event,” almost to the point that I was wondering if they were being paid to say it. But then you’re here, and you go to it. You hang out with everybody, and you realize that is exactly what this is. It’s a very special event.

Has anyone here ever played hide-and-seek with a two-year-old? A couple hands up. Right? All right.

It’s kind of fun because they’re old enough. They’ve figured out object permanence, right? So the peek-a-boo thing doesn’t work any more. The level has been set a little bit higher. But they still haven’t entirely figured out how to exactly hide well.

I have four kids. We play a lot of games. Their two favorite games, I think, involving me are either hide-and-seek or a game where I end up having to crawl around on my hands and knees throughout the house giving them horse – yeah, I see a few people nodding. Yeah, horseback rides. And that is really, really hard on my knees, so I actually – I encourage hide-and-seek whenever possible, so we play it a lot.

My seven and my six-year-old, they have gotten actually quite good at it. They’ll go hide in the kitchen cupboards or something. I don’t know. They pick out these random hiding spots, and sometimes I have no idea where they went, and I have to give up.

My four-year-old, she’s not quite as good, but she’s been watching her sisters and sort of figuring it out as, you know, they go along. She’s a little bit more prone to just random outbursts of giggling, which kind of gives away the location. But my two-year-old son nicht so gut. Was that all right, by the way? Is that? Okay.

Yeah, unless his sisters are helping him, he could be pretty iffy at this whole hide-and-seek thing. I do the thing, you know, where you turn around and you count to ten. I turn around, and there he is like this. He’s just standing in the middle of the room with, like, a towel wrapped around his head giggling, or he’s standing underneath something and his legs are kind of sticking out the other end. You know he hasn’t fully realized that, like, just because he can’t see me, that doesn’t mean that I can’t see him.

But you can’t, like, give in right away. You can’t just find him because then it’s boring and you’d have to find something else to play, which means I’m probably going to be doing horseback rides. So instead what happens is I walk through the entire house, and I loudly proclaim everywhere that I’m looking that he is not. You know it’s the, “Oh, is he in the cabinet? No. Is he under the rug? No. Oh, there he is right there in front of me the entire time. I didn’t know where he was.”

Yeah, he gets a big kick out of it. He loves it, and I just think it’s so humorous. It’s so fun to watch because everything, when you’re two years old, is still very much framed from it being your perspective that matters, not anybody else’s. It’s all about you.

Now I myself, I don’t like to brag, but I’m going to do it anyway because, why not? I’m pretty good at hide-and-seek. Okay? I’m actually pretty decent at this. I’m probably the best out of me and my kids. I’m just going to say that right now.

And if it wasn’t for the fact that my wife catches me and then I get in trouble, I would totally be using this to take, like, a 10- to 15-minute nap somewhere while the kids are off trying to figure out where dad went because I have an unfair advantage because, as it turns out, by the age of 33, you’ve sort of figured out that it’s not all about you. That it’s not just your perspective that matters. At least I like to think so. Sometimes I worry that we give ourselves a little bit too much credit on this front.

Did you know that there are 3.5 billion people using the Internet today? 3.5 billion people: that is a staggering number. It’s even more mind-blowing, though, when you stop to consider how very different their experiences are.

Do you remember when we used to just focus on, like, which of the two major browsers they were potentially using? Oh, forget that. You know nowadays they’re using low-end mobile devices. They’re using tablets. They’re using supped up desktop machines. They’re connecting over a pour mobile connection, high-speed cable connection, publicly shared wi-fi. They’re browsing from home, from work, from a coffee shop. They’re looking for information for entertainment. They’re looking for employment. They’re young. They’re old. They’re rich. They’re poor.

Literally the only thing that they all have in common is that they are all trying to access the Internet, the single largest repository of human knowledge ever assembled. Yet, there’s so much variability. There’s so much that we do not know about the context of how our site or application is going to be used.

So much of it is unseen and unknown to us. Yet, from the very beginning, the Web has been emboldened by this grandiose vision that it could somehow be for everyone. Right? That’s the theoretical promise of the Web, right? It’s a platform for empowerment. Everybody gets access to the Web. Everybody gets access to this huge semblance of knowledge, and it can be used for empowering, you know, rural farmers that become economically independent. It can empower women to be socially and economically independent in cultures where that kind of thing is frowned upon and discouraged.

It’s an empowering platform. At least that’s what the promise is. That’s the theory. But the reality is that often we fall pretty far short of this.

There was a tweet recently. I’m not going to name the person’s name because I don’t want to, like, pile on the person, especially since they’re not here to defend themselves. That feels not very supporting. But they tweeted this. Some guy in Silicon Valley said that mobile people have spent 15 years saying that you’ve got to remember people with low end phones and slow networks. He argues that maybe it’s time to retire this, like we don’t have to deal with this any more, right?

All right, now first off, first off, if there is a problem on the Web that needs solving right now, the problem is not that we do not design and develop for people with high-end devices and fast networks. Okay? Those people get plenty of attention. That is not a problem that needs to be solved. Secondly, I think that this sort of a statement shows a very myopic view of what it means to use the Internet, what it means to use the Web. It shows a very limited perspective.

There was a great document a few years ago called Offline and Falling Behind. It was about barriers to Internet access. What happened was these researchers went around, and they tried to categorize what are the obstacles standing in the way of people getting online today. They categorized it into four basic groups.

One group of obstacles is user capability, so things like digital literacy. If I give you a phone, or if I tell you to type something in Google and search Google for information, do you know how to do it? Another is language literacy, just plain old being able to read.

Another group of obstacles is incentives. This is, you know, lack of awareness or use cases, lack of localized content or, in some situations, the lack of cultural and social acceptance. This is a day ago, maybe two days ago, since I got here there was an article about India and the state of smart phone adoption in India. A couple of people may have seen this. What they talked about in there is that, in India, 114 million more men than women have cell phones. Now globally, the gap is 200 million, which means almost all of this, like 50+% of this gap is from one single country.

Now the reason, as one elder of a village was kind enough to give us in the article, is that mobile phones are really dangerous for women. I bet nobody actually realized this, but this is dangerous. We should be confiscating all of these things right now.

Now he goes on to say that – he goes on to say that, you know what? Girls are more – “Girls,” he said, “are more susceptible to bringing shame if they have access to technology.” Complete and utter hogwash, right?

We all know the real reason why this isn’t happening. The real reason why they’re not giving the women and the girls phones in these countries has nothing to do with this bologna. All it has to do is the fact that this is a platform for empowerment, and this is a culture where they’re not supposed to be empowered. And by taking these things away, we deprive them of that. That’s what’s at risk when the Internet can’t get where it needs to go.

Affordability was another one of the barriers to access. This is things like low income situations, purchasing power, low purchasing power, the cost of ownership of a device. Thankfully that’s getting much more affordable nowadays. Or the cost of data plans, which sadly this is still a very real problem because we keep turning out things like this. This was an article on CNET about Jony Ive and the touch bar thing on the MacBooks, you know.

First off, the site took so long to load, I couldn’t wait. I couldn’t be bothered to wait for it to finish. Like it just sat there just perpetually loading and loading and loading for minutes. And I was like, I wanted to have a nice static screenshot, but I decided screw it, I’m just taking it, and getting on with my life.

Addy Osmani from Google did some analysis of this site, and what he found was that there was 131 megabytes – 131 megabytes on a mobile network. So if you – most of this is – like, look at all these images - layer 99. There’s 99 layers of jpegs. That’s a terrible song: 99 layers of jpegs on the – no, sorry.

Audience: [Laughter]

Tim Kadlec: No, but – so if you actually compare this to what it cost people to use a mobile data plan, what this means is that if we look at it in terms of percentage of gross national income daily per capita, so what a person on average makes in a country, we’re talking anywhere from 50% to 85% for some of the worst offenders. Even in some of these other ones, as we drop down, we’re still hitting near 13%, 14%, 16% of what they make daily to load one single informational article about a touch bar. Cost is still a big problem.

Then the fourth category for obstacles was infrastructure. This is lack of coverage or access, or lack of adjacent infrastructure, so electricity not being available, in which case you can’t use the Internet. A lot of areas where they’re impacted by low speed connections.

I was just telling somebody else, like, a couple days ago, and I remember their just like a look of horror on their face. I just explained that where I am, I am almost always on a 2G mobile connection, and it was like they were appalled. And then we also compared broadband speeds, and I get, like, 15 megs down, and he got like 500, which is kind of sad. But, no, there’s areas where 2G is great, where like there are still areas that are not covered by anything. There are still areas where this coverage is so sporadic and unreliable that it cannot be used, so this is another barrier.

We have these four categories of barriers. We have the user incentive, the user capabilities, the affordability, and the infrastructure. What the researchers did is they went through a whole bunch of countries, and they analyzed the situation. They gave everybody a grade, 100 being great, you’re doing awesome, zero being holy cow we’ve got some problems.

Now I’ve just got – on the next slide I’ve just got a few of the countries. I don’t have all of them. But I want you to know that the top two countries listed, I did not change the order of them in any way, shape, or form. I am not kidding. I could not make this up. The two countries where it is the easiest to get access to the Internet, the United States where I am from, and Germany where most of you are from. We literally have the rosiest picture of what it means to use the Web possible, the easiest route to using the Internet out of anybody else in the world.

When we talk about things like can we forget about low-end networks, it is important that we broaden our perspective because it doesn’t line up with ours. You know and maybe it’s not ideal. I understand, like, it’s not great. It’s not fun to have to admit that we have to do this. We have to accommodate for a 2G connection. We have to accommodate for phones that might be overtaxed by all the resources.

But you know what? The less than ideal is inherent in the Web. It is just part of the Web platform because it goes everywhere to everyone. We have to deal with that. And if we dismiss those less than ideal traits then we’re dismissing characteristics of the very platform we’re trying to build for.

The question is then how can we actually do this? How can we actually build something that can withstand the onslaught of the unknown and the unseen?

This is Werner Heisenberg. He is a German physicist. Studied in Hamburg, I believe. In 1927 he defined what would become known as the Heisenberg Uncertainty Principle. Now has anybody heard of this? Yeah. Anybody consider themselves science buffs and you know, like, the actual definition? There’s a couple hands. Okay.

The thing about scientific principles is, typically when they’re coined, what happens is they kind of stay in science land, like, where test tubes grow on trees and people dream in calculus. But every once in a while one of these principles resonates with a larger audience, and it moves into what we lovingly refer to as pop science. This is kind of what happened with the Heisenberg Uncertainty Principle. Right?

The basic principle, as Heisenberg defined it, is purely about measuring particles and measuring specifically two traits: the location and the velocity of a particle. What he argued was that you could never ever measure these two traits with exact certainty. The reason it has nothing, like some people think that it has something to do with the fact that once you observe it you change it. That’s a different principle. This is all about actually the way that particles move and the way that waves move. There’s a whole bunch of science that we can talk about after that goes into it.

It’s a very narrow definition of what the principle means, but the idea of an uncertainty principle, that there is a limit to our understanding, resonated with a larger audience, and so it’s sort of been gradually, over time – it exploded. It’s sort of taken on a little bit more of a life as a broader vision. It’s basically saying that there is a limit to what we know. There is a limit to what we can understand. And there is a limit to what we can see.

This certainly applies to Web when we accept sort of a pop-side broader definition, right? I think that there’s a level of Zen almost when you accept this, when you accept the uncertainty principle, and I don’t want to – I want to make it clear that when I say there’s a level of Zen, the level of Zen is not in saying, “You know what? You’re right, Tim. I can’t predict all this stuff, so screw it. I’m not even going to bother with it.” That’s not the level of Zen we’re going for here. Let’s keep digging.

No, there’s a level of Zen in saying, “You know what? You’re right. There is. There is a limit to how much I can predict about how my site or application is going to be used. There is a limit to what I know about the context.”

As Jeremy Keith put it, we’ve always only had the illusion of control, right? As soon as I send my beautifully designed, beautifully developed site or application – I could be using gorgeous Web fonts. It’s built in the latest React. You know, from top to bottom it looks – the code is impeccable. And it’s – yeah, I can go in and talk about this to everybody, and everybody loves the site or the application.

But as soon as I put it out in the wild, I have no control over anything else that happens. I have no control over what network the user is going to use to access it. I have no control over whether or not there is going to be some sort of a bad actor in between who wants to manipulate the content that I’m sending out. I have no control over whether or not the person who receives it is capable of using a mouse or a keyboard, or whether they have some visual impairments or motor impairments that makes it difficult for them to actually access and use the site or application.

And I don’t see those things either. You can’t track that in analytics. That doesn’t show up.

We have to remove assumptions. This is how it sort of – this is how the whole process starts, in my opinion, for building for a more resilient, defensive sites and applications: as few assumptions as possible because every layer of assumptions that we make, every other technology that we assume is going to be there, that assume is going to be in place, is another layer of fragility. Every time that I assume that there’s going to be – I don’t have to worry about a bad actor in between, there’s not – I don’t have to ship it over HTTPS, it’s fine, that’s another layer where something can go wrong. When I assume that the user on the other end can see perfectly fine, doesn’t need any help with the contrast, isn’t going to use a screen reader, that’s another layer of fragility. When I assume that they’re going to have JavaScript enabled and it’s going to be a powerful enough device to go ahead and bootstrap everything on the client using something like React, that’s another layer of fragility.

We need to build defensively. I loved what Ariel said earlier. No matter how cool your objects look, when people can’t use them they’re failed products. That is exactly how it is with the websites, right? It can be amazing. It can be beautiful. It can be gorgeous. It can be developed with the latest technologies. But if it gets to the user and they can’t do anything with it, then it’s a failure. It’s a failed site at that point, so we need to prioritize the fundamentals.

A few years ago, Paul Lewis who works at Google, he wrote a post about Web components and how they get along with what he dubbed the three unsexy pillars: security, accessibility, and performance. As Paul pointed out, these pillars each have a few things in common. One is that they are absolutely fundamental to the Web and critical to success on the Web even if we may not realize it at first glance.

One in six people have some sort of a disability. Now if we apply some math based on our 3.5 billion people using the Internet, it means roughly 583 million people have some sort of impairment that may get in the way of them actually being able to use our site or application. From a security perspective, last year alone in the U.S., 90% - 90% of the companies had a malware attack where their machines were injected with malware or their servers were injected with malware. And in the last two years alone in the U.S., companies have lost a combined $740 million because of phishing scams, little basic security stuff that’s been around for a very long time.

As we saw from Paul earlier, 53% of people are going to leave a site if it doesn’t load in 3 seconds. The same study showed, you know, things with bounce rate, session length, and ad view ability. All of these things –performance, accessibility, security –they’re absolutely critical to the success of your site or application.

But the problem is the second trait that they all share, and that is that they are invisible. You don’t see these things. You don’t. I can look at a site, and I can tell right away that something is messed up with the layout and we’ve got to deal with it, or that the carousel is not working. But I can’t necessarily look at a site right away and say, okay, inaccessible. This is going to be terrible on a screen reader.

I mean maybe if you spend a lot of time in accessibility and you know patterns that you’re looking for, sure. But most of us can’t do this on a scan or performance on a scan or look at a site and be like, oh, that right there is probably a security vulnerability. We don’t see these things until something goes wrong. When they do, they immediately get pushed up to the forefront.

In 2010, the Patient Protection and Affordable Care Act was signed into law in the U.S. Did this make news over here in Germany, the healthcare gov thing? Yeah.

What happened, the whole idea was to make healthcare more affordable and attainable for, you know, U.S. citizens. Because it was political, it was, therefore, by default, very controversial. At the center of making this whole thing work was this site, healthcare.gov. It was going to be the marketplace where people could go. They could sign up for insurance, pick out their plan, and get all set and ready to go. The government knew how critical this was, and they prioritized this. They put tens of millions of dollars into the creation of this site.

It launched October 1st, 2013, and, to be honest with you, it is hard to imagine any site having a worse launch than this one did. I mean it was terrible. Within the estimated – the estimate was within the first week that maybe one percent of the people who tried could actually sign up for their insurance. The site was just ridden with all sorts of bugs.

One of the more prominent ones was around performance. The site timed out. It was notoriously slow. And it was weird to watch because, as a performance nut, usually you kind of stand in the shadows, you know, like, “Go, performance,” but there’s never any like real attention to it. But oh, my gosh, it was everywhere. It was on SNL was parodying it.

There was a – all right. Hold on. Just a little TMI reveal here, but there was a country music award show that I watched. No, there was a country music award show that had like a parody song about – they changed the classic country song, Amarillo by Morning to Obamacare by Morning.

It was lampooned everywhere. In fact, it escalated to the point where the President of the United States, during a news conference, said, “You know what? The website has been too slow.” Performance was in a press conference with the President. That’s how bad things got.

They prioritized it. I mean, and over the course of several months and with several consultants and much more money spent, they were able to fix some of the issues. But the problem is that this was already, like I said, a controversial thing. It’s a political thing. There’s a divide here, so people already were kind of – some people were already skeptical. Some were already on the fence. And it doesn’t help situations when you have to wait three, four months for actually to work. It leaves a bad taste in those people’s mouth, and it’s very hard to get rid of it. And I’d argue, for a lot of people, it still lingers.

In 2007, Target was hit with a pretty public lawsuit for being inaccessible to visually impaired and blind users. Now in this case it didn’t get quite the publicity. We never got to the president level here or anything like that. But they did end up settling out of court, and they ended up paying $6 million in damages for having an inaccessible site.

Now, I know what some of you might be thinking. All right, it’s an e-commerce site. Maybe accessibility was kind of hard to do, right? Maybe these were some complicated things that they had missed.

Here’s what was singled out in the report about why they had to pay the damages:

  • There was no alt text on images.
  • You couldn’t use the keyboard in the checkout process. It had to be the mouse.
  • They used image maps, which were inaccessible.
  • and they had missing or pour header structure.

Now I’m just going to hazard a guess. Anybody here who has written any HTML and just a teeny tiny little bit of JavaScript could probably have fixed all of these issues. I bet you didn’t know when you were adding alt, you know, text to images that you were actually saving your company $6 million. Go ahead and try and get a raise off of that. We’ll see how it goes.

Audience: [Laughter]

Tim Kadlec: This isn’t rocket science. This is pretty basic stuff, fundamental stuff. Then of course most recently, October 21st, the day everybody around the world went up in panic because Twitter was down, and some other sites, GitHub and The New York Times, and stuff like that. But what happened there was Dyn, which was one of the major DNS providers, was hit with a distributed denial of service attack.

Now for those of you who don’t know how that works, here’s how it goes. There’s a server somewhere, right? The server is, you know, hosting these sites. It hosts GitHub. It hosts Twitter, whatever. Let’s say this is the server that’s posting it out.

A distributed denial of service attack works this way: You have an attacker who wants to take this down. What the attacker does is the attacker finds vulnerable machines, and he injects malware into these vulnerable machines, basically turning each of these machines into bots that he now controls without you, the person owning the machine, actually having any awareness of what’s happening, right? With all of these under their control, he could communicate to these bots, this botnet, and these can then send off requests out from them.

What he can do is he can have them all bombard at one time, so you get a bunch of devices just hammering on this thing and trying to take it down. If anybody has ever played dodge ball and you’ve been the last person on your team, it’s like everybody pretty much on the other team is still there, they have all the balls on their side, and they’re all about to throw at you at once. It’s like that, basically.

Now it’s funny because when we see this sort of stuff portrayed in Hollywood, it’s always pretty glamorous. You love the tech gadgets that you see like James Bond using or in the Mission Impossible movies. There are always these, like, super cool, high-tech little things like the watches that explode and whatnot.

In this case the way that they did this was with baby monitors, Web cams, toasters, and all other Internet-connected-of-things things. That’s what it was. Half the Internet was taken down by baby monitors, people.

Audience: [Laughter]

Tim Kadlec: Just imagine what happens when this thing gets access to the Internet. We are so screwed. This is a device with a legitimate beef.

All of these things, the security, the performance, the accessibility, all of these scenarios, these could have been avoided. But they’re in-the-moment technologies, so we don’t see them until something goes wrong. Occasionally they do go wrong, and occasionally they move to the forefront. But for the most part they’re sort of in that unpredictable, long tail of experiences.

I always like to think, too, that it’s very much “you don’t need them until you do” sort of a thing. We have a temptation, I think, to categorize the people who might need these features. We say that, okay, we’ve got – let’s see. We’ve got some people here who are going to be using some mobile networks. That’s about 20%. We have 3% of people who disable JavaScript. We have another 10%, 15%, or whatever that are using our site with visual impairments, and maybe another 15% with some sort of a motor impairment.

But the problem with this whole thing is people are kind of messy. We don’t actually fit in little, neat buckets like this. That’s not how it works. Right?

Maybe we’ve got people who have chronic motor impairments that are causing issues so they can’t use the mouse. But then what about this person over here who one day messes up his wrist, or he’s got some sort of an RSI that’s kind of acting up, and so he needs to rely on the keyboard that day?

What about these people here, right? They’re frequently fine using your site or application, but one day she wants to try and do her job outside on a bright day because she needs to. Maybe that’s where she works. The contrast of your site now presents a problem for her because of the glaring sunlight right on her device.

Or over here, these people who have the JavaScript disabled, right? But then right now this person here, she doesn’t disable JavaScript. But then right now this person here, she doesn’t disable JavaScript, but today when she’s browsing your site, for some reason the JavaScript doesn’t get delivered. The operator, like, strips it out, kicks it out, or boots it out. We like to pretend like maybe that’s not a thing and it doesn’t happen, but it’s happened multiple times.

In 2014, Sky Broadband classified jQuery very briefly as malware, and so they stripped it out. What happened is it just broke pretty much everything because jQuery is everywhere, right? It broke just about every site out there.

A few years before that, T-Mobile, in an attempt to sort of reduce the amount of data on the wire, started to try and strip out what it thought would be JavaScript comments, so it looked for this pattern. JQuery at the time had a little thing with a /* (slash, star, star), and eventually later on in the library was a / (star, slash), and so it stripped out basically 90% of the jQuery library on every single page that it was serving up.

Now in the case of the Sky one, that was actually pretty brief, like they kind of fixed it before too awful long. The T-Mobile thing was up there for a while. In these situations, suddenly everybody is a JavaScript disabled user.

These are fluid states. Having JavaScript disabled, having a visual or motor impairment that makes the site difficult to use, they’re not static. It’s not about building for the people in these scenarios. It’s about building for the fact, the inevitability that at some point everyone, even those of us in this room, are going to be in these scenarios at some point.

The thing is these outbursts, the Target, the healthcare, the Dyn thing that we talked about, these are huge, costly blowouts, and they could all easily have been prevented, so why weren’t they? I think we can all agree it’s because they’re bad people. It’s because the people working on the healthcare.gov site and Target and tweeting toasters are terrible human beings who did not care about their users. That’s the takeaway here.

No. You know what? I think that it’s tempting to assign mal intent. In fact, I have a feeling that many of us have probably done this a few times, especially on maybe like a little Twitter rant or something where we talk about, we get riled up, especially something like this that we care about deeply or that impacts people on a very deep level.

But the thing is, in all my years of working on the Web, I’ve never actually once, never once have I walked into an office and some body that I was working with came up to me and said, “You know what, Tim? You know what I’m going to do today? I’m going to make a crappy website. It’s going to inaccessible, unsecure, and I’m going to make it fat too just for fun.” Nobody has ever said this to me, right?

Everybody has the same goal. Everybody wants to do good work. Everybody on your team. There’s nobody on your team who is trying to purposefully ruin the performance, security, or accessibility of your site or application. They all want to do something good. It’s just about the awareness.

It’s not that. I think it’s just a more fundamental thing that we need to focus on here. It’s hinted at in one of the articles on Radware about the DDOS attack on Dyn. The author, she wrote that in the race for innovation and shrinking time to market, security was incorrectly viewed as a roadblock on all these IoT devices. It was deprioritized.

How many of you can relate to this? This sounds kind of familiar, doesn’t it? Does anybody work in an organization where you have a security team that does a review of your site before you ship or you have an accessibility team who does a review before you ship? Or maybe you have the security or performance cop who is sitting inside of your organization who is like, “No, we can’t do this because of this.”

That’s half the problem right there. Security, performance, accessibility, these fundamental pillars of the Web, they’re not the responsibility of some subset of your team. They’re the responsibility of everyone touching that site: your content strategist, your developers, your designers, your information architects. Everyone is responsible for them because, at the end of the day, it’s all about usability. It’s all about making the site available and usable to people in different contexts so that they can accomplish the goals they came to do.

If you’re going back, and you want to try and start this, like you’re not paying to these things in the organization, probably the most impactful thing you can do on any given project is make it visible as early as possible. The reason for this is pretty simple because you can’t fix what you can’t see, right? In fact, even if you could fix what you can’t see, nobody would care because you couldn’t see that you fixed what you can’t see, so it doesn’t work.

You need to make it visible from the very beginning. It needs to be constantly on the minds of everybody working on the project. Lara Hogan has talked a lot about this from a performance perspective. Lara has talked about, in particular, at Etsy. They have these monitors throughout the office that are showing videos taken from Web page tests that show how the site is loading over different connections or different parts of the globe. So when you’re walking through the hallway, you just are constantly bombarded with all these monitors, this constant awareness of what’s going on. That’s exactly the kind of thing that you need. You need to make sure that these invisible things are constantly being seen by everybody on your team.

Now there’s not videos really that you can apply for accessibility or performance. I guess you could take a video of a user actually trying to use your app in those scenarios and post it. But what you could do is you could try to incorporate some of these things inside of a dashboard. There’s a lot of different services out there that try to do a nice little, neat little report card for these features. Mozilla has this observatory feature that just launched, which is kind of nice, where it will test your security across a whole bunch of common features and what they think should be implemented there. What you could do with something like this is you could have that score prominently displayed in sort of a site health dashboard, as well as giving you a nice checklist, too, of different items that you could potentially be – that need to be fixed and addressed at some point.

From the accessibility side of things, you could do similar things with a tool like aXe. AXE has a Chrome extension. It also has – you can actually incorporate it inside of your application as well where it will do actual accessibility testing for you and sort of give you a list of validation errors. I’m envisioning a dashboard that might have your performance metrics. It might have how you’re doing security-wise based on this grade, and it may have as well the fact that you have 83 current accessibility issues. So every time you’re walking past, you’re constantly noticing that we’ve got these issues. They’re not being lost.

You can even go a step further. And if you are in charge of your build process or you know somebody in the organization who is pretty – you know, you can buy them a Coke or something and they’ll put some stuff in the build process for you, you can have this stuff automated. Addy Osmani made an accessibility tool where, actually, you give it a URL and it’s going to go ahead and test it against a whole bunch of criteria. Something like this could be done automated as part of your build process. Where I work, we do the same thing with, like, security. We test it against vulnerabilities, so you could have this sort of a thing automated as well.

All of these things can be taken care of without you having to spend too awful much time on them. They can be sort of automated to some extent to at least get the awareness because, remember, the important part here is not so much throwing tools at the problem to fix it. The important part here is we want to find ways to make everybody in the company conscious of the security, accessibility, and performance situation of your site or application.

If you are also sitting there at the moment, and you are thinking about, you know, okay, this sounds great. I like accessibility, performance, security, rah, rah, but it’s very intimidating, kind of, to get into, isn’t it? Has anybody ever felt that? Like anybody ever tried to do accessibility, security, or performance? I think because it’s so unseen and there’s just so many layers to it, it can be a very intimidating thing to learn.

I know that when I was first starting to try and get into any accessibility stuff, I was scared. I mean I’m serious. I was looking at all this stuff. I couldn’t make sense of the different guidelines. I couldn’t figure out, like, how do I actually adhere to this guideline versus this guideline? When does this apply? When does that apply? I was also terrified of making mistakes.

The thing to remember, too, when it comes to all this stuff is that expert does not apply here. I personally think that the word “expert” doesn’t apply on the Web, period, but it certainly doesn’t apply in these situations. Okay? There’s no such thing as an expert. There’s only people who have spent a little bit more time doing it.

Don’t be intimidated by the fact that you don’t know everything about accessibility, everything about security, or everything about performance. All you have to do is do something and then do it better. Don’t set out to fix everything all at once. Just remember that there is no perfect performance. There’s no perfect accessibility. There’s no perfect security. There’s no such thing. And I don’t think anybody is ever going to tell you that there is. Right?

It’s a gradual progression. You do one thing, and then you do it again, and then you do it again, and then you do another one, and then you keep doing things. A few months later you look, and it’s like, oh, wow, we’re actually pretty good. We’ve greatly improved our accessibility. We’ve greatly improved the security and performance of a site. And you do it by one baby step at a time.

This stuff doesn’t happen overnight. The knowledge doesn’t happen overnight. The cultural change that is required to make performance, accessibility, and security a priority in your organization, that doesn’t happen every night.

Here’s the thing. At the end of the day I firmly believe that when it comes down to this stuff, what we’re doing is we’re maintaining user’s trust. Right? They’re using your site for a reason. They have a goal. They have a task that they want to accomplish, and they trust you to help them achieve it. They trust you to be secure and not be leaking their information. They trust that you’re going to provide them with a usable experience no matter the situation.

The Web is meant to be for everyone, and that matters. That absolutely matters. We get so riled up about things like net neutrality because we know that it matters because we understand that everyone should have access to the same Web, to the full Web, not some subset of it. It shouldn’t be prioritized based on whether they can afford to pay extra for something or not. But here’s the thing. If we’re not taking the time to make our sites performant, accessible, and secure, we’re not giving people equal access to the Web.

Look. The Web is chaotic. It’s unpredictable. And sometimes that feels overwhelming. But if you put yourself in your user’s shoes and try to imagine how much more overwhelming it is from their situation where they feel they’re trying to just use your site to do one little thing, and every step along the way their access is being blocked. We, the people in this room, the people who are working on these sites, we are the last line of defense for the user. It’s our job to make sure that they have an experience that works no matter the situation, no matter the scenario, and it’s up to us to make sure that what we build is a Web that everybody can use.

Thank you.

Audience: [Applause]