Tag: “Inclusive


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
heydon-pickering-author-image-opt

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?

Drew McLellan

Jina Anne In this episode of the Smashing Podcast, Drew McLellan talks to Heydon Pickering about his new book, Inclusive Components. Heydon is known for his work and writing on Accessibility, so what is Inclusive Design, and where do components come into play? Heydon eplains all this and more in this episode. You can listen below, or subscribe wherever you get your podcasts.

Show Notes

Transcript

Drew McLellan: He’s a freelance web accessibility consultant, interface designer and writer. His work focuses on accessible user experience design, as well as writing and editing for Smashing Magazine. He’s the author of the acclaimed book about accessible web application design, Apps For All, and has just released a new book, Inclusive Components, all about how to build accessible web interfaces, again, with Smashing Magazine. So he’s clearly an expert on the subject of accessible design, but did you know he was the first male human to jump the Sydney Harbor Bridge in a speedboat? My Smashing friends, please welcome Heydon Pickering. Hi, Heydon. How are you?

Heydon Pickering: I’m smashing. I’m on brand.

Drew: I wanted to talk to you today about the subject of your new book, Inclusive Components.

Heydon: Yes.

Drew: Obviously just a two word title, but I feel like each of those words does a lot of heavy lifting. Starting at the end, as is obviously logical to do, components, is this about sort of component-based design? What is that?

Heydon: Yeah, so I suppose it’s been a while now since people, front end developers, designers and everyone who collaborates on making interfaces, started to think about things in terms of components and dividing things up into digestible and reusable morsels. And I suppose if you’re not familiar with that way of working for whatever reason, it really is a bit like electronic components. My father is an electronic engineer. He works in the sort of analog world of circuit boards and solder and all that kind of thing.

Heydon: In fact, he’s made some components, very small components, which have been used to regulate the current going into electromagnets at CERN. And he had a lot of faith in me as a kid, because he got me to actually solder some of the bits for them. I think that batch has now been retired, so don’t worry about my poor soldering, my poor teenage soldering, being involved in CERN anymore. But yeah, I think it is analogous to … Oh, there’s too many analogs in there.

Heydon: It’s analogous to analog circuit boards in that the idea is you have single responsibilities for individual parts or components and, together, they make the circuit and, together, they augment the current in the case of a circuit or the, I guess, the interface or the outcome in whatever way, in a design system or in an interface as manifested through a design system. And so, Inclusive Components because I wanted to address the fact that, while, I mean, accessibility does tend to get left behind generally when we advance what we’re doing in different arenas, and I wanted to bring accessibility and, in the broader sense, inclusive design to bear on this kind of new way of thinking and making things using components or modules or whatever you want to call them.

Heydon: So the idea was to both bring accessibility to design systems, but by the same token, think systemically when it comes to trying to address accessibility. Think about solving kind of one problem in one place in terms of accessibility and making sure that simply propagates around the pattern [inaudible 00:03:16] the design system at large.

Drew: In a sort of a practical sense, what does it actually look like to work in a component based way? What might an example of a component be?

Heydon: So, there’s different ways of conceiving and coding components. I tend to get straight into the sort of nitty gritty of it, past the conceptual stuff and think about how I might organize the code. I’ve actually come to focus a lot on custom elements, or if not custom elements, then normal elements but with kind of JavaScript behavior attached to them in a kind of isolated, componentized way. I really like the idea of components which are interoperable. And by that, I mean that they can be used across different frameworks and systems and approaches and technical stacks. And custom elements are nice in that because they’re native. You can define them in one place and then they could be used, say, in a react application or they could be used in a view application or they could be used in an angular application, or whatever sort of larger state management technology you’re using.

Heydon: So for me, usually a component will probably be a custom element. I’ve worked on a project recently which isn’t so much focused on accessibility, although I’ve tried to make it as accessible as possible, called Every Layout, and it’s all about kind of trying to isolate very specific kind of algorithms for CSS layout. And they’re defined as custom elements and kind of they sort of deploy themselves and run their own CSS and work as kind of like primitives within the larger system.

Drew: I mean, in actual practical terms, we’re talking a component might be something like a form field?

Heydon: Yeah, so it could be something as simple as an input. Say, like a text input or it could be something complex like a tab interface. And so, the idea with Inclusive Components was to take the concept of one component with its, hopefully, single purpose, like a text input, and then think about all of the different things that could trip up different kinds of people and try and avoid them. Not avoid the people, avoid the problems. It’s not so much about including people, it’s about trying not to arbitrarily exclude people.

Heydon: That seems to be the easiest way of approaching an inclusive design process for me, is to kind of identify the potential exclusionary elements of something and try and step around them. So with a text input, with a label, you’ve got a number of different things there that you might want to worry about. So, you’d have whether or not it’s actually labeled correctly for a start. So are you using a label element and is that label element pointing to the text field using a for attribute so that the two things are programmatically associated so that when a screen reader user focuses the input, they actually hear the label being announced? So that’s one thing to get right.

Heydon: Then, on a sort of more visual level, making sure that the label is clearly associated with that field and not a different fields, and that’s a question of white space and that kind of stuff. Also, making sure that the label is not, you’re not doing something fancy like putting the label underneath their form input because then when you, for instance, when a virtual keyboard comes up, that might become obscured. So, it’s taking into consideration those sorts of things.

Heydon: Making sure that the input itself has a focus style, so when you focus it with a keyboard, whether you’re a habitual keyboard user who uses keyboards to navigate or otherwise, making sure that it’s clear from the focus style that that’s the input that you’re focused on. Making sure that, I mean, things like autocomplete, worrying about that, whether autocomplete is appropriate and helpful in the context or whether it’s not. And a lot of these things address disability directly, but a lot of them are sort of broader in terms of usability and just making things as understandable as possible.

Heydon: Quite often, there’s a very sort of fine line or perhaps a blurred line between what addresses sort of usability for everyone and what addresses disability. And then, to make it even more kind of difficult to pin down, cognitive disabilities. So if something is not very usable for someone who does not have cognitive disabilities, then it’s going to be even more difficult to work out and be able to use for someone who does have those kinds of challenges.

Heydon: So it’s just trying to think about all of those things in one place. And really, the book is just my, it’s my thought process as I’m approaching each of those. So I did it as a blog to begin with. And each pattern or each component is a blog post and the text is just me going, “So, let’s now address this potential issue. How do we go about that? Okay, we’ve checked that one off. I think we’re okay there.” And, by no means am I trying to say that these are perfect and that I’ve thought of everything, because that’s not possible.

