(announcer) And give an overenthusiastic welcome to Meri Williams.

(meri williams) Excellent.

So the first thing I want to say is I sound English, but I'm not.

[NON-ENGLISH SPEECH] And I say that mostly because it puts the fear of God into English people.

[LAUGHS] There's a joke in England which is, somebody who speaks three languages is trilingual.

Somebody who speaks two languages is called bilingual.

Somebody who speaks one language is English.

And so my accent will also go a bit funny.

And being South African's great because we have this fantastic combination of being very blunt, because we were ruled by the Dutch for 300 or 400 years, and then the British took over.

So we'll go, that dress looks terrible on you.

I'm sorry I had to tell you that.

So we have the kind of blunt and then polite after the fact which is great.

I swear a lot.

I'm very sorry if that's a problem, but we are in Amsterdam.

It's usually not a problem here.

So this thing feels odd.

It's too close to my face over here.

So I'm not a front end dev.

I'm very sorry.

I grew up as a hardware geek.

Who's got kids in the audience? So when I was 15, I built part of South Africa's first satellite.

Once you've soldered something that goes into space when you're a teenager, it is all fucking downhill from there.

Don't let your kids do cool shit when they're young.

They cannot live up to their gawky 16-year-old version of themselves, and it sucks.

I came over here, well over here to Europe, I studied in the UK.

And I fell into being a corporate whore.

I was at Procter and Gamble for 10 years, but I'm OK now.

I worked on SAP for a long time, but I'm OK now.

And I eventually achieved escape velocity, and I managed to escape that and went and scaled up the government digital service.

So I was very lucky to be part of the team that did www.gov.uk.

I'm also the person who bought the Badger of Deploy, for anybody who likes the Badger of Deploy.

I have a backup of the Badger of Deploy still, because you have to have the physical badger in order to deploy to www.gov.uk.

And so arguably, one could steal a soft toy and bring the UK government's to its knees.

And I also made the www.gov.uk cake.

So I like that my legacy at www.gov.uk

is probably soft toys and cake.

There's worse things to be known for.

I really care about accessibility.

And I should say, I'm also not a front end dev.

I'm also not an accessibility specialist.

I'm a CTO.

I'm a geek and a manager, which used to just be evident by wearing a t-shirt and a blazer, but fucking hipsters have taken this back as a fashion item.

So now I look like I'm trying to be fashionable.

I'm really just trying to be [INAUDIBLE], exactly what it says on the tape.

And sometimes the reaction when I say that I care about accessibility is, well, of course you do, because basically I'm the one "The Daily Mail" warned you about.

There's some Brits in the audience.

There wasn't a good enough laugh there.

So does everybody know who they are? They're like a fascist tabloid.

They are everything that is hateful about nationalism.

And I'm the one "The Daily Mail" warned you about, because I'm an immigrant.

I'm foreign.

I'm employed, which means I'm taking a job doesn't belong to me.

It would be worse if I were unemployed, because then I'd be on benefits.

I'm disabled, and I'm gay, so I'm over there stealing their women and their jobs.

And my wife's English as well, so that works out brilliantly.

But the main reason I care about accessibility is actually because some of my favorite family members have had real problems.

My grandfather, well, both of my grandfathers ended up prisoners of war.

One of them stood on a landmine and lost a leg, and so had to deal with that for the rest of his life.

And you get a very different lens on the world when you watch somebody who's got serious mobility problems going through it.

My favorite great aunt got Parkinson's, and then found it very hard to do pretty much everything, because she'd gotten to a point where she'd often write down what she needed doing.

And then she couldn't even do that anymore, and it was very, very hard to watch.

And then a couple years ago, I actually ended up, my shoulder dislocated 180 times in 18 months.

And so I ended up operating completely one-handed for about a year.

And you'll notice from these like stock pictures of people in slings, they look really happy.

It is not a very happy experience at all.

If you do one thing after this, go back to your day job, and try to use your workstation, your life, and your sites that you built or your apps that you built one handed, just for four hours.

I dare you.

And then tweet about it.

It'll be very entertaining for all of us.

And accessibility and inclusion are really broad topics, and so think beyond just screen readers and colorblindness, which are probably the things that we've gotten a bit better at remembering to care about.

So these are actually really low numbers, which is surprising.

And there are a number of other studies that show much higher numbers.

But at the very lowest level, we think that we've got about 8% of the population that has trouble lifting or grasping.

You have to lift and grasp a mouse and a phone.

And quite a lot of others find motor motions are really hard when you have things like Parkinson's, arthritis, or similar, which are increasingly prevalent in our user bases.

