At Accessibility Scotland 2017 Heydon Pickering @heydonworks talked about how cooking a good curry is superficially complex, and quite time consuming.
There are a lot of ingredients and steps to remember. But once you’ve learned a few core principles, you start turning out a lot less flavorless gloop.
With practice you can even get quite inventive, confident that no culinary disasters are imminent.
Hello everybody. Yeah so, couple of apologies.
First of all, I’m English. That’s the first one.
The second of all is I managed to, how do I put this delicately?
Completely fuck my back on the way to the venue today.
I was running for the bus, it popped, and you may have seen me sort of laying around the venue.
So it’s gonna be a bit of a struggle for me but I’m gonna get through as much as I can because I’ve been really looking forward to doing this.
These aren’t even the clothes that I brought with me because I lost all my luggage on the way here as well. So it’s really been…
It’s been fun so far. But I’ve really enjoyed the conference.
Actually, this happens to me every time I go up north. I spoke in Manchester with food poisoning last time.
So I was gonna do a talk which was gonna be really political and was gonna be about European legislation and about how we were gonna be subject to lots of new rules which would help us to be able to enforce and mandate accessibility and stuff.
And it then it was gonna be all about the fact that Brexit happened in the UK, we wouldn’t be subject to that anymore.
I’m from Norwich, by the way, we voted to remain, much like Scotland, by and large voted to remain, so I’m on your side.
So if you’re gonna form a revolution, please don’t, like, invade Norwich.
So, as I was going through that sort of, I got kind of depressed, writing it, so I decided I’d talk about something I love instead, which is cooking.
And it took me a little time to take up cooking because I didn’t think I’d be very good at it. And it’s, I suppose it’s kind of a cowardly thing, but I thought, well, I don’t know how to cook already, so I won’t give it a go.
And then eventually, little by little, I did.
And it’s kind of like that, I think, for a lot of people especially developers, with accessibility. I think they find it hard to start because it’s not their area of expertise. It makes them vulnerable.
But anyway, I found a lot of comparisons, I think, between Inclusive Design and cooking curry, specifically, which I want to talk about today. It’s a sort of a tenuous analogy.
So, first of all, research. In terms of research, there are two kinds of research: market research and this design research.
Market research is all about interests, tastes, hopes, dreams, all that sort of stuff.
So who here likes curry? Put your hands up, please. Yeah, that’s just about everyone. But, the point is I’m not interested at all about any kind of impairment or ability or disability that you have, all I need to know is that you like curry.
And if I know that you like curry, regardless of what kind of impairment or disability or whatever you have, I will find a way to feed it to you. I will get it in your gullet, right?
So that’s market research. All I need to know is what you’re interested in or if you’re not interested in it.
Design research is a bit different. Design research is actually about how I would go about delivering the curry into your body.
So, you know, it’s really important not to confuse these two things, ’cause if you confuse these two things, you end up in the situation where you’re asking questions like, do people in wheelchairs really go on holidays? Do I have to market towards them? Do I have to create stuff for them? Or, you know, do people with arthritis like photography?
And you always hear that’s really dangerous territory, so you want to avoid that as much as possible. So, separate those two things.
Of course, if it’s inclusive design research, it’s about how, you know, how to cater to as many people as possible and not not exclude as many people as possible.
When you’re cooking curry, you might be inclined to put in some cream maybe, or some ginger, but there will be some people who don’t like cream, and there’ll be some people who don’t like the taste of ginger. And that’s okay because you could actually have one of those things omitted, or both of those things omitted, but you’re still making a curry.
So it’s okay. So you still have the product that you want. And it’s really important when you’re establishing what people like and what people are looking for in your curry or in your design. It’s really important to prioritise.
So allergies, obviously, are more important than palettes, and disabilities are more important than preferences.
In inclusive design, we try and do the best for everyone, and often when we’re catering towards disabilities and it has an effect and it helps people who don’t have a serious amuse case there.
But you should always prioritize. So rule of thumb being always prioritize things which people can’t help.
If you saw, I mean if people can get on with something then it’s not so much of a big deal.
So for instance, and this always happens, I don’t know if anyone really does a lot of cooking but there’s always gonna be someone who has an opinion about the way that you cook, right?
They’re gonna lean over your shoulder whilst you’re doing it or they’re gonna send you emails, or whatever it is, and they’re gonna suggest like, I think that you should do it this way.
So there’ll be like this fellow on the left here who insists on, it’s not really a Vindaloo unless you put a bit of cinnamon in it. And so he’s insisting on having cinnamon in his curry, and on the other side here we have someone who’s literally will die if they eat cinnamon, because they’ve got a terrible reaction to it.
So obviously I’m gonna prioritize Jeff over Robert, because it’s more crucial. It’s more critical. And one way of dealing with these situations is to substitute things.
So we talked about cream before. If someone doesn’t like cream, then maybe it might be a good idea to instead have yogurt, and the key thing here is that cream is obviously different from yogurt, but in terms of what it offers in curry, in terms of the richness, and the thickness and the creaminess, it serve kind of the same purpose.
And if you discover that actually more people get on with yogurt, then it’s a no-brainer to use that because it covers more people and more people are satisfied, but you’re not actually, you’re not having to admit a critical sort or dimension to what you’re cooking.
Works the same with interface design.
So for instance, infinite scroll. Some people are quite happy with infinite scroll.
A lot of people aren’t even aware that it’s happening, and it’s perfectly fine.
Whereas there are some people, of course, for which Infinite Scroll is a real pain.
So for instance, keyboard users will have trouble with infinite scroll because as they’re trying to find the focusable elements in the footer, or for the document on the webpage, they keep having these other elements sort of thrown in their way that they have to then focus on, and it’s actually literally impossible to get down to the bottom of the page.
So what you can do is maybe do something a bit different. So maybe you provide a ‘Load More’ button.
Now the thing is, the ‘Load More’ button may be slightly less ergonomic or intuitive, or easy and delightful or whatever for some people, but it works for everyone.
So you have to make that compromise.
Carousels is another example. So, carousels are pretty universally accepted as the worst possible way to provide and present content.
A lot of research has shown that people just don’t understand carousels. They don’t want to use carousels, they’re distracted by carousels, and made to feel nauseous by carousels spinning round and everything, so you probably want to substitute that with literally anything else whatsoever.
And to sort of stretch the curry analogy here, I think carousels are a bit like raisins in curry.
In a sense that there are some curries, like maybe a biryani where you would put little bits of chopped fruit and stuff in there, and that works kind of okay.
No problem. But most of the time people are gonna avoid the fruit in their curry, since having fruit in curries is weird.
Number two, second reason that curry, cooking curries and inclusive design are similar is there’s a lot to remember.
If you start along the path of thinking that different people do things differently and that’s in terms of preferences, in terms of abilities and disabilities, in terms of situations, then you realise that there’s actually a lot to consider, a lot to think about, a lot to plan when you’re designing interfaces.
A slight aside here, I drew this picture. I’m not particularly proud of it, and just to be clear, that’s meant to be a chef’s hat, and not a tidal wave, which actually looks like it’s happening there.
My dad cooks really, really good curry sometimes, but the fun is he never writes anything down so he can never recreate anything.
It’s much better if you get something right because you’ve invested a lot of time in it ’cause you’ve had to think about so many different people and the different ways they do things.
It’s important that you can recreate that again later. And when you’re writing comments in your code, for the developers here, it’s really important that you describe why you’re doing things in a certain way.
So, writing toggle function is no good because actually the code could probably tell another developer that it’s a toggle function, but if you were to write something like toggle ARIA expanded to change state accessibly, then I think that’s a lot more useful.
And it tells the other developer the reasoning behind why you did it that way which I think is really important.
Obvious analogy, but I think pattern libraries are cookbooks, and obviously I’m going for a cooking sort of thing here.
And the point is that you start with a, you start with an exemplar, like a template, a component which you document in your pattern library, and the idea is that you can just take that and you can place it in your different products and knowing that it’s a tested thing that is dependably going to be accessible in various demonstrable ways.
But the issue here is that this original component is kind of a single source of truth, and they’re lots of problems with single sources of truth.
Here are some examples of some single sources of truth, astrological chart, the Bible, Madhur Jaffrey’s Curry Bible, and Capitalism and Freedom by Milton Friedman.
Actually only one of those things would I rely on as a single source of truth.
The other three I think are highly dubious.
So, as with curries if you start off with a terrible recipe for shit curry, then obviously what you’re going to end up doing is cooking a lot of shit curry for a lot of people and they’re gonna stop coming ’round your house.
So you need to rethink the original recipe, which is why I started this blog a little while ago.
So I’m just gonna actually have a break. I’m struggling already, with my back.
Okay, so, so I started writing this blog (Inclusive Components) and because I though it would be kind of cool to do a blog as a pattern library and actually just break down generic components and try and explain the ways that the organisation should be coding them and designing them so that they’re basically inclusive.
And I thought, well that’s cool, but I wouldn’t have to write that much because actually there aren’t actually that many things that webpages are made out of.
It’s just links, buttons, inputs, showy hidey things, and openy closey things.
So it’s not rocket science, the web, but we still manage to get it all wrong, and we get it all wrong more or less in the same way.
So, for example, here is a kind of toggle button, and the way that just about all of the clients who I deal with who I do accessibility remediation for, just about all of them will get this wrong in these particular ways.
They won’t have an accessible state.
The will leave this text, which represents the state separately, unhidden, which means that the ARIA state and this state will contradict each other.
And of course, it won’t be a button. It’ll be a link instead.
And it should be a button because it’s doing a button-like behavior.
Here’s another example. You have the tool tip there. It’ll only appear on hover, it won’t appear on focus, so it’s not keyboard accessible.
It won’t be associated with the button itself, so the way you would do that probably would be to use ARIA describedby, to kind of link the two things together, so when a screen reader user focuses the toggle button, it will be read as the description.
They won’t know it’s there unless it’s associated programmatically.
And of course, it’s still a link, not a button. Here’s a drop down menu. That should have ARIA as pop up here, to indicate that it’s a pop up menu, and if it is a pop up menu, then the behaviour should be that the first item should be focused.
That won’t happen.
Either they won’t have ARIA as pop up there, or the behavior won’t happen, of focusing.
Arrow key navigation won’t be implemented so you won’t be able to focus between the items with the arrow keys.
That’s quite common. And the check state is not set interoperably, or it would just be set visually or something.
It won’t use ARIA check tool, or what have you. And of course, that button will be a link, and all of those buttons will be links as well.
Links are very popular for some reason.
I’m looking for suggestions for different components to talk about on this blog, so if anyone has any ideas for things then please get in contact.
So you can follow the Twitter account there which is @inclusicomps, and you can contact me there or at my normal Twitter account (@heydonworks).
Rule number three for why curries and inclusive design are similar is beware of third parties.
When you first start out making curries, it’s kind of daunting ’cause there’s a lot of different spices and different ingredients, so maybe you’d go out and you’d get like a pre-made jar of paste or sauce or what have you.
Makes it easier.
And they all have names with things like Uncle Satan’s Gastric Meltdown, Primordial Zombie Affluence, and my wife came up with this one, she likes puns.
Residue Evil Breaking Bum.
So it’s like a pun on Resident Evil and Breaking, I love my wife.
And this one, I think if I was gonna do my own sauce brand, I’d probably call it Doctor Volcano’s Ultimate Prolapse.
So, the problem with these third parties, the problem with these like sort of pre-made sauces that you might use, is that of course they have all of the ingredients in them and once they’re in there, they’re very difficult to extract.
So for instance, if you remember my friend Jeff who dies if he eats cinnamon, and there’s a problem here ’cause there’s no way that I can actually take the cinnamon out of this and I think you can probably tell where I’m going with this, this is true of like third party components and modules that you might install.
Now, it does speed up development if you rely on those things, but of course you need to vet them.
And in terms of performance and ’cause, they would tend to because they’re sort of public and in the open source they would tend to try to address everyone’s use cases.
There gonna be a lot of code in there as well so they’re gonna be quite underperforming and quite heavyweight, so where you can obviously it’s better to do things from scratch.
You can’t always.
Order is important.
So now I’m just gonna actually describe the basics of how to make a curry and the order of it is very important.
I only learned this when I went to curry cookery school, but that’s a whole other story.
But first you marinate the meat. So you get the meat, you chop it up, and then you cover it in like tumeric powder, some salt, and some vinegar and you let that sort of settle overnight for a bit, and then when you get to the cooking, you start with aromatics.
So, bay leaves, cumin seeds, mustard seeds possibly, or methi seeds, otherwise called fenugreek.
You start that, you get that in the oil and you get that sort of crackling and popping.
Then you add the onions, which should be chopped very, very finely so when it cooks it sort of almost turns into a paste.
The onions are there to thicken the sauce. They’re not like a main ingredient. You shouldn’t chop it into like slices. It should be like mashed up.
And then you add ginger, garlic, that kind of stuff.
And then only after that will you actually add the meat and then add the tomato paste and all of that kind of stuff.
So there’s a really important order. And I think you can probably see where I’m going with this.
Yeah, it’s really important to get the order right when you’re developing for the web as well. And there are so many accessibility question marks over content, and if you don’t get those right to start with then there’s no way that you can make an interface which is in any way sensical or usable to anyone, and anything which is unusable is necessarily inaccessible and uninclusive.
So you need to get the content right first.
Get the structure of the content right first, get the content strategy so that you know the interface that you actually need to make to expose that content.
Then you go to HTML, which is where you actually kind of inscribe this structure that you’ve come up with.
And then you add branding I suppose, all CSS is really is branding.
So it doesn’t matter whether you’re using assisted technology or not, I think it’s really important to think of HTML as the interface.
It’s the fabric.
It’s the thing you actually interact with.
It’s the thing which elicits the browser’s behaviours, and the more you think about it like that, the more of what you realize it is and why it’s important to think about it early on.
Unfortunately, we do something a bit different.
So it should be kind of like this where HTML is like the foundation, and then you style it, you make it look good, and then you add the behaviours in, but what we’ve done is this, where we’ve sort of torn it off the bottom and then nailed it to the top like this.
The idea is that it’s really flexible.
The problem is that HTML shouldn’t really be that flexible because there are only certain structures which work, you know, certain heading structures and regions and everything that should be in certain places.
And then this part here, the HTML part here is what I do as part of my job, which is a client will come along and say, oh, we really need help because our HTML is really inaccessible.
And Suze the other day, was kind of thinking out loud about how, and she was thinking about frameworks, and the frameworks aren’t necessarily inaccessible, of course, it’s how you use them.
But like if there was one which actually could add a or accessibility at the forefront, what kind of shape would that take?
And I think it would be a framework which had very, it would be very opinionated about the HTML e-road. And it’s not just assisted technologies, of course, that benefit from structured HTML.
There are other areas as well, of course they do, but it’s CSS failures so if you have a CSS failure but you’re using really good structured mark up, then actually it might even be just about traversable.
You know, say if you’re on a bad network, just might still be able to fill out form if it’s using real form elements and real legends to actually structure it, because the user-agent will still provide styles.
So that helps visual users on poor networks, for instance. Performance, as well of course, because if you’re constructing interface elements from scratch using like divs and ARIA and stuff, you’re writing a lot of the like the standard browser behaviour yourself, in your own scripting, which is all unnecessary.
If you rely on what the browser does naturally, then that’s less code and it’s more efficient.
And of course, things like reader modes, like iOS 11, reader mode if you’re using good structure content then when it interprets it and passes it into reader mode, it will result in a much better translation.
Okay, number five, I think there’s about nine of these.
I’m sort of, I think I’m alright. I think I can probably get through at least eight.
Sorry if you wanted to go early.
There’s no magic bullet. So if like me, you wasted a lot of your time in the early 2000s watching music television, you got really fucking sick of the Red Hot Chili Peppers, and it’s the same with curry, of course.
You can make curries without chili. You don’t have to put chili in.
Chili is a good ingredient in curry, if you like your curries to have a background of heat and to sort of spice things up, and it’s sort of the same with ARIA in HTML.
It can enhance things but you don’t have to use it obviously to have an accessible experience. It depends on what you’re trying to make.
So here’s a little example.
So I want to have a button which is used to disclose that there will be a region that’s either open or closed, it’s available or unavailable both visually and nonvisually.
So I’m using the ARIA expanded attribute there.
So at the moment, if that’s focused with ARIA expanded force, it will say button, edit, unexpanded or something.
It depends on the assisted technology your using. But the point is, all I have to really do is add the states because so much information is already in the button part and the disable part here, which is just standard HTML.
Just because I’m using ARIA expanded doesn’t mean I have to build everything else from scratch, which is obviously really inefficient and is really not robust.
I don’t have to use the role button because that’s implicit there. I don’t have to use an ARIA leg or anything, I can just use a text note.
So, this is, does anyone here watch MasterChef? Really?
Like, so more people like curry than watch MasterChef, okay.
So, I always judge whether or not there’s enough chili or too much chili in food based on Gregg Wallace’s face, but there’s a subtle difference between the two pictures I’m gonna show you here.
This is happy Gregg, and this is not happy Gregg here.
So, for those of you who can’t see this.
This is Gregg, he’s smiling, but also his eyes are smiling.
And in the second picture he’s sort of smiling, but there’s actually more of a grimace.
So you just have to be careful, so look out for that.
Number six, offer choice.
If you think of kind of the main curry dish, like your Vindaloo or your Madras or whatever it is, that’s the content.
I’m stretching this analogy already quite a lot. that’s kind of like the content, or the experience or the functionality that you’re trying to offer, and then the naan bread or the rice, they’re kind of like the different conduits that you could use in order to deliver that experience or that content.
And either is good, but the thing is that offering choice to your users is really important.
They use the expression half rice/half naan, which kind of means like you like a bit of both, and there’s no judging for that.
If you like a bit of both, then that’s absolutely fine. That’s absolutely fine. Go for it.
The other expression is half rice/half chips, which is more of the sort of takeaway version of it.
Offer choice is actually one of the principles in the Inclusive Design Principles website that Henny Swan and I and Leonie Watson and Ian Pouncey recently published, which give you some very broad principles about how to go about making accessible and inclusive interfaces, and offer choice is one of them.
So an example from a neat space to do with, and I was talking to Claire earlier about this actually in the break, is to do with say visualizations.
Now, the mistake a lot of developers will make, excuse me, I’m just gonna have a bit of water, would be to think everyone loves my fantastic, fancy visualization.
Isn’t it such a shame that people who are blind can’t experience it?
I’ll make a table with the same information, and I’ll provide that nonvisually.
The mistake they made there is not that they, not in the way that they provided information to blind screen reader users, of course not all screen reader users are blind, but the problem is that they’ve hidden it.
Because actually everyone can benefit from having that different data format.
And Claire actually suggested the other example is transcripts.
Transcripts can be useful for people who, all sorts of different people who don’t find it convenient or easy to traverse the information in the video in an audio/visual way.
So, if you’re providing something for one group, don’t exclude it from other groups of people or perceived groups of people.
In fact, you don’t even have to think in terms of groups if you just provide choices, because then it’s just easier for people to make up their own minds, so you don’t have to like, pigeonhole it at all.
Number seven is eat your own dog food.
So does anyone know that software expression, dogfooding, where you kind of walk the walk as you talk the talk.
I don’t literally mean make curries out of dog food, and actually, I don’t know if I’ve still got the slide, yeah, and actually I did do a bit of research before the talk just to check out the reverse of that, and I found this website which gave me a quick answer on whether or not I should feed my dog curry, and it said Answer: Not Recommended.
And with my dog, really probably not.
I have a greyhound and greyhounds have absurdly disgusting gas, and that’s why you give them like dry food.
So giving her curry would be biblically horrifying.
Yeah, so sorry. That was a bit of a tangent.
So, really that whole sort of the whole dogfooding thing is about doing as you say, so that people don’t think, well if you’re not doing it then why should I?
And I’ve tried to take that to the limit with something that I’ve been working on recently.
So this is called Infusion, and it’s a documentation builder, but it’s got a big focus on the output but also the input and the way you can input the information on being inclusive.
So a few examples, this is basic technical stuff like using ARIA Current, so where it visually indicates which design pattern in the pattern library that you’ve built is the one for the page that you’re on, you can use ARIA Current to indicate that nonvisually, and it’s only recently that ARIA Current has actually taken hold and is actually become implemented in a lot of software, but it is quite well supported so you can start using that.
Infusion is based on Hugo, which is a static site generator, really performance static site generator, and in their documentation they use ASCII to describe the file trees, to describe where you should put everything basically, and I really like that, but it was literally ASCII, so it’s completely useless nonvisually to try and pass it.
So I used some CSS to recreate the same thing out of nested lists, so that’s made that a bit more accessible.
And then there’s just some sort of broad inclusive features which are nothing to do with nonvisual semantics or anything.
So if you’re documenting something and you use more than two h2 elements, it will automatically create a table of contents and link everything in that document.
So, it kind of makes it easier for you to write documentation which is easier for people to traverse without having to think about it, I guess.
And I would never dream, I think, of printing out a website.
I very rarely print out pages of websites, but I’m not everyone, and that’s an important part of being an inclusive designer is to accept that.
You might be wrong or other people do things different ways, so I put a lot of effort into making a print version using print styles.
So, you can print it out and you can have it at hand or you could print it to PDF if you want to turn a perfectly good website into a shitty PDF.
The other thing is it’s all in black and white, and the reason for that is so that it doesn’t conflict with the branding of the thing that you are documenting, ’cause it’ll be like visual things that you might want to document in there from the site or the application that you’re documenting, so I’ve made it very neutral, I suppose, so in a way you could say it’s being inclusive of the kind of products that it would be used to document.
But that’s made it also very easy for me to do a switch so that you can go to a dark mode.
And that helps a number of people. I get migraines quite frequently.
So I kind of go partially, sort of go blind in one eye and then have a horrible headache for several hours, which makes it very difficult to work as a web developer or whatever for a few hours at a time.
People with photophobia have a little problem with very bright interfaces and they cover kind of I suppose, clinical issues but then of course it’s that classic inclusive design thing.
Also it’s kind of nicer for people who don’t want to look at bright things when it’s late at night and the lights are down, you know, if they’re reading something in bed or what have you.
So it covers all of that. And, this is something which I’ve come to realise recently is there are certain things, and I believe Paul was talking about it this morning, where it’s like adding features for accessibility, like here’s a little widget which can change the colors around or things like that.
I think that they can be really useful, but they can be really hugely inefficient as well.
I mean, there can be really big features which pull in a lot of code, and because performance is so critical on the web, it’s better that you don’t implement it at all if you can’t do it efficiently, because it all effects people so badly if it’s really clogging up the interface.
So the only reason I did that theme switch is because it turned out it was quite easy to do since in browsers that supports filter invert, you can pretty much just switch things over.
You’re nets are preserved images by kind of doing a double inversion thing there so that they remain the same, and I don’t get spooky sort of negatives all the time.
I wrote an article about that whole thing (https://inclusive-components.design/a-theme-switcher/), and there’s a react implementation of that if you’re interested in using it in react interface, but it tends to work really well with any interface which is predominately dark text on white backgrounds.
It will switch it over pretty well, without you having to tweak it for that particular interface.
Of course the inefficient way of doing it would be to have a whole lot of style sheet which you load and use it to overrun it.
And it also works offline, which is great because that means that I can look at docs on a plane, and I like to work on planes because I’m scared of flying and that gives me something to do, and I’ve got a terrible memory.
So it’s not like I’m gonna actually remember even my own API methods, so that’s handy.
Number eight is embrace diversity.
There are a lot of different types of curry that you can make and those ones are just some southern Asian ones.
There’s obviously African curries, Asian curries, Thai curries, there’s all sorts of things.
And once you get into that world, and you’ve gone past the stage of, no I’ll just have a korma, and try something a bit different, and obviously you know, everyone’s palette’s different and I don’t expect everyone to eat a Vindaloo or a Bangalore or whatever, but it’s nice to try out different things because then you just have a broader experience of stuff.
If your attitude is this, nope, I’m not gonna try any of that, then you kind of doom yourself to just, you know, I’m gonna have my super English mints and boiled vegetables, ’cause we’re the best country in the world and we don’t need any outside influences kind of thing, and you’re just, you know, ruining your own life really, punishing yourself.
Masters of design are students of diversity.
I don’t know how to put this, I was talking about it earlier.
So, I think if you’re an inclusive designer you’re a good designer, basically. If you’re the interaction design, then if you do it inclusively, then you’re just doing it better than people who aren’t.
So the more you study diversity, the more you listen and try to understand the different ways that people go about using and consuming information, and functionality and experiences and all of that stuff, the better you are at making stuff for people, for people per se.
So I think that’s a really important rule. And it’s even so, I’m not a business person.
I don’t understand stats and stuff like that, but apparently diversity really is good for your bottom line, whatever that is.
And if it’s true of ethnic and racial diversity, I think it’d also be extra true if you had an organization which is both diverse in terms of ethnicity, but also in terms of ability and disability as well.
Number nine, I’m getting to the end now.
Number nine is it’s okay to make mistakes.
This is a very important one, especially if you have one of these handy.
This is a takeaway menu, so if you screw up your own curry, then obviously you can order one from somewhere else.
So that’s all good.
Not sure what the equivalent of that is in interface design, but, and I like this one from my colleague Leonie,
“It doesn’t have to be perfect, just a little bit better than yesterday.”
So people here who are, who actually work with inaccessibility already, I think it’s important to encourage people who aren’t familiar with it.
And when they have a go but they kind of get it wrong, not to like berate them or make them feel stupid about it.
To actually say, well you’re on the right track and let me help, sort of thing.
Because people really are scared, in my experience, of getting into it because they want to be perfect at what they do and if you’re not perfect in the field of letting actual people down, and people who are vulnerable down, then they feel as if they’ve really failed in a horrible way and they’d rather not do that at all than just say, well actually, it’s not my field.
Please let someone else do it. It’s always better to just try and it’s never gonna be perfect.
Get inventive is the final one.
So, the idea is you begin with following instructions.
It’s the same with making curries or whatever.
You begin with actually just doing it by rote and just going through all the steps.
But the more times you do that, the more you pick up along the way, like how things actually work and how they interact, and that’s when you develop your palette, which means, well I know that ginger which adds a sweetness will complement tumeric, which adds a bitterness, and so on and so forth.
And it’s exactly the same with interface design.
You have all of these different concepts which you could draw upon, and they’re like different spices and different flavors and different ingredients, and then when you understand all those things in the abstract, you can take them and you can build new things.
You can build inventive and interesting and engaging interfaces, not just the same tab interfaces, and accordings or whatever, because you know the actual underlying concepts, so you can be more of like a chef.
So go forth, and create some new dishes, and solve some new design problems in inclusive ways.
I think that’s all of my slides.
Oh, one last thing.
As I said, I was gonna do a very political talk, but I decided not to because I just got too angry whilst I was writing it.
If anyone bought my book Inclusive Design Patterns, I’ve been giving the royalties away.
To start with, I was giving them away to the ACLU in the States because they were trying to hold the Trump administration accountable, and of course, they’re not really friends of inclusion or diversity or disability in any way which you could imagine.
So I thought that was a good thing to do. And then I decided to send some money to the Democratic Socialists, because they stand up against Fascism.
As we know, Fascists aren’t really good with disability or diversity or anything like that either.
And I wanted to thank you really, anyone who bought the book, because I was able to send some money to the Democratic Socialists and being the fantastic organization that they are, they actually sent me a handwritten letter from the States, to say thank you for the support.
So thank you very much for that, and that’s it.
Thank you very much.