Drew: So does taking a component based approach to how you work on individual parts of an interface, I guess, it allows you to go really deep on that particular item and make sure that you’ve really heavily optimized it in the best way you can so that it’s accessible to everyone. Is there a danger in doing that and doing that on lots of different components and then putting them all together on a page? Is there a danger that you can create issues that you weren’t aware of because you’re testing them individually and not together?

Heydon: That’s a really good point, and I was going to bring that up earlier actually. I’m glad you said that. So, in lots of ways, I think we have, philosophically, we’ve decided that we need to separate things into these individual components. And there’s virtue to doing that, because if it’s isolated then it’s easier to kind of test and sort of treat as a single thing. And you can kind of, in terms of the way we work, it makes things easier to manage. We do have to consider, as well, the fact that these things ultimately have to share the same space and join together into a larger system.

Heydon: And I don’t think, actually, enough of our effort and thought goes into that, funnily enough. I think we componentize things more to make our lives as engineers easier, so that we know what we’re working on at what time. And, but then, we often do neglect the fact that these things will be living in dynamic systems and they have to be …

Heydon: I mean, the Every Layout project, although it’s more about visual design and about layout, is all about trying to make these little CSS primitives, these little layout primitives, in such a way that they can sort of self-manage algorithmically. It’s so that you can take them out of a narrow column and put them then a wide column and then it will be, the code itself will determine how many items abreast there should be or whether it should reconfigure itself in some other way. Because we can’t afford to constantly be intervening, and it has to be a system which is sort of self-knowing and intelligent, I think.

Heydon: There’s always things which you can forget about. So maybe you make a tab interface, you’ve got a row of tabs, you choose between the tab and the tab corresponds to a tab panel, that opens something up. And then, someone will come along and they’ll say, “Well, what if I want to put a tab interface inside a tab interface, or some other component inside a tap interface?”

Heydon: And of course, I mean, it’s partially a technical concern as to whether that would be possible, but yeah, you’ve got to make the choice about whether you’re going to make things as flexible as you can so that it’s possible to sort of imbricate things in a complex way, or simply write hard rules which say, “You can’t put something inside here because the level of complexity in terms of the code would probably be too high, but also possibly in terms of how the user can perceive and use the thing.” I’m all for writing rules which say, “Don’t nest loads of complex functionality inside itself,” because it’s just not likely that people are going to be able to get their head around it, really.

Drew: Is it possible to take a fully algorithmic or automated approach to designing for accessibility?

Heydon: I don’t believe so. No. So we have automated tools and I don’t want to disparage automated tools in any way. I think they are very useful, but I use them as kind of like an early warning system to try and kind of get an impression of where the problem areas are. So, if I was doing an audit for an organization who wanted some advice on how to make their products more accessible. So it’s a good way of kind of funding where the problem areas are, but I mean, you can have an interface which is technically 100% accessible, perhaps, according to some tool, even a good tool for judging it, say, against WCAG, the web content accessibility guidelines, or some other acceptance specification. And, even though it’s a 100% sort of all the boxes checked, it can still be entirely unusable for various reasons.

Heydon: For instance, going back to what we were saying before, it can just be entirely too complex. You can just overwhelm someone with links and there’s just no way that they’d be able to get through it and then that becomes, it’s a very sort of tacit thing and difficult thing to pin down, but it’s bound to just alienate people. But there’s also, you can get, it’s very easy to get false positives and things like that. I had a thing the other day, I said the other day, it was the other month, I was working for an organization and of course they wanted to have a 100% accessibility lighthouse school and there was an iframe which was dropped in there dynamically by a analytic script or something. You know the kind of thing where it’s some sort of slightly gross code, which is just sort of chucked in the page to do some task like that.

Heydon: Now I would recommend not using analytics at all, and I recommended to them to at least support the do not track protocol so that people could opt out. Unfortunately, that protocol is kind of, doesn’t really work anymore because it was never really supported properly. But this iframe, it was saying it doesn’t have a title on it. So the idea is that if you have an iframe, it should have a title attribute because that’s the best sort of longstanding way of identifying what the iframe is for to a screen reader user. But this was an iframe that also was set to display none, so it wasn’t even perceivable to a screen reader in the first place because display none, just as it hides things visually in a screen reader, it will essentially remove it from the interface, so it won’t be encountered or announced in any way.

Heydon: So it was a false positive. I mean, it was asking me to identify an iframe that was not there to be perceived in the first place. So, there’s always going to be those kinds of errors and problems in automated testing. But ultimately, it is about knowing, although it’s just sort of a thing that programmers, I guess, don’t really like to think that they’re involved in and they find it a bit icky, but it is about human behavior and about how people understand things and that’s a very difficult thing to just have a set of kind of binary sort of, or boolean sort of rules about.

Heydon: So, I mean, I spoke to a developer when I was consulting sometime ago about this and they kept saying, “Well, as long as we’ve got automated testing, we’re fine, aren’t we? It’s just, then we can just move forward.” And I said, “You still have to test manually. There’s no automated test which can really tell you if using the interface by keyboard is impossible in one way or another.” There are sort of discrete things you can look for, but the overall experience is still something that needs to be judged by human being. Yeah.

Drew: Sometimes the danger with automated tools is they look at items in isolation or they look at one interface in isolation and not see the wider context.

Heydon: Yes.

Drew: Certainly with using lighthouse for performance audits, sometimes I might make a decision as a developer to include, there may be a lot more CSS than is used on that one page and strictly speaking, I’m downloading too much CSS, but actually, I know that once that file is loaded, by the time the user browses to the next page, they’ve already got the CSS. So it’s an an optimization that’s being made across multiple pages the tool, looking at one page in isolation, sees as an error.

Heydon: Yes, absolutely. You’re thinking ahead and you’re making a judgment call, and until we get to advanced AI to anticipate that, then yeah, you really need human beings looking at it and going through it and going … I mean, so automated testing should be in place, as I say, a sort of early warning system, diagnostic system, but there should also be, if you’re interested in your organization really caring and making things more inclusive and more accessible, there needs to be training as well. There needs to be Q & A.

Heydon: So I would write scripts for, “This is how it should work when you interact with this component with a keyboard,” or, “This is how it should work when you interact with it with a screen reader and not actually step through it. So, when you do this, this should happen. When you do this, this should happen. When you do this, this should appear,” or that kind of stuff. So, and the kind of journey stuff, as you say, automated tools aren’t aware of that. They only just see, “Oh, this doesn’t have alt text here.” And actually, in a lot of cases, maybe it shouldn’t have alt text. And also, it can’t judge whether you’ve written the alt text well or not. So I think an image without all alternative text is probably better than an image with misleading or just bad alternative text. And that’s a judgment call again, isn’t it?