About 6% cognitive, mental or emotional impairment.

And then visual impairment or hearing impairment, 3% , 3.3%.

How low would a browser have to go before we said, oh, that's still too many people for us to really abandon.

Great point earlier.

Like we still do IE8, but we don't care about people with screen readers.

That is the wrong way around.

And so I'm going to talk less about how you do this, because I think most people actually know what the best good practices are.

Thank you very much for reminding us that best practice is bullshit yesterday.

So I don't think you guys need teaching about progressive enhancement, or graceful degradation or offline-first, mobile-first, office star first.

It's everything first.

And I don't think anything first is really the answer for this.

It's about us baking this into how we work and how we do things.

And that's really what my topic is today.

And it's really not just about design either.

Josh Marshall, who is fantastic, partially blind on Twitter.

He was the accessibility lead for, at first just www.gov.uk, and eventually,

the whole of the UK government.

And he was interviewed and said that actually the fundamental thing that www.gov.uk did,

that changed the accessibility of government information in the UK, was all about the style guide.

It was all about stopping departments writing what they wanted to say, and asking instead, what do citizens need to know? And again, to some of the points yesterday about, we're in this first world environment, where we've got access to everything.

We have clean running water.

We complain if the 4G is a little bit slow.

But even in the first world, 22% of adults have below basic literacy.

The average reading ability of an adult in the Western first world is that of a 14-year-old child.

And then add the people where it's their second language, their third language, their fourth.

I come from a country with 11 national languages.

I speak five languages.

I'm not even vaguely extraordinary by South African standards.

I have friends who can speak all 11 of our national languages and then three European ones.

And when somebody's operating that distant from what comes to their brain immediately, it's impressive they're getting anything done, let alone remembering where the apostrophe goes.

Grammar Nazis.

And so remember that this isn't just about the technology.

It's also about making sure that we're really designing our content, that we're looking at how we do this very holistically.

It's not just, when I zoom does it work, though that is important.

It's also, when I zoom, is it worth reading? Is it written in a way that's useful to me? The most impressive interview I've ever done with a UX designer was where she demonstrated, not only extraordinary empathy, but also a real understanding of the users she'd been working with.

And that was because she was working with banks, and there's not a lot of people I know who can find any empathy for bankers.

But she'd realized that actually they were completely impaired by their environment.

They were often on the phone like this, and then they had a mobile in their other hand, getting a text from whatever insider information broker they had.

I don't know.

It's all bullshit and illegal.

And then they had three or four screens in front of them.

And so rather than just wanting to go, fuck you guys, which would have totally been my reaction, she found it in herself to just go, these people are basically impaired by the environment, by being so busy, by being so distracted.

How can I reduce cognitive load for them? And so even our users that are lucky enough not to have any kind of impairment or disability, they probably got a whining toddler or an annoying boss or a traffic jam that they're getting through while they're desperately trying to read on their cellphone, even though that's also illegal, or similar.

And it's again, not just about making sure that we do the technical things, but also about making sure we test it.

And broad and inclusive, and user research and usability testing, really matters.

How many folks make sure they actively recruit users with any kind of challenge into their usability testing? One or two lonely hands.

Talk to them in the break.

They've got some tips for you.

So I've got two anti patterns and then a bunch of patterns of what makes this work.

And too often, we just try and rush this in at the end.

We go, brilliant, the site is done.

Oh shit, some people need to magnify, right? And that is just unprofessional bullshit.

I dislike that enough.

I have two note gifts for you about that.

The [INAUDIBLE] is the best.

No, no, no, no, no.

So let's not do that.

Let's talk about how to bake it in.

And so the first thing, and I'm making an assumption that most people are familiar with Agile.

Who is familiar with Agile? I'm going to keep asking you questions to keep you awake.

Excellent.

Sea of hands.

I'm not going to do any kind of introduction to Scrum.

So I'm assuming that some of you don't operate in an Agile way.

But some of these tips may still be useful in those of you who are in Agile.

Hopefully, the terminology is useful when you go back to your team.

So the first thing is write down your team values.

This sounds like corporate bullshit, and I appreciate that.

I am not asking you to write a vision statement.

I'm not asking you to write a mission in poetry that will sit on the wall and never be read.

I'm asking you to just write down what you guys give a shit about.

And so that might be in more technical terms, things like the Boy Scout rule.

Does everybody know the Boy Scout rule? Can't tell if that's a yes or a no.

So leave things better than you found them.

If you go and edit something to fix a bug, if there is not full regression testing on that module yet, you write some.

You don't leave it just as bad as it was when you found it.

