Hello everyone and welcome to accessibility talks. Accessibility talks as a monthly virtual meet up where we come together to discuss topics around all things website accessibility. Each month a speaker will present in-depth accessibility topic to the group, after which will be some time to ask questions and discuss. If you have a question for our speaker today, please post them in the chat window or tag them on Twitter with the hash tag #a11ytalks spelled A 1 1 Y T A L K S.

I'm your host Carie Fisher and this month we are super happy to have Heydon Pickering as our guest speaker. Heydon will be talking today about prioritizing accessibility. For those of you who are veterans of the world of website accessibility, you probably already know a lot about what Heydon has contributed to our field. But for those of you who are new to the field let me take a quick minute to give you some more background on our speaker.

Heydon is essentially one of the grandfathers of UX accessibility design and development. He's written uncoated a ton of useful things including his "Inclusive Design Patterns" book. I highly recommend and if you don't like killing trees there's an e-book version. And he has a blog series called inclusive components and his latest GitHub repo is called the inclusive design checklist. And if that wasn't enough he writes and edits for one of the most popular web design blogs in the world Smashing Magazine and works with The Paciello Group focusing on accessible user experience design. So welcome Heydon! We're very happy for you to be here.

All right well thank you for the great intro. It was lovely. Let's straight into it. So this is a new talk which I've been working on which I'm going to be giving hopefully a few times in 2018. But you're all guinea pigs, and so it's quite raw as the WuTang would say, at the moment. So I'm just going to jump into it now. 

It starts by me asking something that I didn't that I never dreamed I'd actually ask anyone at it let alone several people at the same time also. Well not ask, but say and that is I want to talk to you about Taylor Swift and specifically Taylor Swift dot com. I found out about this a while ago. A few weeks ago guy called Alex Hern who works for The Guardian and writes about tech there, shared this on Twitter. He discovered that Taylor Swift dot com was going into, shall we say a really interesting design phase, and I'll show you what I mean. This is what it looked like a few months ago I guess. And I know what you are probably thinking, and you are probably thinking "There's a slide missing" or my I've stopped sharing my slide or something like that but that's not case. This is actually what Taylor Swift dot com looked like for a few hours or weeks. 

It was just empty. It was just a void. There was nothing there whatsoever. It was just this black page and no interface at all. My first thought when I heard about this from from Alex was that it was kind of derivative because Metallica already done the all black thing although they kind of failed to do the all black thing because they might show their own logo in one of those curly Confederate racist snake things in the corner there. And of course they stole the idea from Spinal Tap. Who did the who did the entirely literally black album. And as I put it there was none more black than that. So this is sort of tradition of doing entirely black things in music I guess and Tyler is part of that lineage. 

Around about the same time I discovered one of these sort of games these political Matrixx things where you plot authoritarian against libertarian and left against right and this is this is sort of the original series version and then people sort of applied it to different kinds of popular cultural things and someone did one which was about music. And so for instance in the top right corner authoritarian right would be I guess someone like nazi punk band like Screwdriver or some awful shit like that. And then in the bottom left libertarian left would be primitivist 9 hour long Bongo jams by bison hippies or something like that. The interesting thing for me was it in the center top area. They'd simply written ideally silence but in reality Taylor Swift which I wrote was great because yeah I prefer silence to Taylor Swift personally not being a huge fan of more than Napalm Death fan than a Taylor Swift fan. 

But then that got me thinking that maybe the people who were responsible for Taylor Swift dot com were actually kind of doing their audience a favor and saying look we can prove to you that there is actually a better alternative to the noise and the bleatings of Taylor Swift's music and that is nothingness its emptiness, purgatory, whatever you want to call it. But I suspect that wasn't their main agenda or that wasn't really their intention because if that was just their intention just sending the user, sending the browser the client a black page. If that was all they were doing then it wouldn't be 300 kilobytes in size. Or at least I thought it was 300 kilobytes. I actually discovered that I had Privacy Badger running which was blocking loads of stuff and actually Taylor Swift's web page was 800 kilobytes which is a lot considering it's just literally a black page.