Drew: One of the things that I’ve struggled with, historically, in building things in an accessible way is keeping my knowledge of the best practice up to date because it’s, each time I refer to any documentation or any sort of recommendations, it seems like what I was doing and thought I was doing the right thing, the recommendations have moved on and now I should be doing something else. And that’s a familiar story with all areas of working on the web. But I think the danger is, of course, with accessibility issues, is that, if you’re not following the best practice, if you leave something in your interface that is now not good practice, that could be affecting your users in a negative way. Does a component based approach to building an interface or a site, does it help with that at all in any way?

Heydon: I think purely in the sense that, because you have one component which then, the idea of course in all cases and not just in terms of accessibility, is that you have this component defined in one place which will then be used in different places, at least when aspects or browser support or whatever it is changes and you want to update the component, you only then have to do it in one place and then wherever it’s used, that enhancement or that change will be felt. So from that regard, I think it’s certainly more useful to have things divided into components.

Heydon: But then, yeah, as I say, that doesn’t just affect accessibility, that can affect anything that changes. But then, I’m not sure really how much changes in its … I mean, there’ll be few sort of breaking changes in terms of sort of HTML accessibility, which is, obviously, a very narrow area. But in terms of the code quality or how the code works, things are introduced into the HTML spec, obviously, very slowly and not quite as slowly but fairly slowly into the ARIA spec as well. And then, much of ARIA just mirrors what’s in the underlying baseline HTML anyway.

Heydon: I think, more so than the technology, the perception and understanding of these things tends to change over time. I mean, there was recent, in the WebAIM survey recently, they identified the sites were using ARIA were more inaccessible than sites that didn’t use it. So this technology specifically conceived in order to help people make websites more accessible, was making it worse. So it’s really, it’s just a knowledge gap, not a technology gap or a technology shortcoming. It’s people just taking the technology and misusing it because they didn’t really actually understand how it’s intended to work, unfortunately. Hopefully, some of my writing might be able to help with that. In some areas, anyway.

Drew: But a sort of well structured component-based system would enable you, once you realize that something is out of date or you’ve made a poor decision and you now know better, would enable you to more easily go in and fix that across your application.

Heydon: Yeah, exactly. Yeah, yeah, absolutely. I mean, it’s all about efficiency isn’t it, really? And this dry principle or what have you, and see, that’s why I guess I was originally very excited about this opportunity, because people always complain that making things accessible is extra work and it’s hard and it’s upsetting and all of that. And so, it was kind of an opportunity to say, “Well, you know how you’re making this stuff really, efficiently building these component systems? Get your accessibility in there for that one component that you’re making, and then you didn’t have to worry about the accessibility anymore apart from the occasional spec change or update or what have you.”

Heydon: Or just, I mean, probably most of the time, the iteration will simply be based on user feedback and ongoing research, which, obviously, you should be, as much as possible, conducting with a diverse group of people. So, you should be getting people who use different devices and have different browsing habits and use different assistive technologies and that kind of thing. And you know, things are bound to come up all the time. I think I’ve really pinned down a component, think it’s really rock solid, and then I do a bit of research and I find that I’ve made some pretty bad assumptions. But yeah, with a component system you only have to fix it in one place.

Drew: Can a component ever be fully inclusive or is it a spectrum where you’re just working ever more towards inclusivity?

Heydon: Yeah, it would be possible for a component to be, in terms of let’s say WCAC error free, it meets all of the WCAC criteria, but as I said, that only takes you so far and it could still be entirely unusable or impossible to understand even with those technical criteria met. So yeah, this is something that I talk about a lot. I try to convince people that accessibility is like any other area of design, it’s just a part of the design process and nothing can be perfectly designed just like nothing can be perfectly accessible. I think, unfortunately, a lot of folks think of it just in terms of just making sure that it is compatible with screen readers, which is obviously a very narrow scope in terms of accessibility and inclusion in general.

Heydon: So then, there will be people who, some good folks I’ve worked with like at the Paciello Group, who would say, “Well actually, I want to be known as a accessible UX person.” So it’s not just about this box ticking exercise, it’s more about actually trying to make the experience better and more valuable for the greater number of people and move more towards sort of broader principles and things which are less binary. But ultimately, it’s all that, and WCAC and other such criteria can only really identify the real hard and fast, “This is wrong,” stuff, I suppose.

Drew: So if I’m a developer, what should I be doing differently as I approach how I design and plan and build a component? Is there anything that I should be considering in my work to make sure that that component is going to end up being as inclusive as possible?

Heydon: So, I mean, depending on what you’re building, there’s going to be different criteria which need to be met. So, for instance, not every component is going to have the to have accessible imagery with alternative text, because it might not use imagery at all. It might just be text-based or what have you. Some might not be interactive. So, in terms of the specific requirements, then, it would change between component, but hopefully what some of my writing and what the Inclusive Components book helps you to do is to fall into or kind of adopt a discipline of just thinking inclusively.

Heydon: So, when you’re approaching this stuff, not just thinking, well, basically just getting out of the mindset of, “If it works for me, it probably works for everyone else,” because it’s simply not the case that the way that you or I browse things, I mean, we’ll probably do things completely differently, just us two, right?

Drew: Right.

Heydon: And we’re Western, white, English as first language people. And so, yeah, the amount of diversity in terms of the people consuming this, I mean performance people always talk about this as well, people who are interested in advocating for better performance. You’re used to using a high spec set up on a good network and a lot of your users or a lot of your potential users will certainly not be, and same with accessibility. It’s just a question of, basically, just getting out of thinking about yourself, really. Literally just that. And trying, obviously, to reach out beyond just your immediate colleagues and people in your same social group as well.

Heydon: So hopefully, it’s really just, “Here’s what I solved for this stuff,” and what I was thinking about at the time. You can reuse some of those ideas and apply precisely what I’ve applied, if that’s useful or relevant to you. Hopefully, the book is more about just, “Here is a case study of a person who tries to think inclusively. See, the kind of things they were thinking about, when you’re designing something completely different, perhaps just employ the same kind of thinking and try and open your mind up to the diversity of of users and how they go about things.”

Drew: So the book itself, how did you decide how to structure it? It seems very fiercely practical, which I like in a book, but how have you structured it?