There's also things, like refactor whenever you touch, rather than trying to leave refactoring for later, which is never.

I've been a product owner.

There has never been a time where I've gone, yea, fuck the users.

I want to work on technical debt.

And you know what? I'm right when I say that.

And the product managers I work with now are right when they say that.

But as engineers and as professionals, we need to make that what we do as we work, not a thing that we leave till later.

There are genuinely so many things that you can do, even up to the architectural level that you refactor as you go, rather than waiting for the big opportunity, the big project, to do it.

It might be things like the no seagulls rule.

Who's not aware of the seagull school of management? So the seagull school of management is when somebody who has previously been uninvolved, flies in, shouts at everybody, shits on everything, and flies away again.

I have a strong no assholes, no seagulls rule in my teams, and I would encourage you to adopt it.

But sometimes that involves kicking some executive ass as well.

Or it might be that performance is one of the first things that we care about.

And I think when you write down your values, it's a lot easier to have really useful conversations about what matters and why, and what's a priority and why.

And I think when you leave accessibility inclusion performance to the end, you are both making your life lot harder, because it's a hell of a lot harder to do it at the end, and doing a disservice to our users, because they are not going to get what they need if you only care right at the end of your project.

And so write down your values, and please make inclusivity and diversity part of those values.

I've genuinely never worked with a team where somebody hasn't had a relative, or a friend or a spouse or a child who would benefit, if things were actively more inclusive.

And just remind people of that.

People can be reminded of the humanity, even in the middle of an Emacs versus Vi war.

That's a little bit harder.

But it's possible to get people to remember that these aren't just users, or idiots as is the interference from the tone sometimes, they're real people who are trying to get shit done.

And we can either help them or hinder them, and it's better to be helpful.

And then the other thing I recommend is try and arrange your work as deliberate practice.

And I know some folks will know about deliberate practice.

But for those who don't, who's read "Outliers"? A couple of people.

(WHISPERING) He gets it a bit wrong.

Who's read "Talent is Overrated"? Anybody? "Talent is Overrated," because I'm a management geek, is my second favorite management book.

And I'll tell you my first, if you ask me afterwards.

"Talent is Overrated" is a fascinating book.

It's a load of very credible research, very, very well done science, and that was all about looking for talent.

And what's most fascinating to me is that they didn't go looking to prove that talent is overrated.

They went looking to find talent.

They wanted to figure out what made Tiger Woods amazing.

What made the best violinist in the world the best violinist in the world? And could we identify them earlier? Could we find that talent and then be able to select them as even younger children? And so they went to the, again I'm not great at names and places, so they went to whichever the best violin school is in the world.

I think it's in Germany, probably Berlin.

And they asked the lecturers, who are your future world class soloists? Who are your, they're going to be in an international orchestra, but they're probably not going to be the soloist? Who are your music teachers? And they asked them to divide them up into those categories.

And then they went and looked for everything that was the same and everything that was different within those.

And the only thing that they could find that was genuinely different was the number of hours that they had spent practicing as an individual.

I don't play the violin, but apparently if you're a violin player, the most boring part of being a violin player is practicing on your own.

The best part is playing with the orchestra.

The worst part is practicing in your room, on your own, because it's boring.

But those who were in that top tier had arrived at this magnificent school with over 7,000 hours of individual practice under their belt.

The next lot down were under 5,000 hours.

And the next lot down were under 3,000.

And 3,000 hours, 5,000 hours, this is the science behind the 10,000 hour rule, which I appreciate some of you may have seen some articles discrediting it.

They'd discredit the headline, which was misunderstood, more than the actual really quite well done science.

And another example that's very interesting is sport.

And ice hockey is where a lot of this knowledge came from.

There was professor watching a game in Canada, as you do, where violence is an aphrodisiac.

And that one didn't go down so well.

Clearly, clearly like sex not on the agenda on a Friday afternoon in Amsterdam.

We're probably the only part of Amsterdam not caring.

And his wife was sat next to him at this game, clearly not as involved in the game as he, reading the program.

And she said, that's weird.

They're all born at the same time.

Anyway, very dismissively, no, they're not.

This one's 26, and that one's 19.

There's quite a range of ages.

And she went, no, I don't mean their the same age.

I mean their born the same months of the year.

And she was right.

They were almost all born in January, February, or March.

And they eventually worked out the reason for this is that you start playing ice hockey when you're four years old.

And in Canada, the cut off for which year you're in is December.

And so if you're born in January, February, or March, you are the oldest in your year.

And if anybody's got a four or a five-year-old, the difference of a few months when you're four years old, makes a big difference in your size, in your level of coordination, and in your ability to skate and hit things with sticks.