To put it into perspective. The computer game Populous in which you literally play a God who decides the fates of several autonomous sentient beings so quite a complex concept is only 512 kilobytes so fits comfortably on one floppy disk and the game Frontier: Elite II which is game when you fly around an infinite universe of planets and stars and submerged in a three dimensional phantasmagoria that is just seven hundred and twenty kilowatts. So you know you get a lot more bang for your buck for less code. And Taylor Swift's site on the other hand is just nothingness. Of course if the universe was devoid of matter entirely then playing Frontier: Elite II would be a little bit like this you would just see black and that would be an easy easy game to code. 

But that's not really the point. One of the funniest things about it that Alex discovered was that the part of the code that actually made the screen black was some embedded javascript which shifted a document body style with the background color of hash 0 0 0 and some premature optimization here which is that it's encapsulated in it immediately invoked function expression which isn't needed because there's no way you're actually going to read a foreign document as a variable or would be very foolish to. 

And since it's the only thing it actually does that affects the user experience. Then why would you go there? When you think about it, if javascript isn't running then the user literally gets the opposite experience which is a white screen rather than a black screen. Literally the other end of the spectrum. So there's a lesson there to do with not relying on javascript to doing stuff but I digress. 

The rest of the 800 kilobytes it was all just ad trackers. Just ad tracker's all the way down. And this kind of made me sad and it kind of made me think about the state we're in in terms of the global economy. I suppose in that we're at this point where we're asking consumers to go somewhere to log on go to an address to experience literally nothing. So they don't get anything themselves and in return they have their identity stripped. And so it makes money out of their presence. So it just seems really sort of unfair and uneven and that's what got me talking got me thinking about priorities and priorities in terms of the way that we design things. 

So is one rule and it's kind of a universal rule when it comes to design and development. We can't do everything that we want to do because we have certain constraints. We have budgets so we don't have infinite money. The money will run out at some point. So that's going to gonna hold us back. We have time frames so we don't have infinite amount of time to do things of course when we are designing stuff for ourselves like we're doing that redesign for our blog which goes on forever and ever then it kind of is an infinite timeframe but we never finish, so there's a problem there anyway. And we have limited resources in general staffing and technology and endorsements and of course we have friends and family I mean if we're lucky our friends and family and we have to do things like you know sit next to them and watch them whilst they eat and and make conversation. So we have to do you know we have other responsibilities in our lives aside from coding so we can only do so much. 

But the problem is the things that we seem to have chosen to do. I don't think are the important things. We've got our priorities wrong. We've got them the wrong way around. There are signs that you may be working in an organizational you may be working in a way wherein your priorities are out of whack. And I'm going to talk about some of those signs a sort of litmus tests. 

The first one is if you spend an inordinate amount of time discussing the relative merits between these two shades of red and depending on the quality of your monitor of course you won't be able to see whether there is a difference there at all. So much resources and time is spent on having those kinds of things and treating those kinds of discussions as if they're important and you get bonus points of course if you try and justify what is essentially just piffling around with unimportant design decisions like that with some sort of psychology so you would say something like well the muted red I believe we should go for because it creates more trust in the brand or maybe the more vibrant red because it's more energetic and it fills the need to use it with a urgency or something like that or complete bullshit. 

And from a more sort of technical standpoint we say stuff like ultimately implementing the application and psychogenic is a net benefit to the user because it's intrinsically reactive and functional nature makes my experience as a developer more economic investment and productivity higher. If we're honest with ourselves we really just want to play with the new toys that we were quite happy to completely reimplement something which was in say angular into cycle JS without there being any change discernible change for the user. 

We but then we post rationalize it and say well actually no. I think in one way or another we get really tenuous. It's actually is that a real important reason for doing this and it really helps the user. We're looking out the user. Of course with things like this where we present information in bad ways using the wrong methods and and reduce the amount of information because we're worried about clutter because we care more about how things look and how tidy they are than how good they are at actually explaining what's going on. So this really will be better you have permanent visible labels and then you use placeholder for what it's supposed to be used for. But that's not what it looked like when the designer the graphic designer who isn't an interface designer created it and inscribed into a static scam. So you treat that as gospel and you do that instead because your priorities are wrong. 