Heydon: Very much like the previous book, actually was Inclusive Design Patterns and I had a lot of trouble that book, to begin with, because I tried to organize it in terms of kind of abstract criteria. So I started out doing a chapter which was all about keyboard accessibility, but that was very hard because then I had to kind of, every time I talked about a different type of keyboard accessibility or the thing that you have to think about, then I had to conjure some sort of component and then ditch that component and then move onto something else.

Heydon: And so, it just made more sense for me to organize things in terms of components themselves. So, Inclusive Design Patterns does this and now Inclusive Components is really just a continuation, which just covers different components. It’s different in that, in terms of features, it’s a bit different because it also includes live code examples and stuff, which I didn’t do so much for the previous books. But yeah, it is literally just, “We’re going to do this component,” whether it’s a tap interface or a collapsible section or a theme switcher or a notification flash card or toaster or whatever they’re called, and then just everything is then organized around that component.

Heydon: So it’s, “This is what we’re doing and these are the things we should consider while we’re doing it to be more inclusive,” because that’s how I work and that’s how other folks work. And as soon as I started doing it like that, it was really just me working and writing notes as I worked. And so, the thing kind of wrote itself, and then all of the effort was really in actually just making sure that I was doing a decent job of making those things not inaccessible, I guess.

Drew: Yes, I mean the table of contents really reads almost like documentation or like a self-help manual or something. Straight in with chapter one, toggle buttons. If you want to implement some toggle buttons, go to this chapter, read it and you’ll get everything you need to know about how to do that, which is an approach I really like. I see things like collapsible sections, tabbed interface, theme switches, data tables, loads of actual, real practical stuff that we’re all building every day and I think we all, probably, could be building better.

Heydon: Yeah, that was totally the idea because it wasn’t just about me making my components, it was a case, and you’ve touched on it there, which I’m glad you did, which is it was of identifying common patterns that we all use. So I mean, there’s tab interfaces everywhere and they’re all implemented differently and they’re all implemented, variously, very badly. I mean, I’ve implemented terrible tab interfaces and that I’ve learned a little about how bad they were for people, and then I’ve tried to make them a bit better and a bit better and a bit better. I’ve probably made 15 or 16 different versions of tab interfaces in my time, having been doing this kind of thing for years now.

Heydon: And you know, they’re getting a bit better, hopefully, every time. But it is just a common thing. It was a common thing that I would use quite often between different websites, I use and everyone uses. So, part of the idea was to say, “Well, actually, let’s do a design system, kind of an accessible design system for the web.” Now, people are going to branch out and they’re going to do their own versions of these things, but to kind of get the core stuff down and the accessibility is a core thing that should be in things. It shouldn’t be an add on, it shouldn’t be an either/or, it shouldn’t be a feature. It should be a core thing. And if you get that core stuff paired down, then yeah, hopefully people would look at the chapters and go, “Oh, okay, I’ve made those. I’ve seen those. Let’s see how to do it as inclusively as possible,” and then hopefully they get some value from that.

Drew: Well, what I like about it is, certainly I know I’ve, in the past, I’ve had some interface features I’ve needed to implement and I know that it’s going to be tricky from an accessibility point of view, say some sort of a fly out menu, drop down menu, something like that. I think, “Okay, here be dragons in terms of accessibility. I need to make sure I do this right.” And so, I Google for how to do it, I find a reputable source saying, “Use this method,” I use that method, I implement it and I move on, but I actually haven’t learnt anything. I haven’t learnt why the solution was that. And what I really like about the way you go into it in the book is I can do two things at once. I can figure out how I should be doing it and I can figure out why I should be doing it like that because it’s all very carefully explained. So, I think it’s really successful from that point of view.

Heydon: Oh, great. That was what I was going for. So that’s good. But yeah, that seems to be my thing. I mean, I’ve been working with the BBC for some months and we’ve kind of made a thing a bit like Inclusive Components but for the BBC, so we’ve done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it’s not a pattern, really. The idea is that the individual departments at the BBC, because there’s so many of them, because it’s such a large organization, so there’ll be BBC Sport, BBC Weather, BBC News, they’re the ones who would be taking care of the kind of technical stack and making their pattern library. And what we’ve really provided is just, we’ve just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Yeah.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn’t going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it’s full of caveats. And the main caveat is, probably don’t use a tab interface. Use maybe an accordion, it’s a simpler interaction paradigm. It’s easier to make responsive, it’s easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven’t written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don’t know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I’ve done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I’ll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I’m kind of doing other things at the moment. But I’m always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I’ve covered and there was just something that they were unsure about or which I, for whatever reason, I hadn’t made as clear as they’d liked it. Yeah, then just contact me because I’m always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I’d recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we’re all about learning. What is it that you’ve been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it’s still available as a PWA, it’s a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I’m now working on doing a much more advanced version of this. And it’s a different kind of drum machine because it’s polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You’ve got these, it’s multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who’s interested in kind of experimental music, that’s something I wanted to play with. Obviously, I’m trying to make this drum machine as accessible as possible. And that’s been interesting from the point of view now that I’m working with, I’m turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I’ve been doing cross browser testing for 12 years now, it’s really nice to have a break and just to design stuff for one browser. And it’s got some, so there’s a flag in Chromium. It’s a, what’s it called, an experimental web platform feature for focus visible. So I’ve been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you’re using a keyboard. So that’s been nice, to be able to incorporate that.

Heydon: But the thing recently that I’ve been learning about, just I’ve, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they’ll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It’s kind of like a reverb or something. But sometimes if you’re doing an arpeggio, like a baseline or something, you don’t want them to open up. That’s not how a bass guitar works, right? If you’re on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it’s not the web audio API having a problem or anything like that. It’s just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it’s going to sound nasty. And then, so I found that there’s a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it’s basically been web audio API stuff and messing around with sounds because I’ve always been into, as I say, into experimental music and messing about with that sort of stuff. And I’m trying to write a talk about this. And in the talk, I’m using Billy Jean by Michael Jackson because it’s a very straight, fall to the floor rhythm and I’m going to kind of warp it in various different ways. So I’ve actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he’s @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.

Smashing Editorial (dm, ra, il)


Articles on Smashing Magazine — For Web Designers And Developers

logo-red-5

Inclusive Design And Accessibility: Live Stream With Heydon Pickering

Inclusive Design And Accessibility: Live Stream With Heydon Pickering

Inclusive Design And Accessibility: Live Stream With Heydon Pickering