But that advantage doesn't last very long.

So why does it last all the way through to being a pro hockey player? And the reason for that is also very interesting.

Which is, if you are selected at a very young age for a specialist sport that requires specialist equipment, then the fact that you're bigger, faster, and stronger than the other kids when you're four, means that you play more.

And then when you're five, you're in whatever the hell the mini, the little league equivalent of high hockey is, tiny bruisers, whatever.

And it is a wonderfully violent sport.

And I come from South Africa.

Rugby is a quiet Saturday afternoon for us.

Water polo is our true violent sport, so I find ice hockey impressively aggressive.

And so, it kind of snowballs.

So you get a lot more access.

You get a lot more practice.

You're more likely to be practicing before school.

You're more likely to play a match every weekend.

Whereas if you're in the second or third squad, you're not going to get quite as much experience.

And interestingly, the counter example that proves this is basketball, because basketball football, arguably, you don't need any special equipment.

You need a ball and a hoop or a field, and it's pretty easy to go out and play one-on-one or two-on-two, or even just to improve your skills on your own.

Where it's quite hard to get good at beating somebody up on the ice, if you have neither ice nor somebody to beat up.

And so it's a very specialist equipment sport.

And so what this teaches us is that we're good at what we practice, providing we can learn from it.

And out of all of this research came this definition of deliberate practice, which is up in its academic glory for you there, but is essentially whether we get into the flow state.

It needs to be challenging, but not frustrating.

It needs to be engaging enough that we want to do it, but hard enough that we find it a little bit interesting to address the problem, because otherwise we get bored or we get frustrated, when we go play GTA.

And so when you try and design work in this way, you want to take advantage of whatever you already know.

Try something new, which is not so far beyond what you already know as if you can't do it, but is within your reach.

And then get immediate feedback on how you did.

And then do that enough that you get really good at that task.

And so I grew up, I hesitate to say this in a room full of geeks, I grew up coding in Turbo Pascal.

[LAUGHS] And then I got to program in Python at university, and that was fucking awesome, because I didn't have to wait for everything to be done and to compile, to then go ah shit, it doesn't work.

I could mess about in the interpreter.

I could test out little snippets of code before doing all of it, which when I was doing artificial intelligence research was awesome, because you really don't want to set your simulation going, and then realize that one of your robots just spun in a circle for three days.

And that's why your results aren't quite what you wanted them to be.

And so that immediate informative feedback is really helpful and really valuable.

There's a few different models of deliberate practice.

So the sports model is now just conditioning.

So that's like, if you're a football player, you do weights.

Or a soccer player, as the rest of the world would say.

You do weights, and you sprint, even though lifting weight is definitely not a part of the actual game, because that's all just kicking.

Sorry, I'll stop being nasty about football in just a second.

But it's your fault for [INAUDIBLE].

That did not exist before fucking foreigners turned up for the World Cup.

[LAUGHS] So there are things that you can do that make you better at a specific skill, which is not exactly what you would do day-to-day, but is helpful with what you would do day-to-day.

And so one example for us is like, if you can type accurately and fast, that's not essential for being a developer, but it sure as hell helps.

There's a test model where you look at what somebody in the same situation did, and you go, would I have done the same thing? And you try and predict your own move.

And then you go on, what did the grand master do? And the music models where you chunk things up.

So you go, I'll get good at this bit, and then I'll get good at that bit, and then I can string them together and generally be better at this.

And so when you go back next week, after this excellent experience to do your normal job, which may feel a little bit of a come down because this has been pretty awesome, figure out whether your work is designed to be deliberate practice.

Is it challenging, but not frustrating? Is it taking advantage of the stuff that you already know? And are you able to get feedback on whether you're doing it well pretty quickly afterwards? One of the things I love in Agile is that respectives are such a part of how you work.

And so rather than waiting till the very end of something, and then going well, the next unlucky bastards who try and do something like this should learn these lessons from us.

I've been in so many lessons learned sessions.

Learnings sessions.

Learnings is not a word, people.

Corporate people need to stop using that word.

What's great about Agile is that during the work, every week or every sprint, the team will sit down and go what's working, well, what's not, and what do we want to do differently? And that's really, really helpful.

It let's you tune your process, as well as your product, is you go.

And if you've got a team charter in place, one of the things that you can then do every week is make sure it's visible, make sure people are remembering that you all said up front that you cared about accessibility or you cared about performance.

But nobody's done anything about it in the last three weeks, and is that really OK? And as an aside, it's just a language thing, but please do retrospectives.

Don't do for postmortems.