And of course we enshrine even the simplest of web pages and apps in these monolithic architectures with bloat and much of that bloat affects the how you are how you're able to consume that content on the on the client so this performance problem but also we just treat everything generally as if it's not a something that's ephemeral most of the things we do are ephemeral. Life is short and these projects we work on disappear. We spend far too much time worrying about trying to make these things immortal. When actually we should just make the musical for the time being so I guess what I'm saying is that we spend too much time paying lip service to putting users first and when actually we're serving ourselves and then we're trying to justify it we're using users first as a and trying to work that in after the fact, disingenuously. 

Performance is one example. So performance is a really important thing of course for performance and accessibility are both parts of inclusive design both are really important parts of inclusive design. So I'm big on performance. Performance is great. But we go about it in two different ways. One way is just busy work as far as I'm concerned. So it's just what we're doing a performance then we're making a difference in one way or another. We are we are affecting things. And then there's real world which is we're actually making a big big impact with making real proper decisions and actually having to compromise in other areas in order to make it more performant. CSS selector performance is is kind of a busy work one as far as I'm concerned so much time and energy has been put into thinking about CSS selector performance and studying it and worrying about it. 

Ben Friend did a study not long ago which more or less just concluded that in modern browsers if there was ever a problem even in older browsers that now it's really not something that you would you would you would care to worry about. There are bigger fish to fry bigger priorities to have. And yet we still continue to study it and worry about it and write blogs about it. Here's how you measure selector performance. So first what you have to do is get about 6 million DOM nodes and put them all on one page. Then you heat up those DOM nodes to about 300 degrees C. Then you apply the worst CSS selectors imaginable like stuff that no one has written since 2004 like really huge chain selectors and put this all into an older browser because they're the only ones where you be able to measure this stuff at all really and then you file all of that shit around the large hadron collider and then if you're lucky you'll get a small sign that there might be something measurable but so you might be able to see a slight difference between the amount of time that it takes to pass say a qualified selector like a.class or a a child selector thing. 

But the point is measurable doesn't mean something matters just because something is measurable it doesn't mean that it matters. And we seem to get that wrong. A lot of the time I think which is a shame because it means that what that tells me is that we're no good at prioritizing essentially and whenever I talk about this kind of thing people kick back and I say well if you are making it more performant even if you're making a tiny bit more performant on the interface then that's good right because because you're not making less performant and you're not doing nothing but the point is that that's not a good argument. 

And the reason is because you have budgets you don't have all of the money to spend on doing this kind of research in this kind of performance Genie and you have time frames and you have limited resources and your family and friends probably want to spend some time with you if they haven't already abandoned you because you spent too much time doing piffling coding experiments. So you have to prioritize. You have to choose where doing performance geeing will actually really make a difference. 

So for instance a low priority would be filling well engineery and having data and charts to stick on your blog. Where as a high priority. Actually making things more performant for the user putting them as as a priority. So you have to ask big questions and difficult questions that in order to do this you have to make compromises.  jQuery for instance nothing wrong with jQuery not dissing jQuery but for a blog where very little javascript if any is needed. You shouldn't need to depend on a sort of between 50 and 80 k library in order to do a couple of very basic interactions you should be able to just do that with vanilla JS and get rid of that dependency because if it's more ergonomic to jQuery then maybe you choose that. But that's serving you. Not to user.

And of course images. It's not really kind of scientific and is kind of engineery feeling or anything but just using less images I mean compressing them and lazy loading them is good but just just the over-reliance on images especially raster images is a big problem and it actually causes a genuine performance and cost as well as of course users on mobile who are downloading large images don't actually have to pay for them over the network. 

Question Why do they call it a hero image? And the answer is because the user says Thanks for the pointless 500 kilowatt image. You're a fucking hero. So getting rid of hero images actually would make a difference but were reticent to do that because then we're actually seeing a visual difference in the way that something designed. We have to get used to and more comfortable with compromising over things like that. And it's an easy compromise to make really because actually all the hero images usually is a picture of a desk which is the desk in front of you already. So I don't need to be reminded that I'm looking at a desk with a computer at it or so what's the fucking point in that. So get rid of hero images. Some images of course actually add to the user experience and I help usability and internationalization sometimes in that sense in terms of icons because icons don't belong to any particular language. They cross barriers in that sense and making little icons which are just generic shapes if you use vectors you can make them really really small so they don't have very very little impact on performance. 