Vitaly Friedman

Accessibility can sometimes become an unfortunate afterthought as we race to meet deadlines and search for tips and tricks to meet client demands. We can cause problems for keyboard or screenreader users, and leave our products fragile and potentially vulnerable to legal action from people who find themselves locked out due to their accessibility needs. How can we get better?

One way to find out would be by joining our live stream with Heydon Pickering who will be sharing insights about the relationship between accessibility and design systems, and exploring how to build accessible components, and why he decided to write a book on accessible interface design patterns.

Live Stream On Inclusive Design: Nov 7, 5:00 PM GMT

The session will start today, November 7, at 6:00 PM Berlin time (12:00 PM New York time) — broadcasted live below! (If the video doesn’t play, you can also watch on YouTube.)

For a few years now, we’ve been running live sessions with respected professionals on Smashing TV — our video channel for our dear Smashing Members, who support our little team and our little adventures every month.

Starting from November, we’d like to try out something new. As the webinars have always been about sharing lessons learned with the community, we’d like to open them up to everybody, with Members having a chance to ask questions about the projects and their work right after the session.


From Smashing With Love

To help you stay on top of things, you can subscribe to our bi-weekly newsletter, in which we announce what’s happening in the Smashing universe. Each and every newsletter issue is written and edited with love and care. No third-party mailings or hidden advertising — promise!

You can also follow us on Twitter, Facebook, LinkedIn and even stay updated with our bi-weekly Smashing Podcast. Please do always feel free to reach out and share your thoughts with us — we love hearing from you!