Something has to die before you can do a postmortem, and you really shouldn't be letting things die before you look at what went wrong.

Another thing that's a useful approach is to do what are called accessibility testing katas.

Who uses katas for other forms of testing or coding? Ooh, that's an x-rated.

I forget which martial art.

It's probably not karate, but it's stealing from martial arts where you basically get very good at specific movements.

It's a bit like the sports model of deliberate practice, and even the music model of deliberate practice, where you get good at the specific skills that you're learning.

And so one example with testing katas is that you go in, and you go I'm going to test this piece of software very deliberately, doing the expected result, unexpected result, fucking weird result.

And that's when you'd put everything from a zero to a very large number, and then a negative number, into instilling that it is expecting something between zero and 20, and just check how it blew up.

And you do that repeatedly to get yourself into the mindset of always remembering to do minimum maximum wild card when you're testing.

And accessibility katas are a similar approach.

So you go, let's today when we do our testing, or when we go out and do our usability, or when we go out and do our user research, let's adopt a specific constraint.

And we do this.

We did this when we go, let's test how it works without JavaScript turned on.

But we don't remember to test how it works with if you assume that somebody was colorblind, or if they had no sound, or similar.

And so you adopt one of those constraints and teach yourself by practicing how to take that into account.

And one of the things that's really helpful with that is it becomes second nature.

And we'll look a little bit at how the psychology of how we develop skills in a second.

The other thing to do is to define done appropriately.

And I've seen this work really, really well with Agile teams getting better at testing.

So it's not done until tests are written, tests pass, and tests are really comprehensive.

It's not done until there's full coverage.

It's not done until we've done the performance checks.

Let's add, it's not done until it works on mobile.

It's not done until it works offline.

It's not done until it works excessively to those lists.

And that makes it part of our everyday.

That means we're not waiting until the end to gold plate it and polish the turd as the Brits say.

Don't leave it right to the end.

Figure out how to build it into your process.

And I get that having this list of seven things to go, is it really done, but is it really done, makes you feel like an idiot.

But we do that already.

We've just internalized a load of the other things.

We've already got to the point when we go, does it work in every browser? Have we tested it with and without JavaScript? Do we know what's going to blow up if the underlying data model blows up? We've adopted those things.

They don't feel like extra work anymore.

And we need to get some more of this performance, mobile, and accessibility stuff into our day-to-day in order to be successful.

The reason that it gets easier is because of this.

This is the model of how humans develop skills.

We all start off unconsciously incompetent, which sounds a lot like a stack do in Amsterdam, passed out and useless.

But it's basically when you want to drive a car, but you have no idea, you don't know what to do yet.

You then move on to being consciously incompetent.

You're grinding the gears.

You almost hit somebody every time you go out on a driving lesson.

You don't know which way to look.

You check your mirrors in the wrong order.

But at least now, you know what you should be doing, probably because there's somebody sat there shouting at you.

And you're able to go, I know I screwed that up.

You then move on to being consciously competent.

And if you've ever seen a little kid who's just learned to ride a bicycle, or a newly qualified driver or a learner driver, they're so intent.

It's taking all of their energy, all of their focus, not to fall off, not to crash.

I don't know about you guys, but at this point when I drive to work, I arrive there about 90% of the time not even remembering the journey.

Because I am now able to just drive.

I am unconsciously competent.

And I think, I firmly believe, that if we adopt more of these considerations into our day-to-day workflow, we will end up able to just do it without it being any extra effort or any extra problem.

And that's why we need to build it in and bake it into how we work day-to-day.

The anti-pattern that I think has been mentioned a couple of times by other speakers is [WHISTLES] like a car mechanic does when he's trying to swindle you.

Oh, that's going to cost you.

Fuck that noise.

Accessibility, and inclusion of people who have genuinely no other fucking option than to use websites and our services and our apps, is not an optional extra.

It is not an optional extra.

We are professionals.

And you wouldn't charge extra to go, oh bug testing, we're going to have to add that on.

That'll be a gold plated service charge.

Fuck that noise.

That is not how we work.

Why on earth would we make accessibility an optional extra? Just please stop doing that.

I'll stop ranting now.

I think I'm running a little early because I'm probably talking too fast.

But the main things to remember here are articulate your team values.

And some of you may go back and find your team articulates a very different set of values than you.

And you can either choose to stay and try changing them, or to go find a new home where you feel more at home.

But have that conversation out in the open, very bluntly with people, to go what matters to us, what do we stand for, do we really want to further minimize and further make the experiences of people with impairments even worse? Or do we want to make it part of who we are, that we serve everybody equally, that this is for everyone to quote Tim Berners-Lee.