I made a set of these on Twitter the other day just to sort of prove that it's possible and things like this as a menu icon it's a tiny little bit of markup essentially. Same with a checkmark. Same with an arrow. Which is really super tiny. And of course you'd need to add things to this to make them accessible. So for instance with the SVG can have rolled text and then I relabel of rights if in the context right was the correct label. There are different ways of doing it. You could have a title element and then you could refer to that from the parent SVG and label it that way. Or you could actually add a text element inside the SVG and maybe you use a class to visually hide it didn't want right to appear. 

So these are all ways of doing and they're not difficult ways of doing things. But you won't know how to do those things unless you learn it. I mean it's certainly not more difficult to do accessibility than it is to do to learn JavaScript and know the intricacies of closures and tuples and things like that. It's probably a lot easier. But the reason that people find it hard and don't want to get into it so much is because they haven't prioritized it because because it's it's not something they already know.

Pixel perfection this expression winds me up because people still use it like doing graphic design not web design like we're like we're not making things for a huge diversity of different devices and things like that. Let me tell you a story about a project I did a little while ago. Well it was just months ago now. And what it was we were were employed to make an app to help people in the UK. Do well in interviews where they're assessed to get one of these two benefits the EASA or PIP benefits. Basically people who are who are disabled or otherwise unable to work they should be entitled to certain benefits. I'm happy to pay taxes to support those people because it's not their fault that they can't work right. So you have these kinds of benefits. But the interview process is kind of kind of tricky and there's not really very much information on how to go about it. And we don't want those people to be badly assessed and to walk away without benefits that they really should be entitled to. 

So we created a little app which helped them go through the process of the interview and it was like a quiz and it sort of asked the typical sort of questions that might be asked. So naturally when we're building an app like this we did some user testing and we were careful to make sure that the if there were any anyone who was going to come to the testing session was in a wheelchair then of course we'd have to do the session downstairs. But no one no one was due to turn up who was in a wheelchair. So we booked the room because it was easier which was upstairs. But what we hadn't bargained was that actually some people have invisible disabilities whereby using stairs can be really really hard anyway. So we had one guy turn up and it took him five minutes to get up on one flight of stairs to get up to the user testing room. So that was kind of unexpected. 

And then when he got to the top it took him another 10 minutes to catch his breath because this was a really really exhausting thing for him to do to look at him you wouldn't realise. So I learn something through that process. The first thing I learnt was that while invisible disability really is a thing and I should have known that because I've suffered from anxiety and depression and those things can be debilitating and I can very much stop you from being able to do the things you like to do. So we made a bit of a mistake there. But I learned other things about this guy. He not only had very limited energy but it actually spent most of the last ten years of his life off the grid so he didn't have a computer. He wasn't really in contact with anyone at least not in any sort of mediated or digital way. And the handset he brought with him and it's important that we asked people to bring their own their own devices because that's kind of like a user testing or usability testing rule I guess don't force people to use a machine that they're unfamiliar with you're testing the app. No it's not their ability to use a MacBook or whatever. But anyway he had only that week got himself a mobile phone and it turned out it never had one before and it certainly never had a smartphone before.

So bearing all of that in mind. Bearing in mind that he was very limited in energy and really not familiar with or very interested in technology. How many fucks do you think this person would have given about some of these features for example subtle drop shadows around the buttons. You know it's very subtle it's a certain color as a little bit of a warm hue to it and no fucks given about the golden ratio based typographic. He may or may not know about the golden ratio principle and the mathematics behind it. He certainly didn't need to have an interface which had typography based around the Golden Ratio in order to achieve what he wanted to achieve crudely application that we were building and lifelike animations in functions bouncy cubic bezier based animation functions which make it look as if it's really a bouncing ball or button or whatever it is that's being animated just like Disney. 