Smashing Editorial (ra, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
inclusive-components-product-image-landscapea

Meet “Inclusive Components”, A New Printed Book By Heydon Pickering

Meet “Inclusive Components”, A New Printed Book By Heydon Pickering

Meet “Inclusive Components”, A New Printed Book By Heydon Pickering

Vitaly Friedman

The web is full of interfaces that leave people out. Of course, it’s not designers’ malicious intent or developers’ lack of empathy that bring us there. It’s just really difficult to foresee a wide range of situations in which our users might find themselves in. We need to build robust and reliable solutions in a world that’s inherently chaotic and unpredictable. Where do we even start?

Because we often build and deploy under tough deadlines, we tend to break accessibility without even noticing it. Our products become slower, clunkier and more painful to use — often simply unbearable for keyboard- and screen reader users, and as such fragile and vulnerable for legal disputes. Let’s fix it.

Meet Inclusive Components, our new handbook for building fully accessible websites and apps.

Meet Inclusive Components, our new book for building accessible, inclusive interfaces. Written by one-and-only <a href='http://www.heydonworks.com/'>Heydon Pickering</a>.”>     </a><figcaption>Because accessibility matters. We’ve teamed up with one-and-only <a href=Heydon Pickering to create a handbook for building accessible, inclusive interfaces. The eBook is finished, and it’s being printed this very moment.

About The Book

At its heart, Inclusive Components is a detailed, practical handbook for building fully accessible interfaces. The book examines 12 common interface patterns — accordions, tables, modals, notifications, tabs, toggles, and everything in-between — through the lens of inclusion. The result is accessible and robust components we author, plug in, and use daily.

For years, Heydon Pickering, a seasoned front-end developer with a focus on accessibility, has been writing about accessible solutions. We’ve teamed up with Heydon to produce a book with common challenges and solutions that he’s been refining over all these years.

For each component, the in-depth explorations are meticulously illustrated and all solutions are available as bulletproof code snippets, applicable to your work right away. Bonus: you’ll learn how to build your own accessible components with inclusive design in mind — all in a single book. Jump to table of contents.

332 pages. eBook already available as PDF, ePUB, Amazon Kindle. Printed book will be shipped early December. Written and designed by Heydon. Download a sample PDF (1.1 MB).

The cover of Inclusive Components, a new book by Heydon Pickering.
The inner spreads of Inclusive Components.

Print + eBook

$ 29.00 $ 39.00

Quality hardcover. Free shipping worldwide, starting from early December.

eBook

$ 15.00 $ 18.00

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

Table Of Contents

Each chapter tackles a single component, addressing how different and vulnerable people might read and interact with it, and how they can be better accommodated. Download a sample PDF (1.1 MB).

A preview of the book, with examples ranging from accordions to toggles, tables, notifications, dialogs etc. Download a sample PDF (1.1 MB). Large preview.

About The Author

Heydon Pickering

Heydon Pickering (@heydonworks) has worked with The Paciello Group, The BBC, Smashing Magazine, and Bulb Energy as a designer, engineer, writer, editor, and illustrator. He was shortlisted for Designer Of The Year in The Net Awards.

Heydon previously wrote Inclusive Design Patterns which sold over 10,000 copies. Proceeds from this title were donated to the ACLU and The Democratic Socialists Of America, to help these organizations fight fascism and create a more inclusive society.

Testimonials

Artem Sapegin“Inclusive Components is a very deep and thorough explanation of development of accessible components with real world examples. Heydon Pickering shows several alternative approaches and explains pros and cons of each. It’s also a pleasure to read!”

Artem Sapegin, front-end developer, Wayfair

Sarah Federman“Inclusive Components is chock-full of practical and comprehensive advice on building accessible UI. It’s my go-to resource after the official WCAG and ARIA documentation. I’ve found it extremely helpful when building our design system!”

Sarah Federman, senior front-end developer, Adobe

Andy Bell“What Heydon achieves with his work on Inclusive Components is a pragmatic, friendly and approachable set of guides that help you to generate not just accessible components, but also resilient and progressive starting-points that will help you to build better websites and web apps in general. I often describe this work as crucial learning material for this exact reason.”

Andy Bell, independent designer & developer

Why This Book Might Be For You

The devil is in the detail and often the things you do with good intentions can impose accessibility barriers unknowingly. Inclusive Components is for every front-end developer who wants to learn how to detect and address potential accessibility issues in their work. The book will teach you:

  1. How to use <button> elements, how to apply styles to your toggle buttons, and how to label them.
  2. How to create managed lists that allow users to create and delete content — in an inclusive way.
  3. How to address and resolve accessibility issues with navigation menus and submenus (aka “dropdowns”).
  4. How to create accessible and keyboard-friendly tooltips and toggletips.
  5. How to create a “dark mode” theme that’s both accessible and maintainable long-term.
  6. How to build an accessible content slider to prevent harm for motion-sensitive people.
  7. How to create inclusive notifications with live regions to communicate with your users through visual and aural channels simultaneously.
  8. How to create data tables that are semantically correct, responsive, and sortable.
  9. How to build accessible dialogs and modal dialogs with performance and inclusive design in mind.
  10. How to create and group inclusive cards (e.g. for teasers).

Technical Details

Community Matters ❤️

With Inclusive Components, we’ve tried to create a very focused handbook with applicable, long-living solutions and strategies to create accessible and inclusive interfaces.

Our hope is that with Heydon’s book, you will be able to make better design and coding decisions as you build your interfaces. Perhaps it will even become one of those reference books you’ll reach to every time you need to build one of those common UI components.

Producing a book takes quite a bit of time, and we couldn’t pull it off without the support of our wonderful community. A huge shout-out to Smashing Members for their ongoing support in our adventures. As a result, the eBook is and always will be free for Smashing Members. Plus, Members get a friendly discount when purchasing their printed copy.

Stay smashing, and thank you for your ongoing support, everyone!

The cover of Inclusive Components, a new book by Heydon Pickering.

Print + eBook

$ 29.00 $ 39.00

Quality hardcover. Free shipping worldwide, starting from early December.

eBook

$ 15.00 $ 18.00

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
3-accessible-presentations

Inclusive Design For Accessible Presentations

Inclusive Design For Accessible Presentations

Inclusive Design For Accessible Presentations

Allison Ravenhall

To all the presenters of conferences, workshops, and meetups: I truly enjoy hearing your anecdotes and learning things from you. I like laughing at your jokes, especially the puns. Unfortunately, some people in your audience aren’t getting as much out of your session as me. They may not be able to see your slides, or hear you speak, or make out the details on the screen.

A few tweaks will make your presentation more inclusive. Here are some tips so next time you’re on stage, everyone in the crowd can laugh at your bad jokes.

1. Create Accessible Slides

Make Your Text Big. No, Bigger.

The back row of your presentation room is a long way from the projector screen. It’s much further than the distance between you and your laptop screen as you create your slides.

Small text in the middle of a large slide
Small text in the middle of a large slide. (Large preview)

People up the back will appreciate every extra pixel you add to your font size. People with vision impairments will appreciate the larger text too — they’ve got a better chance of being able to read it.

Go big or go home. This goes for all text, even “less important” stuff like data labels, graph axes and legends, image captions, footnotes, URLs, and references.

Is Your Slide Font Readable?

I love fonts; they can really set the tone of a talk. However, before you jump into the craziest corners of Google Fonts, think of your audience members with reading difficulties. Using handwriting or script fonts, particularly ones whose letters link together, makes text much harder to read. Using uppercase reduces scannability by removing ascenders and descenders, as well as being shouty.

There’s more scope to experiment with fonts on slides than web pages due to the larger text size, but here are some best practices:

  • Sans serif is typically the most readable.
  • Be generous with spacing (between letters, words, and lines).
  • Use bold for emphasis — underline and italic change the letter shapes, making them less identifiable.
  • Use mixed case, not all caps.

(Reference: British Dyslexia Association Style Guide 2018)

Does It Make Sense In Greyscale?

Do a print preview of your slides in black and white. Does it all still make sense without the color? If you send out your slides post-talk, some people may not have access to a color printer.

There’s also a good chance that someone at your talk is color-blind. If you’ve used red text for negative items and green text for positive items mixed together in a single list, they may not be able to tell them apart. If the datasets in your graphs only use color to differentiate, think about using patterns or labels to tell each bar, line or pie segment apart.

Don’t rely on color only to tell your story — enhance color with labels, icons, or other visual markers.

Recommended reading: Getting Started In Public Speaking

It’s A Slide, Not A Novel

Every time a new slide goes up, you lose the crowd while they scan the new content. If the slide is full of text, it’s going to take a long time for their attention to come back to what you’re saying.

People with attention deficiencies will struggle to read your slides and listen to what you’re saying at the same time. Audience members with reading difficulties may not finish reading text-heavy slides before you move on, and never mind what you said while they were concentrating on the screen.

Slides aren’t speaker notes. If you need prompts, write up some cards or use your slide program’s notes function. Use keywords and short phrases in your slides, not whole sentences or paragraphs, to share the essential ideas of your talk. Write and refer to a long-form companion piece if you want to share loads of detail that doesn’t translate well to slides.

Animated Slide Transitions? Really?

My high-school self-loved slide transitions — the zanier, the better. Look, my slide is swirling down a plughole! It’s swinging back and forth like a leaf on the breeze! Fades, swipes, shutters, I was all for it.

Microsoft PowerPoint contains 48 (!) animated slide transition options
Microsoft PowerPoint contains 48 (!) animated slide transition options. (Large preview)

I have since discovered that slide transitions are overrated. More seriously, they can make the audience feel sick. Slide transitions and other animation such as parallax scrolling can trigger nausea, headaches and dizziness in people with vestibular (inner ear) disorders.

Make your audience groan with your punny jokes, not because they feel ill.

Readability Applies To Slide Text, Too

If you’re presenting, you probably know a decent amount about your topic. You likely use specialist words and phrases and assume a minimum level of audience knowledge.

Be mindful of using jargon and acronyms, even if you think they’re well-known. Explain them, don’t assume everyone knows them. Better still, use plain language for everything.

Don’t mistake using simpler words and shorter phrases for “dumbing it down”. Slides are for clear and concise ideas, not showing off your vocabulary. Save your fancy words for your next crossword puzzle.

GIFs Aren’t Always Funny

Animated GIFs are used in lots of presentations — usually as a killer quip or a laugh out loud punchline. They’re an easy way to add fun to dry tech talks but use with care — and I’m not talking about your bad sense of humor.

If the GIF content strobes or flashes rapidly, it may trigger seizures in people with photosensitive epilepsy. It’s happened: in 2016, disgruntled Trump supporters caused a Newsweek writer with epilepsy to have a seizure by deliberately tweeting flashing images to him.

While a GIF is looping on the screen, I’m half-listening to the presenter at best. It’s so distracting. If there’s an animation on screen while you relate an anecdote, I’m going to miss the story.

When you create an animated GIF, you can configure the number of times it loops. This is a good compromise — have some fun with your audience, then they can focus on what you’re saying without distraction.

How Good Is Your Color Contrast?

The word 'Binary' on the bottom-left of this slide is presented in a large, readable font, but the color contrast is very poor.
The word ‘Binary’ on the bottom-left of this slide is presented in a large, readable font, but the color contrast is very poor. (Large preview)

There are recommended color contrast values for text on the web. The idea is to ensure text is visible even if you have a vision impairment or color-blindness.

Color contrast is important for slide content too. You probably won’t have much control over the environment, so it’s a good idea to use color combinations that go beyond recommended contrast ratios. I guarantee it won’t look as clear on the projector as it does on your computer.

Don’t be subtle with your color palette. Use bold colors that make your text stand out clearly from the background. Be careful about laying text over images — do it, just make sure the contrast is good. Use a color contrast checker and aim for a ratio of at least 4.5 : 1.

(Before you flame me about the big text minimum ratio being 3 : 1 for WCAG 2.0 AA, I figure it’s big up close, but it’s smaller from the audience’s perspective. They’re not likely to complain that it’s too high contrast, are they?)

If you know the setup in advance, light-colored text on a dark background is more audience-friendly in a darkened room; a white background can be dazzling. Some people have even resorted to wearing sunglasses when they were blinded by too much glare!

Enable Your Audience To Follow Along

If you plan to share your slides or you have complementary materials, include links to these on your first slide, and mention it in your intro. This enables your audience to follow along or adapt the presentation on their own devices. People with low vision can zoom in on visual content, and blind audience members can follow along on Braille displays or with a screen reader and earbuds.

Keep Your Links Short

If there’s a web link in your slide, there are two reasons to keep it as short as possible:

  • Readability: Long URLs will wrap onto multiple lines, which is hard to read.
  • Say-ability: You should say your URL out loud for people who can’t see the screen. A long URL is very hard to say correctly, particularly if it contains strings of random characters. It’s also very hard for listeners to understand and record in real time.

Use a URL shortener to create short links that point to the destination. If you can, maximize readability by customizing the short link to contain related word or two rather than a random string.

Does Your Presentation Contain Multimedia?

Video and audio clips are a great way of presenting events, interviews, and edited content that doesn’t work in real time.

If you’re playing video, think about audience members who can’t see the screen — is the audio descriptive enough by itself? Can a blind or low-vision person get a sense of what’s going on, or who’s speaking, purely from the soundtrack? You may need to introduce or summarise the vision yourself to add context.

If your video has an audio track or you’re playing a separate sound clip, are the visuals enough for someone who is deaf or hard of hearing? You should provide captions of decent size and contrast. Given an audio clip doesn’t have a visual component, you could display equivalent text or graphics while the audio is playing.

Don’t Put The Punchline At The Bottom Of Your Slide

This is more of a general usability tip. Don’t bottom-align slide text unless you know that the bottom of the screen is located well above the audience, or the audience seating is tiered. If the bottom of the projector screen is at or below the audiences’ head-height, and the floor is flat, people seated beyond the first few rows will likely not see what you wrote at the bottom of the slide.

Recommended reading: How To Transform Your Next Conference Takeaways Into Real-Life Results

2. Presenting Tips

Have A Clear Beginning, Middle, And End

It can be tempting to structure your talk towards a big reveal. This is a great device for building interest, but you run the risk of losing people with attention deficit disorders. More generally, if you find yourself running out of time, you may have to rush or cut short your final grand flourish!

Set expectations upfront. Start with a quick “Today I’ll be covering…” statement. You don’t have to give the whole game away, just tantalize the crowd with an outline. They can then decide if they want to commit their brain power to focus on your talk. Let the audience know that it’s OK for them to go if they wish.

Don’t be offended if someone chooses not to stay. They may have a limited capacity for focused thought each day, so a conference of back-to-back presentations and loud breakout spaces is challenging. They must pick and choose what is most useful to them. Hopefully, they’ll come back to your talk if it’s shared later.

Give The Audience Time To Read Your Slides

Complex content like graphs with multiple datasets take time to read and understand. If your slide is a slab of text, your audience will get annoyed if you summarise it and skip onto the next topic before they’ve finished reading.

Consider how much time your audience needs to read and understand each slide, based on the amount and complexity of the content. Remember, they’re seeing it for the first time, and they don’t know as much about the topic as you. Structure your talk so complex slides stay up on the screen long enough to be read completely.

You worked hard on those slides, it’d be a shame if they weren’t appreciated!

Provide Captions And Foreign Language Translation

I’ve attended events that have provided sign language interpreters or live captions to translate or transcribe what the speakers say in real time. They’re invaluable for people who are deaf or hard of hearing. International events may also provide foreign-language translation.

If you present at an event that provides these services, send your slides or speaker notes to the interpreters and captioners in advance. They can then research and practice unfamiliar terms before the day.

Many events don’t provide captioning or translation. They’re beyond the budget of most conferences, being both specialized and labor-intensive. In this case, you can potentially provide your own captions.

MS PowerPoint has a free Presentation Translator plug-in to add real-time captions and foreign language translation. I saw a demo at A11y Camp Sydney last year:

Google recently added real-time captioning to its Slides product, too.

Mind Your Language

Your choice of words may be offending or excluding some of your audience, and you may not even know you’re doing it.

Not all people that work in technology are “guys.” When a speaker says “I talked to the guys about it,” I imagine a group of men. If they’d said “I talked to the developers about it,” then my imaginary group also contains women.

There’s also ableist language. Using words like retarded, insane, lame, and crazy incorrectly is degrading to those with mental and physical disorders. What’s a normal user? Are you making assumptions about gender, sexual orientation, race, family unit, technical knowledge, physical or mental abilities, or level of education?

Then there’s swearing, commonly used to get attention or add some spice. Be careful about deploying this weapon. If you’ve misjudged the room, you could put people offside. If you’re traveling, that fairly tame curse word you use at home could be deeply offensive elsewhere.

Stories Aren’t Universal

When I discussed color contrast at A11y Bytes 2017, I moaned about not being able to see my phone screen in bright sunlight. Attempting to relate, I asked “we’ve all been there, right?”, expecting a few nods and smiles.

The retort was lightning-fast: “Can’t say I’ve found it a problem!” Laughter rippled through the crowd as I realized I’d just been heckled by a blind woman. She graciously laughed off my hasty apology.

I still tell my sunlight story, but now I’m mindful that not everyone can relate to it directly. Learn from my mistake, don’t assume your audience has the same abilities and experiences as you.

Interests And Pop Culture References Aren’t Universal Either

My most recent presentations have been about WCAG 2.1, including the need to provide alternatives to motion-based inputs. I use three Nintendo Switch games as examples.

I don’t assume that the audience has used a Switch. I briefly explain the premise of each game and the motion input it uses before I move on to how it relates to the new success criteria. It’s a courtesy to those people who don’t share my interest in the Switch.

Similarly, much as I’d love to do a Star Wars-themed accessibility talk, I won’t because I’d be putting my own amusement ahead of informing my audience. Some people aren’t into Star Wars, just as I’m not a Trekkie or a Whovian. It’d be a shame for them to misunderstand me because they can’t translate my tenuous Star Wars associations — or worse — if they saw the themed talk title and skipped my session altogether.

Have some fun, by all means, include a pop culture reference or two, but don’t structure your entire talk around it. Make it work for someone who hasn’t watched that movie, or heard that band, or read that book, or seen that meme.

A Picture Is Worth A Thousand (Spoken) Words

Photos, graphics and drawings all add interest to your slides. You may have screenshots of a website you’ve built, or photos of people or places you’re talking about.

When your slide imagery is part of the story, remember to describe the pictures for those in the audience that can’t see it. Try not to say “As you can see here…” because someone may not be able to see there.

If you think it’s awkward to quickly rehash a sight gag, think how awkward you’d feel if you were in a room full of people that suddenly all laughed and you didn’t know why.

Slow Down, Breathe.

You’re nervous. You’ve never presented before. You’ve got a time limit and lots to share. You haven’t practiced. Your parents, friends, children, workmates, industry idols, and managers are all in the room.

Whatever the reason, you probably talk faster than usual when you present. This puts pressure on interpreters and captioners, particularly if your talk contains tech-speak. Your audience may struggle to keep up too. Note-takers mash their laptops in vain, live-tweeters’ thumbs cramp up, and sketchnoters leave a trail of half-drawn doodles in their wake. International visitors may get lost figuring out your accent. Cognitively, everyone is thinking furiously to keep up, and it’s hard work!

Practice. Slow down. No one knows your stuff as well as you; give everyone else time to take it in.

Respect The Code Of Conduct And Your Audience

Codes of conduct are found at most public speaking events, such as this one by UX Gatherings. They set the minimum behavior standard for speakers and attendees.

Read the code of conduct for every event you attend — they can differ broadly. Know the no-go zones and don’t go there.

If you are talking about sensitive topics that may upset some of your audience, give them plenty of notice so they can prepare or remove themselves from the discussion. A note in the event program, if possible. A mention on your lead slide, and during your opening remarks. Include contact details of support services if appropriate.

Make Your Code Demonstrations Accessible, Too

Well done if you have mastered the art of the live code demonstration. Few presenters can show off something meaningful that also works while providing a clear commentary.

You know what would take your code demo to the next level? Jacking up the font size. Your usual code editor font size is perfect when you’re sitting at your desk, but it’s not big enough for those sitting in the back row of your presentation.

Check your editor’s color settings too. A pure white background might be startlingly bright in a darkened room. Make sure your editor text colors have good contrast as well.

Don’t Drop The Mic

If there’s a microphone on offer, use it, even if it’s a small space.

Many public conference spaces have an audio induction (hearing) loop connected to their AV systems. The loop transmits the AV output directly to hearing aids and cochlear implants. People who are hard of hearing receive the target audio without background noise.

Recommended reading: Getting The Most Out Of Your Web Conference Experience

3. After The Presentation

Congratulations! You’ve done your talk. There are just a couple more things that’ll round this thing out nicely.

Distribute Accessible Slides

Lots of presenters publish their slides after the talk is done. If this is you, make them accessible! Correct semantics, meaningful read order, ALT text on images, enough color contrast, video captions, limited animation looping, reasonable slide transitions, all the good stuff.

Fill The Gaps With Notes, A Transcript Or An Article

Help people that need more time to take in your talk and need more detail than what’s on your slides. Publish your speaker notes or a companion piece that covers your topic(s). If the event is recorded, ask the organizers to include captions or a transcript (but perhaps don’t rely on YouTube’s auto-captioning).

Conclusion

Applying these tips will make a big difference to your whole audience. Your slide content, design, and how you present can all affect how well the crowd gets your message, if at all. This is particularly true for those with physical and cognitive conditions.

Making subtle changes to what you show and your script will help all attendees, not just those with disabilities, to get the most out of your hard work.

Smashing Editorial (ra, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers

advertisement-10

Building Inclusive Toggle Buttons


   

Some things are either on or off and, when those things aren’t on (or off), they are invariably off (or on). The concept is so rudimentary that I’ve only complicated it by trying to explain it, yet on/off switches (or toggle buttons) are not all alike. Although their purpose is simple, their applications and forms vary greatly.

Building Inclusive Toggle Buttons

In this inaugural post, I’ll be exploring what it takes to make toggle buttons inclusive. As with any component, there’s no one way to go about this, especially when such controls are examined under different contexts. However, there’s certainly plenty to forget to do or to otherwise screw up, so let’s try to avoid any of that.

The post Building Inclusive Toggle Buttons appeared first on Smashing Magazine.

Smashing Magazine

advertisement-8

Web Development Reading List #162: Server Side React, Inclusive Design And The Web Worldwide


   

We shouldn’t let ourselves get distracted by people who work on different projects than we do. If a developer advocate works on a web-based QR code application, for example, their way of tackling things most certainly won’t fit your project. If someone builds a real-time dashboard, their concept won’t relate to the company portfolio website you’re building. Bear in mind that you need to find the best concept, the best technologies, the best solution for your specific project.

Web Development Reading List #162

Thinking about the right decisions rather than following cool, new trends blindly, is the first step to building responsible web solutions. That’s what we call progressive enhancement. The only subjective matter in this undertaking is you, judging what level of progressive enhancement a solution should have.

The post Web Development Reading List #162: Server Side React, Inclusive Design And The Web Worldwide appeared first on Smashing Magazine.

Smashing Magazine

advertisement-27

Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release)


  

Accessibility has always been a slightly unsettling realm for web developers. Surrounded with myths, misunderstandings and contradicting best practices, it used to be a domain for a small group of experts who would “add” accessibility on top of the finished product.

Pre-release: Inclusive Design Patterns written by Heydon Pickering

Today we’re privileged to announce our brand new book on inclusive design patterns, written by Heydon Pickering, with dozens of practical examples of accessible interface components and inclusive design workflow, applicable to your work right away. With this book, you’ll know exactly how to keep interfaces accessible from the very start, and how to design and build inclusive websites without hassle and unnecessary code.

The post Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) appeared first on Smashing Magazine.

Smashing Magazine

×

Powered by WhatsApp Chat

× Chat with Us