Value that inclusivity and accessibility.

I know that it's work, but make it part of the day-to-day, and it won't feel like an added extra.

It won't feel like extra stuff that you have to do.

It just becomes the same kind of consideration as you have for building good shit.

Figure out how to arrange your work as deliberate practice.

Is it challenging without being frustrating? Is it easy for you to get feedback on it? Are your team honest with you about whether what you've just done is shit? One of the things I loved on www.gov.uk,

we adopted an official rule that nobody should ever work on something for more than 10 working days, two weeks, without doing user research.

You had to go and check that it was really going to work for users before you invested too much time in it.

And that meant some rough and ready testing, and meant that we were sometimes taking stuff out that felt a little bit un-glossy, but it helped us detour around what could have been a real waste of time very well.

Do some accessibility testing katas.

I challenge you to go home and try and work 100 for four hours.

And then you can send me all of your sympathy tweets for me having to work like that for nine months.

It is not a gimmick to try and walk in your users' shoes.

It is something that can be genuinely helpful.

My wife's an architect, and she designs hospitals.

And there's a very weird, it's like a fat suit, but it's not.

It's a thing that they make architects wear on occasion to have them experience life in hospital as somebody who's geriatric and got arthritis, and has trouble moving.

And there are things that, if you're able-bodied, you won't realize that those stairs are just too high to be doable when you're shuffling in slippers with really bad knees.

And so some of it is just about finding a way to walk in somebody else's shoes for a while and see what's different for them.

Use a screen reader for a day.

Try it.

There are some cool widgets you can find where it will colorblind your site.

So make it how you would have to experience it.

Turn off all sound.

See if everything still works.

Turn off all sound, and see whether you really know whether things have happened.

I don't like having sound on ever.

And it's amazing how many sites don't give you any other indication.

How many apps, mainly it's apps rather than sites.

But they don't give you any other indication that something's changed, other than the beep or the swishing noise, or whatever.

So remember to do both.

Define done well.

We've already expanded the definition of done so much.

We've added needs for testing and performance and all these other things.

Let's just work something as critical as accessibility into there as well.

And remember that this shit gets easier.

The more you do it, the more you learn.

And the more reinforcement you get of that learning, the more automatic it will become.

And you'll be unconsciously doing it right before you can count the number of days.

And be awesome.

Be inclusive.

Thank you.

(interviewer) Come over to the chill out lounge.

(meri williams) [LAUGHS] (interviewer) Turn that off.

I'm glad that you very effortlessly, at the start of your talk, dealt with the microphone pointing to close to your mouth issue.

As I remember, one of my first talks I gave wearing one of those headsets, I had that issue where when I started my talk, I could hear myself breathing.

I was so nervous, my tactic was to stop breathing.

(meri williams) [LAUGHS] (interviewer) And I almost died.

[LAUGHING] (meri williams) I did consider for a minute, styling it out, and trying to do a full, "Luke, I am your father."

But you guys don't seem quite Star Wars-y enough audience for that.

(interviewer) This is web conference rules though.

So I think as developers were expected to cater for IEA a lot, because the client's company, someone high up, is probably a user of that browser.

And not a lot of companies have an assistive tools users on the board.

How can we convince clients that this thing that's invisible to them is worth the time? (meri williams) So there are two things that I've done that have been helpful.

And one is really educating them that there are assistive tools users even working in our industry.

And it surprises me how much that surprises people.

But I've worked with some fantastic people in the past who really operate fully with JAWS or similar and are brilliant at their jobs.

I've been lucky enough to bring them in and introduce them and show them how awesome they are.

Because I think a lot of people assume that people like that just don't use services, and that's where they've given themselves the permission not to give a shit.

And the other thing is talk to people about their families.

Because once you broaden it from being just people who are color blind, people who are using a screen reader, to well, your mum's got arthritis in her hands now, and she wants to use it on the iPad, because that's an increasingly common thing that the over 60's demographic are often engaging on tablet, on larger tablet, but they also have a lot of fine motor control challenges with arthritis and similar.

And helping people to realize that, I've not found anybody yet that I couldn't with one of those approaches convince them that it was more important than IE6 or IE8, whichever was on the table at the time.

(interviewer) So how do you start that conversation with a client? It seems like you're playing the clairvoyant thing at the start and saying, I see disability in your family.

(meri williams) [LAUGHS] (interviewer) We're going to fix that.

(meri williams) I usually start it by talking about my family.

And so I have got a lot of that in my family.

And the thing that made my shoulder dislocate, they've now figured out, is a fairly severe disability that makes all my joints dislocate.