No it doesn't give a fuck about any of that stuff of course he doesn't because real people aren't looking to be delighted or engaged with the interface itself. They're not fetishists like us they're not people are actually fetishized interfaces because that's what we work on. They're not looking for immersion either. They don't what they don't want to be stuck inside this experience for a long time. They want to get over with because they've got other things to get on with because they have limited resources time frames and of course they have if they're lucky enough friends and family to do things with as well. So it's important and it should be a priority to make things accessible and what that really means is to make it broadly and attainable experience for as many people as possible. And of course it should be a priority to make it usable as in whoever those people are and how if they access it it makes sense and they can actually get through it you know and it's clear. Everything else really is frippery. Always think about this in terms of if you take it to an extreme in the other direction always think about the idea that maybe if I'm trying to buy train tickets that instead of just being an easy experience I can just get through and get done. They go the other way and I try and turn it into the submerse thing whether it's this cut scenes and animations and lifelike mathematical plumes of steam smoke or whatever. I'm obviously not interested and I don't even like traveling by train. I mean trains are just like compressed tubes of ignorant people. So I don't I don't want to do that at all and certainly don't want to go through an immersive experience in terms of actually confirming that I'm going to have to do that. That journey in the future incidentally the guy he came to that user testing session bravely to help us test this app was using Windows Phone. And funnily enough I had never actually tested anything on a Windows phone because I was surrounded by people who had iPhone and Android and they were readily available. 

And I guess part of me also just the assumes that that's what most people have. Nobody has a Windows phone that would be silly. But this guy doesn't give a shit whether it's a Windows phone or an Android phone or whatever. He's just walked into a shop and he's picked up whatever's cheapest and whatever is just sort of visually pleasing to him at the time. It wasn't visually perfect the app on the windows phone it didn't look I mean it couldn't look how I imagine because I never imagined anyone using on a Windows phone. But it did look OK and it was usable. And he was able to get through the task. And the reason was I hadn't done adaptive design I hadn't actually tailored the design to those specific Apple devices that most people worry about. I just made it responsive argues content breakpoints points instead of device breakpoints. 

So I knew that it was going to be kind of malleable I was going to be more inclusive of other interfaces. Now to be really clear I'm not suggesting that you should go out of your way to make stuff which is a bit off kilter and a bit ugly but my point is when you prioritize you have to compromise you have to weigh things up you have to decide what's important and the important thing in the web is to make sure that most people get a decent experience that's more important than a few people getting an excellent experience. So you have to weigh that up and you have to make those kinds of compromises. There was a guy on Twitter recently who is doing this thing where he was sort of sharing little sort of nuanced interface refinements. 

So for instance he was in this thing way saying well if you've got like text on a kind of a lightish backgrounds then you can lift that by by giving it a subtle dropshot I like this. And I was doing that dickish thing that people do of quotes tweeting and saying well this is you know that's all very nice for you. But actually people who have limited sight wouldn't be able to discern that in any way and you'd still have a contrast accessibility issue. So you're solving the wrong problem or you know even solving a problem and it's you know this this would be better. It would you know you just change the background color. So it's dark right. So yeah I'm a bit of an asshole because I was sort of picking on these things and someone pointed out that it wasn't kind of me but there's a reason why I get pissed off with stuff like that because it does make a difference for a few people. 

But we spend too much time worrying about those little differences when we've we've not solved the main problems. The main like the actual accessibility of it so I guess the conclusion to that is just that basically your priorities betray your privileges and your prejudices. So what you prioritize says a lot about you and about what you've experienced and about about the kind of problems that you've encountered. Because if you think that you've got the space and you've got the time to worry about these tiny little refinements then you've probably not had a life of crisis. I suppose you lead a kind of a sheltered existence and you've not met people who've not otherwise led a sheltered existence either. So I started building this checklist recently because I forget that. Not by anyone's fault really just for a lack of experience. We tend to fall back on on creating stuff for ourselves. And I wanted to just create this grab bag of ideas and principles based around how you can just quickly begin to make interfaces alienate fewer people. So the Inclusive Web Design Checklist is available on GitHub and you can just come up with ideas things which affect you or just stuff that you think of them that you know is a problem and you don't see it in the list. And there was some discussion over where where we would actually draw the line in terms of maybe we should categorize different things in different ways but no one could agree on that. Basically the point is that all of this stuff should be should be priorities because it's all to do with making things work and be more understandable to more people. 

Just a note on vanity and specifically to do with code vanity. So here's a bit of code. This just defines a tab list with tabs in it and it's so for creating a tab interface with ARIA. I suppose now I remember a while ago I was talking to a JS engineer who I worked with and I had added the semantics to make it an accessible and accessible tab list and his response was I don't get it that's surely that's bad practice to do that. 

I said I didn't understand what he meant. And he said well the case just so much uglier now is now it's just more difficult to read. It's it's more messier. I of see what it means but I guess because he was used to writing code which which ran on a server or or it didn't actually directly give anything to the user. Then he was in this mode of thinking the readability was more important than the semantics. And of course the semantics are really important. HTML is the interface so adding those that semantics even though it may bloats things can sometimes be important. Of course you don't always need to use ARIA. And there's a question mark over whether tab interfaces are very useful or understood by many people. But the point is you should be adding code that makes a difference to the user. 

This will be redundant code because you have a roll of tab lists and they have a class of tab lists just because you've decided you want to use classes in your CSS means you are bloating things because you're you're adding stuff that doesn't need to be there you can style stuff based on attributes selectors for the different roles and things. So you don't need to do that. But that's a kind of a minor point. The point is you should add stuff where it's needed and make it a priority. So in terms of markup a low priority would be doing mark-up that's neat and tidy a high priority will be mockup that successful right. Low priority mockup that's readable to developers. High priority mockup thats readable by assistive technologies low priority managing CSS specificity high priority managing user experiences. So this is a vanity thing about CSS specificity because it makes us feel like we can't write CSS when we kind of get in a muddle over CSS specificity and the reason that we get into that muddle is not because CSS is broken as Sergio wrote. 

I disagree with that is because we make interfaces which are too complex in the first place with far too much heterogeneity but far too many different bits and pieces and feature creep. Thats why CSS becomes a problem if you make simple interfaces then the CSS you write will necessarily be terser. So he kind of did this weird cell phone in this article where he said how many importants do you have in your project. You know how many importants have you had to rely on to trump specificity. And he shared the fact they had 162 in his code. Now that's sort of laughable as another coder. 

You just think well that just means you can't write CSS very well are you. I mean there are 34 fucking CSS files there in the first place. I mean I don't remember the last time I did a project with more than one CSS file. In any case the importance being there does not directly affect the user and finding out ways to get around that. Should therefore not be a priority. It's vanity. You don't want that important there because you're worried about what the next developer is going to think. Now there is it is a sign that you've mismanaged your CSS and maybe it's less maintainable or whatever. But as I said the main issue there is because the interface itself is far too complex. We have tried to get around the CSS specificity problem and inheritance problem if it and if you can call those problems we've all sorts of things we did object oriented CSS a few years ago when it became BEM which is kind of a really hardcore version of that and atomic CSS which is just like literally every possible thing you could write and CSS defined in a class name and then CSS in JS which is where you kind of tie the CSS to the component the writing which works for some people. 

Nothing wrong with any of these techniques or whatever. My concern is that we spend so much time and energy worrying about this thing when we could have been working at the actual user experience if we really wanted to solve the problem of CSS specificity. We would simply do this we would turn all of our content into one giant image do a Mac and then define areas that's what I used to do back in 2002 when I was first making websites a big image because it meant I could use the font so when it's used because this is before web fonts then just defined little areas to draw around for the links completely and utterly inaccessible and hugely badly performing and all sorts of other issues because it's a giant fucking image but it does solve the CSS specificity (I can't fucking say that word) the CSS specificity problem. 

So if that's your one and only priority fucking go ahead and do that but of course it's not or it shouldn't be. So I'm going to wrap up the good news is most of what you do isn't necessary which is kind of depressing to think back on all of the work maybe that we've collectively done and think that well actually a lot of things we worried about the other things we were trying to do they just you know there was really no point it didn't really make any difference to users they either didn't notice or didn't care. 