So I can talk about my personal experience as well.

But once you start sharing, and maybe you're not in that position, but there's somebody you know.

It doesn't have to be a user persona.

It can be a real person.

And I think as soon as you're talking about real people.

And then people go, oh shit, I don't want all over 60's who have arthritis, because that's a pretty high percentage to not be able to use my site.

Yes, this is worth investing in.

(interviewer) I think if you don't have a close family member with a disability, I think it's easy to see people with disabilities as being completely helpless.

There's an absolutely great radio show that I recommend people seeking out is Richard Herring's "Objective."

He looks at the wheelchair and disability in general.

And there a comedian Francesca Martinez, and she's got cerebral palsy, and she really turns it around well.

She says to him, are there things that you're good at, and things you aren't good at.

And he says, well, I'm rubbish at DIY, And she says, oh, how do get around day-to-day? You're incredibly, incredibly brave.

(meri williams) [LAUGHS] (interviewer) How do you manage to go to the toilet? [LAUGHS] But even with that, I think when we get accessibility experts in to help with our sites, that's like getting one of us to use a test site, because we're experts in the browser, and you get an accessibility expert.

You're getting some who's an expert in assistive tools.

What can we do to get around that? (meri williams) And so I think that one of the most useful things is to broaden your participants in your user research that you do.

And I hope folks are doing user research and usability testing, because that'll make a big difference.

Josh Marshal's written some really good guidance for how to do that, including they're often harder to recruit, and it's often best to go to them, rather than have them come to you.

So if you can go to someone's house and see them with their set up and have them use your thing, then that's really helpful.

And then to use the accessibility expect to, A, develop that expertise in house where you can, help it be a skill that most of your devs are aware of what's needed, and that they're doing it.

But have it be that you do the first parts with somebody who's an expert, but the real learning comes from real people, the same as everything else.

We are not good users.

We are the minority in such an extreme way that it's not even funny.

We are non-representative of the world at large.

(interviewer) I think that's such an important point that going to someone's house, or at least getting them to bring their laptop, their equipment in, because we had that problem at the BBC.

We did some user testing, and our machines, we had these sweet machines with all the software we could find, but it wasn't set up the way they would use it.

It was a mad day because we had so many people come in with so a range of disabilities.

And I was so badly organized.

I found myself going down to the reception area to meet the next tester, and I'd forgot to look at what disability they had.

So there was an awkward moment, where I was in reception, where I was looking at them, like how much help do I need to give you, because you don't want to hold the hand of someone who's just got mild Asperger's that look like you're trying to patronize them.

But that kind of testing, that must be expensive, right? I mean it's not something a small company can deal with.

(meri williams) The same could be said of general user testing.

And we've come to accept that.

Again, part of our professionalism, part of doing our job well, is to test with real people and for the majority of things.

If you're building in house apps for a company, then maybe there's an exception.

But what's actually fascinating in that example is that, in the EU at least, a company with a disabled employee has a legal obligation to make reasonable adjustments for that employee.

And so actually, even if you're building something on an intranet or an in house thing, the company may not realize it, but they may need to make even more of an accommodation than they would for an outside customer.

And that's something worth knowing and worth reminding them of.

I think these things are not things that we can do for nothing, but nor is the rest of what we do.

I think it's part of building it in.

It's part of how we work, like when 20 years ago you would deliver software, and then you would genuinely charge extra for testing and integration.

And if you tried to do a bit that had that in your plan today, you'd be laughed out of the building.

And that's why I think it's important for us to build this in to how we work day-to-day, and into our base cost as well.

So track what it takes.

Track how much cheaper it is to do early, because it really is, really a lot cheaper to do it early than to do it late.

(interviewer) So you mentioned including everything in done as an ideology, but I've never been on a project where everything that is in done gets done.

They all get bumped to phase two.

And as we know, phase two is something that never even gets started.

And up against the wall, it's basic testing and then user testing, accessibility.

What can you to defend that? What can convince to work around that? (meri williams) And the reason that I included the bit about team values, even though it feels like the most corporate bullshit bit of it, is because that's the thing that you do about it.

Because, when as a team you've sat down, and that ideally should be part of the reason your client comes to you.

It should be part of the reason that your business partner, if you're in an internal team, believes in you is that they share those values.

And so if you think you can get that right, then it makes it a lot easier to have those discussions for it not to be an optional extra, because it's the way that we work.

And in the same way that you want privacy to be the way that we work, and the same way that you want things being maintainable to be the way that we work.

And I know it sounds a little idealistic, but I've genuinely seen it work really well with teams that have it upfront.