But the good thing about it means that as you move forward and you become better at prioritizing things there's less to do and more time to do stuff with you know your family or whatever. Because life as a developer is short. You know once you've once you've done a few dips that's it and it's game over. But the good news is there is plenty of time to do the stuff that matters. If you cut out the stuff which doesn't matter the stuff which you de-prioritize and that can include you know having a bit of fun. 

So for instance the Taylor Swift web site. Now the problem with that was that it didn't do anything for the user whatsoever. It was just a blank you know void empty space and yet it was 800 kilobytes if you really prioritize the user that would have to be a blank black screen and it would only be I don't know three kilobytes or something similar to that just for the little bit of markup and you wouldn't use javascript obviously to do the to do the color anyway. And as I experimented with this idea and I thought well if I wasn't doing the ad tracking business which I shouldn't be doing really then I could actually get away with doing all sorts of stuff on the page. I mean this is just one sort of speculative redesign that I came up with. I feel like it's on brand it's all singing or dancing it's got you know lots of great imagery and stuff like that. 

It's it's it's very Taylor Swift and that's 100k so that's a fraction of the 800. OK well there's something actually fucking there that is actually something to look at so. So yeah eat that up. This is one of the best designs I think I've ever done And that's it actually that concludes me ranting ranting on about stuff.

Oh my gosh...that is perfect and awesome and horrible all at the same time. 

Certainly horrible, yeah.

Thank you so much for joining and giving us this accessibility priority talk. 

Questions: first one is from @imbedges. You describe a scenario where developers and designers justify the poor decisions they make in terms of avoiding clutter and or being productive. What about scenarios in which designers and developers are advocates of exactly what you've been speaking about. But it's the business that's the blocker. What do you what do you do. 

Yes. So that's really good question. So I think most of the time. See whenever I do these talks I'm sort of speaking to developers as much as I'm a developer. So by doing that kind of work or I'm a designery developer. Well actually I didn't even think the designers and developers should be seen as separate people as often as they are. But in any case yeah I mean it's usually the business is the problem. It's usually you know it's it's it's sort of organizational dysfunction that is the reason that we create these really complex things. And and and you know we get a feature creep in it you get a sort of top down decision making and I think in any organization which is genuinely committed to making their interface more inclusive more user sends it. And I think you just you in terms of specifically the classic problem ultimately you end up with something which is less cluttered just ultimately because you discover that users really don't want very much from you and they want what you know what you do to be super super easy and simple as easy I guess. But yeah I think I mean I do a lot of auditing and quite a lot of the time when I when I'm looking at the code I'm not seeing that like bad developers code like I know it's easy to sort of think oh well they screwed this up. They don't know anything about accessibility or whatever. But actually most of the time I think they were probably really rushed to change something which they weren't really happy with changing. But there was a lot of pressure and there was a deadline and so you know it was a perfectly good radio group which they wanted to then act buttons to. And that kind of turned into this mishmash of a component. And it's no longer makes any sense to anyone. I've seen that so much so I think a lot of the time it's kind of be organized as the organization and the way that the organization functions kind of. Yes screws it up. And despite you know the developers of that designers as being very talented. But I think that in terms of accessibility and inclusive sort of broad and inclusive design the more design that actually goes into the development the better and the more that that becomes part of the culture the the the more robust in lots of different ways the output is. Yeah. So I did. I hope that answers your question.

Yeah I mean that's something that you constantly get as somebody on high that read a great blog or article about something and said oh that's what we need to do yeah let it go. 

Yeah yeah. No that's yet that that happens a lot. It's kind of I think a lot of the time people get into their heads that their that they're Facebook or they're Google so what works for them should and should work for those people as well. And so it's just about this is THE thing to do. And I think that's another thing which is really powerful when you get it and you really commit to just choosing the things which are right for the job. Now like I was saying you know if you're doing a blog then it's all about reading experience. And it's all about performance because you can afford for it to be performed because it should just be static content or it can just be static content just doing things in a way that suits what you're trying to make. I guess it's an important thing. Yes so. So that whole thing of just like all the cool kids are doing this so we should do this. You know you end up in a situation where you're doing a client rendered react based blog which is just not the way to do it's not compatible I guess.