And as I've been managing people for quite a lot of years now, and that's the other benefit, is if what the team cares about is open and upfront people can self select in and out of that.

Because otherwise, what happens is you find at the end of phase one, the dev who really cares about doing it right, they leave.

Because they're just like, you fuckers don't give a shit about stuff that I really care about, so I'm off.

And it's one of the most common ways to lose really good, really passionate people, is to constantly de-prioritize things that they think are important in a human rights way, rather than just in a I really prefer place Python to Ruby kind of way.

I'm sure some people will leave because of Ruby, but that's understandable.

(interviewer) Well, I think a few years ago that performance had a similar view as accessibility.

It was very much an add-on at the end.

And we are seeing the type of change there.

It is becoming more of a cultural thing.

Is there anything that we can learn from that? I think we made that maybe from numbers, but also by introducing a competitive element to it, like people who run their stuff with WebPagetest to get a higher score.

Is there anything we can do there around accessibility.

(meri williams) I think it's something that we don't need to do, but it's happening to us already.

My perception is that a lot of the change in the attitude to performance is about the ubiquity of mobile.

And it's annoying when it's slowing your laptop or your desktop, but it's fucking impossible when it's on your mobile phone.

And I think the ubiquity of mobile really brought performance much more than stage four for everybody.

And I think the same thing is going to happen with accessibility, because we have an aging population that is enthusiastically adopting tablets, iPads, Kindles, et cetera, and so you can't assume any more that anybody who's over 65 with arthritis just isn't going to be using a computer, because that's bullshit.

And there's actually a really fascinating bit of research that shows that the adult demographic that spends the most time on Facebook is the over 60's.

And because they retire, discover that they can figure out what their friends from high school are doing these days, and so and so's kid got married, and whatever.

And they just start spending an increasing amount of time on social media.

And so we've got a turned up world for us.

Many of us have grown up with out grandparents not really ever embracing technology.

So the 80, 90-year-old folks now, they're not.

But you look at your parents, most of them will be.

And if yours aren't, other people's are.

My team and I are working for Marks and Spencer at the moment.

They've got interesting demographic that includes the older demographic being a big part of their fan base, consumer base.

And it's an increasingly interesting challenge for us.

How do you build an iPad app for someone who's hands shake? How do you build an iPad app for somebody who can't one handed do a pinch zoom.

Because those things are quite hard, if you start to have mobility problems in your hands.

And that stuff is getting a lot more important.

And you can make an interaction change, and find out through loss of sales that it's made it harder for people to use, and then you find out that more people are calling the contact center because they can't shop from their sofa anymore because it requires a hand movement they can't do.

(interviewer) I think you're absolutely right about the social media thing especially.

My Dad retired this year, and it's got to a point now where Jen will say, I posted a status to Facebook 10 minutes ago, and your dad hasn't liked it yet.

(meri williams) Is he OK? (interviewer) Do you want to give him a call and make sure he's not trapped down a well or something.

[LAUGHS] (interviewer) What's www.gov.uk's

approach to accessibility? What kind of testing or proof is required to ship something? (meri williams) So to be open, I left in the beginning of last year, so I'm not up to date on it.

They blog very well, and they blog very openly.

I think Josh has just left them as well.

But generally, you had to have considered it.

You had to have done usability testing and user research including a wide demographic.

But equally for www.gov.uk, it was

really easy to make that argument, because the consumers of www.gov.uk

are the entire citizenry of the United Kingdom.

And so there is absolutely no way in hell that it is defensible to exclude any group.

And arguably, that then makes it easier to include them.

And it had to include things, like have you tested without JavaScript.

One of the most interesting things for www.gov.uk

was that the stats after the first nine months, I think, there was a great article they published, that one in 100 visitors didn't ever get the JavaScript payload.

And that was not because one in 100, 1% of have JavaScript turned off, but because you're on mobile.

And it doesn't download fast enough and all of those things.

And that's the progressive loading approach that was talked about earlier, and that's become very much a part of how they think about things and do things, because of that.

Because you need to plan for failure in the system to mean that people don't get all the content you've pushed them, rather then because they've been the one weird person who has decided that JavaScript isn't for them.

And that kind of rhetoric is used a lot to dismiss the it needs to work with JavaScript turned off, or it needs to work without.

There used to be an argument to get Flash.

It needs to work without Flash.

It's only you developers who don't install Flash.

That kind of stuff.

(interviewer) Nobody has your JavaScript until they've downloaded your JavaScript.

(meri williams) Thanks.

(interviewer) Thank you very much.

Meri Williams.

(meri williams) Thanks.