What would be the one takeaway that you'd want somebody to get out of the talk today? How would they take what you presented and like apply it. 

I think just just to think about priorities and just to the ones that like the one lesson I think I feel most passionate about passionate about as I say it's as I'm explaining in it or is this idea of just because something can be measured doesn't mean it's important. So you really have to actually cut things you can't and you can't afford to say well this is actually doing good. You have to say well if it's not doing enough good then we don't do it. We prioritize something else and we and we we focus on another area. So I think that's the main thing is just. And then when you actually think about what we're doing which is creating interfaces you're actually creating things which real people have to use. Then you have to conclude that actually the inclusive element of it or the accessibility of it is paramount is a really important thing. It's not just catering to to to very few outliers. That's the sort of one of those misconceptions of accessibility is like well it's a lot of cost to to do all of that work for just a few blind people or whatever group it is that you're obsessing over when actually we are all divided into different groups where we have different different needs essentially and that's why that's why it's sort of an inclusive design rather than accessibility because it's more about like if you add up all of the different groups which you can one way or another sort of arbitrarily defined as a group of people but face a a certain problem then you it's actually most people almost all people have those kinds of challenges in one way or another. So you're just making things for people. Yeah. So just cutting out cutting out the stuff which doesn't make much difference and it is sort of like an 80 20 rule thing you know like 20 percent of the effort 80 percent of the outcome that kind of thing and then you save time and then you can move on to another project right. And do that one really quite well but not try and obsess over it and don't make it perfect. 

Yeah I think that ties into a question that Adam Silver asked earlier too. That's great. We all agree with that. But how do you actually convince people to prioritize those things over their own non problem priorities maybe like beyond maybe the business argument. 

Yeah. So the the I guess in terms of inclusive design the business argument I mean just to cover that first would be as I said you know if you add up all the different disabilities all the different challenges which people find then that is sort of everyone. So the idea is to make it as flexible as possible I suppose. I used an expression in the book which is about the less the fewer decisions you make for the user then the more they can make for themselves. You know the more they can adjust the interface the more that they can they can have things to their liking but actually trying to convince people that their problems are that the problems that are coming up with all the things that they want to change in the interface that there is little kind of pointless pixel perfect thing iterations are not important and trying like defeat that culture and you have to be good at argumentation. You have to get good at kind of pointing out fallacious argumentation in the way that people try and justify had to do things I actually did it an article of my blog a while ago called developer fallacies which is about about kind of spotting and seeing through that kind of false justifications people use for things like the two sides of the same coin you have the one which is one which I call the Gospel fallacy which is we've always done it this way. So so it must be good sort of thing which is obviously it doesn't follow suit is a fallacy. And the other way round which is as we were just we were just chatting about a minute ago. The thing where you just adopted a new just because it's new. The fallacy that because it's a new thing it must be better than the old thing. So getting good at actually standing up saying well actually you know I don't think you're justifying this one enough for us to go down this path. And that does mean confrontation ends. And and I dunno getting into getting into awkward situations to some extent but unfortunately that that is part of it's like any other job it's really not about the code. It's more about it's more about human interaction sadly. 

That makes sense. Thank you. And I've posted a link in the chat to that article that you just mentioned, the fallacies one.

Oh cool.

Just wrapping up are there any other last minute questions anybody has? Otherwise we'll hopefully see you all in January in the new year we'll have a new speaker and a new topic. But for now. I'm so excited. I think a lot of people here and in the room you know look up to you as somebody who you know we can learn from and grow and expand and go off from.

It's all about learning from each other. You know we don't...I mean I think Steve Fulton is really good at this. He knows he's like an oracle you know. He's the person I always go to if I did know something about some specific thing about ARIA or whatever but then you know he doesn't know everything no one does. And so it's just important to be brave enough to admit when you don't know and to be willing to say you know shit, I don't know this. And so ask Yeah. 

Awesome thank you so much. Thank you everyone.

Cheers everyone. Cheers Carie. Thank you very much. Cheers, bye!