 I'm now delighted to introduce Leonie Watson. Leonie is director of Tetralogical, a member of the W3C advisory board, co-chair of the W3C web applications working group, and a member of the BIMA inclusive design council. Leonie is also co-organiser of the inclusive design 24 conference, co-author of the inclusive design principles, and mentor to young people interested in the fields of accessibility and inclusive design. She's also a Microsoft most valued professional. So wherever you are, please join me in welcoming Leonie and Leonie. It's over to you. Wonderful. Thank you, Jeff. And hello everybody. Just give me a moment so I can share my screen. Okay, all things being equal. We should all be looking at the same thing. Before I get started, and this is a thing I really appreciate when other people do because I'm blind and can't see who's on screen. A quick description of myself, painful as this is to have to do for yourself. I'm in my late 40s. I'm female. I identify as she, her. I have purple hair currently up in a clip on the back of my head and because it's ridiculously hot and I'm British, I'm just wearing a black v-neck t-shirt today. And some black jeans for those of you curious about what else might be out of camera shot. It's lovely to be here today and to kick things off for DC DC 2022. I'd like if I may to talk to you about inclusive design and using the inclusive design principles. The reason I'd like to talk to you about this is that I'm not an archivist. I don't curate collections of things. I quite enjoy discovering collections of things. But your field is not one I am terribly familiar with. But what I am familiar with is the ideas that go into creating interfaces that humans are going to interact with. And I'm guessing sooner or later that becomes relevant for what many of you do. The collections you are responsible for putting together for making available sooner or later I'm guessing have a human on the end of them who's curious to discover them and the communities that lie behind them. So I hope over the next few minutes I can share these principles with you as a way to encourage you to inspire you to think about accessibility and inclusive design as part of the systems and collections that you curate and design. So, before that, I should probably take a moment to think about what I mean by inclusive design. It's a common phrase and like many common phrases it has lots of different meanings and interpretations. One of the ones I like is that it's about designing for people with permanent temporary and situational disabilities. In other words, all of us. I have a permanent disability. I'm blind. It changes the way I do things every day and it doesn't really change particularly. But it's not just about people like me who have permanent disabilities. It's about people who have temporary disabilities. That might be something like a broken wrist that stops you using your mouse, an ear infection that means you don't hear so well or perhaps an incoming migraine that means your eyes are not working quite as well as they used to be. You've got a pounding headache that affects the way you think and can process information. It can also be situational disabilities. You might, and this is a really good week for demonstrating this, be out in the bright sunshine where it's not so easy to see what's on your screen. You might be using the hand your least used to using to interact with your touchscreen device perhaps because you're holding hands with your partner, your child, or you've got a bag of groceries or something in the hand you might ordinarily use. But it's the similar impact of any dexterity problem that someone with a physical disability might incur. So it's really this idea about, we talk about accessibility being for disability, but inclusive design is really expanding that definition to encompass pretty much everybody, maybe not today, maybe not tomorrow. Hopefully, not at all, but on the expectation that sooner or later, inclusive design is going to be good for pretty much all of us. And so to help you think about that, I'd like to share with you the inclusive design principles. Jeff mentioned this briefly in his introduction. I co-authored these design principles with Hennie Swan, Ian Pounsey, who are now my colleagues at Tetralogical, though they weren't at the time we authored these. And our other co-author Hayden Pickering. We created these inclusive design principles because we wanted to help people elevate the way they thought about accessibility to become more than just technical conformance and compliance with laws and guidelines and to become something more creative, a bit more energetic, if you like. So the first is provide comparable experience. Quite simply, think about making sure that your interface provides a comparable experience so that people can accomplish things they want to do in the way they want to do it without reducing the quality of whatever content it is you're sharing with people. In strict accessibility terms, we often talk about equivalent experience, and we decided to steer away from that and use the word comparable instead. And the reason we wanted to do this was partly to get that separation from the idea of conformance with guidelines. If you've come across the web content accessibility guidelines, you'll note that they talk about equivalent experiences. But also we wanted to recognize that equivalent is actually a really tough thing to achieve sometimes. And actually what we might want to aim for instead is not an exactly equivalent experience, but something that's comparable. The example I often give is watching the ballet. It's something I used to do a lot as a young person and young adult before I lost my sight. And as a blind person now, I've sort of realized that for me at least there is no equivalent experience. Yes, I can go to the ballet and I can still listen to the music and I can still know the story or have it told to me before I go. I can read descriptions of what the principles are wearing, the costumes of the chorus and such. But there's no real way to convey all the different unique steps that each dancer is undertaking as they happen in real time, which would essentially be the equivalent experience of looking at the dancers on stage. So what we have to aim for instead is comparable experience. What gives me just as good an experience even though it isn't necessarily exactly the same one that everybody else might have. Another example is image descriptions. On the website for the inclusive design principles, we have a picture that I'm showing on screen now. Bear with me if you can't see what's on screen right now because all will become clear. But if you're able to see the image, you might be thinking, this is what a logo? It's actually not. It often gets confused as such and that's probably our fault. We don't have a logo. We wanted to include an image that gave people a certain set of emotions. And that's really what it comes down to. In the code for the website, we could have decided to make this what's known as a decorative image. In other words, to hide it from people like me who can't see because, well, really does it add any value? We thought that it actually does. And that's why we gave it a text description that says three hot air balloons hanging together in a calm sunny sky. Sure, it doesn't contain any information. It doesn't really tell you anything very much about the inclusive design principles, but I'm fairly willing to bet it evokes a certain sense of emotion in you, particularly perhaps on a day like today when it's beautiful outside. You can capture that sense of stillness, of soaring up above in the brilliantly sunshiney sky. And that's a nice feeling that everybody should share in. So that's the idea, something that everybody can share in, whether it's words describing a picture or the picture itself. That's a comparable experience of hopefully happiness, calmness, sunshineyness, whatever it may be. The next principle is to consider a situation to think about the ways or more importantly the places in which people are going to be accessing the interfaces that you build and making sure that you offer a good experience for people no matter what their situation. So, for example, I mentioned, you know, the sunshine a couple of the times already this morning, someone might be out in bright sunshine, you're looking at your content on a mobile device. That's going to mean the sun's glaring off the screen, and that's going to mean things are perhaps a little less easy to see. So making sure you use well contrasting colours so text shows up clearly against its background or important objects show up clearly. This is really fundamental accessibility, but it's all about recognising that in this particular situation, someone outside in the sunshine is going to find it much more inclusive if they don't have to sort of try and find a bit of shade, shade their screen with their hand or do all those kind of awkward things that might make it more possible to see what's on screen. Be consistent, use familiar conventions and use them consistently. It'll probably come as no surprise to you is that we humans don't really like having to work terribly hard for the things we want to accomplish. We like a nice easy life. And one of the ways that we can do that in terms of inclusive design is to use patterns that have been used before. So they're familiar, they're conventional, people recognise them by looking at them or by hearing their screen reader tell them what it is. And in turn, knowing what it is, how to use it, how to interact with it. Not having to learn new processes and new sort of patterns and situations and forms of interaction. This of course is good for everybody, it's good usability, but it's particularly helpful to people who have cognitive disabilities that make learning new things or processing information more difficult. Or to use one of the examples I mentioned earlier, someone who's coming down with a migraine and is finding, thinking and processing information a bit harder than they might otherwise do. Giving people control, we all like to be in control and we're using technology, quite often feels like we're not in control. If you're anything like me, you probably spend a fair amount of time cursing at the screen, but from the point of view of building inclusive systems try and give people as much control over what they're doing as you possibly can. A really good example of this is infinite scroll. They're quite popular when you've got a lot of content and if you're a sighted mouse user, they're really great. You can just skim with your mouse wheel, whizz through the content, skim through it visually until you find something that catches your eye or you're interested in and then you can slow down and focus. If you're a sighted keyboard user though, things don't work out quite so well because you have to use the tab key to move through content. And if you want to get to something that's a chunk of the way through the infinite scroll, you may well have an awful lot of tab pressing to do to get to the place you wanted to be. And then you've got an awful lot more to get out back into the main part of the page. So giving people control would be saying, here's a pagination option. If you don't want to use infinite scroll, if it's not the way you prefer to control content, we'll give that option to you and let you choose say pagination as an alternative mechanism. Following hot on the heels of that is offering people choice. There's a lot of overlap between these two, but it's about giving people choices about the way they can do things, particularly if those interactions or your content is less familiar than it might otherwise be. It really comes down to giving people multiple ways to do it. Sorry, enormous explosion just outside my window. Apologies for that. On screen, we've got a picture of a Google Maps and it shows you two different ways to get from your current location to your destination. You can walk or you can drive. It's about thinking like that. You might prefer to do a general search for a document in an archive. I might prefer to browse a category list based on, you know, the taxonomy that the documents are organised into. Someone else might have the specific document ID or ISBN number or whatever it may be and can look things up more specifically. In other words, people don't often want to do things in exactly the same way. So giving people choices means more people can get to things more easily with less stress. And that also means prioritising content, helping people get the thing done they came to do as quickly and efficiently as possible. And also prioritising certain tasks as well. A great example is from Mind. The mental health charity Mind recognises that it has two primary audiences. I should say two primary audiences, but two main audiences. People who are seeking mental health guidance and people who are wanting to donate to the charity. And so on their website, they've got two highly prioritised calls to action, one for one audience and one for another. Visually, they're right at the top of the page that you can't miss them in the code order, which is important to people like myself who use screen readers. They're also right at the top of the content area. So in other words, no matter who you are, no matter what kind of device or approach you're taking to interacting, you're going to get those two priority calls to action. And it's very clear, depending on what you want to do, which one you should take. And lastly, my favourite, add value. Think about ways you can add value to your interfaces or think about what you're already doing and how you can add even more value. One of the nice ways to think about this is in terms of doing the hard work so your consumers don't have to. This is actually one of the design principles we put together right back in 2010, 2011, when we were first putting together the idea that is now the Gov.uk platform. And I love it. It's something I hold really true even to this day because the more we can do to create inclusive systems, inclusive collections, the easier we make it for the people who are going to use those things in the end. And I think as professionals, it's on us to take up the heavy load in that case. The other reason I like this principle more than the rest is because it's really where some creativity comes into play. It's all the imaginative ways we can come up with to do things differently or better. For example, if you're thinking about something that's going to issue notifications, particularly on apps or mobile devices, think about using vibrations as well as sound as part of the notifications. So people who are deaf are notified just as easily as people who are not. If you're asking people to fill in an address based on their present location, think about using the geolocation APIs, being conscious of course of personal data, privacy and security. But it can be a lot easier for everybody to have their address automatically filled in, but even more so for people who have physical or dexterity difficulties. So this is really where you can let your imagination loose on the whole idea, I think. And I hope, thank you, that that has given you a very brief introduction to the inclusive design principles. And I hope it's encouraged you, maybe even inspired you to head out after the rest of this conference and have a think about the things you're working on. You're responsible for your building or perhaps the ones you're planning building and maybe incorporate a few of these ideas and principles into what you do. Thank you. Thank you, Leonie. So I realised in my rush to start, I forgot to do my physical description, so I'll correct that. So I say I'm Jeff, I'm in my mid ffifties, I'm bald, I'm wearing a blue and white check shirt. I think the kind of shirts they tell you not to wear on television and I've got glasses on as well. So thank you so much for that really thought provoking talk. We've got questions coming through already on the Q&A session, and I'd just like to encourage everybody else if you've got a question, use the Q&A function please. If you put it into the chat, I understand it will pop across into the Q&A anyway so that we can have a good conversation. We've got plenty of time, so hopefully more things will arise as we go on. So perhaps if I start, I was really interested when you mentioned earlier, Leonie, about the co-creation process that you'd gone through. And I guess I'm just interested to know how you found that experience and how that worked, whether you were able to rationalise differences of opinion and how much that works its way through into the principles. It was an interesting experience. All four of us had known each other for some time, so we had the benefit I think of A being familiar with each other on our backgrounds and experiences and perspectives. Also, I think it was made pretty easy by the fact that the very reason we all came together to do this was that we all had some fairly similar ideas about why and what we hope to achieve. But the four of us do come from very different backgrounds. Hayden and Ian have a strong development background. I have a little of that going a bit further back in time than either of them. Hennie's background is much more in UX and sort of application design if you like. So we did bounce off each other and it did take a little bit of back and forth. But I think because we had that shared goal, even where we disagreed or had differences of perspective, they were pretty easily resolved through some conversation and sharing of ideas. That's great. I'm thinking about the principles then. So for smaller organisations, you know, the kind of organisations that don't have huge amounts of resources or particular web expertise, are there any quick wins or priority areas that you would advise them to focus on? Yes, I mean the principles are much more about sort of your thought processes if you like, how you as an individual or a team might approach things. In terms of quick wins or things that are easier to accomplish than others, coming back more perhaps to the specific idea of accessibility. I can share this on YouTube, a series of 10 quick accessibility tests that anyone can do that Tetralogical put together precisely to help with that question that you've just asked. Each one takes less than a minute. And if you can get into the habit of using those on a regular basis, there's something in there that makes things more accessible to people with all kinds of disability, hearing, sight, cognitive, physical. So I think probably more than anything. Just remember that every little thing you do will make a big difference to somebody somewhere, and it's actually quite surprising how far reaching those differences can be. Keyboard accessibility is a really good one. From a testing point of view, just abandon your mouse for a few minutes, use your tab key, enter key, space key and have a go at using your own website for yourself. If there's anything that doesn't work just with the keyboard, fix it. And if you can do that, you are helping many people, sighted keyboard users who just can't use a mouse or prefer not to. People like me who use assistive technologies that don't tend to work so well with a mouse or because we can't see to point and click. Even sighted mouse users will often prefer to stick to using the keyboard because it's less hand waving around than switching between two different devices all the time. So just fixing one thing, you're already starting to help an awful lot of people. So try not to be scared by the enormity of what accessibility often looks like and just start making steps in the right direction. I know personally my experience of moving from, if I have my mouse or I don't have my mouse, my experience is then quite different. So I can imagine that using a keyboard is different again. So just think about the, I've got a question here on the Q&A. So do you plan to extend the inclusive design principles? Yes, always. And one day we'll actually get time. I'm working at the moment on actually extending some of the examples, not the principles themselves for the moment, but some of the examples to include different types of interface. What's there at the moment is very web and app focused. A big interest of mine in recent years has been voiced interfaces as they've become more popular and more common. So I'd like to add in some examples, certainly of the different principles that encompass those interfaces. Another area we'd like to expand that into is sort of XR as the umbrella term for augmented and virtual reality in different forms. Thank you. So I'm going to keep going with the Q&A because they're coming thick and fast, so it's really good. Keep them coming everybody. Thank you for such a fascinating talk. Do you have a favourite example of inclusive digital design in the heritage sector? Tough one. I don't think I do. I'm really sorry. Not because there isn't one I should hasten to add. It's just that's not a sector. I've got a great deal of familiarity or have many opportunities to explore and I'm afraid. So sorry. If we broaden it out, what's the one that you would say? Go and take a look at that one. So I often come back to the Gov.uk website. Not because it is the most gorgeously creatively designed website, it's not. But because it was never really intended to. But what it is for the most part is I think really usable. And really accessible. And one of the reasons I come back to it is that in 2012, just after it was launched officially, it actually won the design of the year award. And that's an award, if you're not familiar with it, that's usually given to architects or fashion designers or artists in the conventional watercolours, oil paintings and such. Characters from those industries is not often given because a thing is entirely fit for purpose, which is why it won it. In terms of more creative websites, that's an interesting one. And I'm sorry, I'm using the differentiation of creative because I'm imagining a lot of heritage websites have a great deal of sort of engaging content more so than probably applying for a phishing licence while doing your tax returns. How do I think it's a really good website? That's interesting. I can't think of really excellent websites, but one feature I have come across recently that I think is done well, and I suspect might be increasingly common on heritage websites is the use of virtual reality to show someone an art. Or round a room or something like that. And I think done well with good audio description so that there's a voice over narrative that's not there for accessibility purposes, but just what we call natural audio description. So the natural voice over for the virtual reality tour explains what we call natural audio description. So the natural voice over for the virtual reality tour explains what we call natural audio description. Not there for accessibility purposes, but just what we call natural audio description. So the natural voice over for the virtual reality tour explains what's happening and describes what's happening. I think that's a really good technique I've seen emerging recently. The good UK one is an interesting one, isn't it? Because like a lot of people, I use it for various purposes. And I don't know if you've got a view about where websites hand over to someone else. So good UK, if you're doing a tax return, inevitably you go from the good UK website to the HMRC website and then back again at the end. And if I think about the National Archives, we work with partners quite often. So very aware that people experience our website, but then might go off to a third party website before coming back. So do you see problems with that or do you see challenges around that? Yes, there are. I mean, that was one of the main reasons why Gov UK came into existence back in the last decade. And I'm sure you're all much too young to remember this. Every single central government department had a different look and feel, different logo, different colours, different navigation, different layout, different everything. And the idea was that we should try and come up with a common look and feel for all these departments. So that was the original goal. That's largely being achieved. But it does fall down in a few places. There were a couple of government departments that were excluded from the beginning, the NHS most notably. And you're right, there are areas where bits of different services, HMRC being a good example, still exist in different places. And they haven't quite adopted the same common look and feel yet. So there is a bit of a cognitive jar that happens when you do that. I hope that will even out over time because, as I say, the idea was to do the hard work so that consumers didn't have to. And part of that hard work was to make central government uniformly look and feel pretty much the same. So people knew where to go, how things worked, where to find them and all that sort of stuff. Couple of questions from the Q&A. So Leslie Ruth then apologies, Leslie, if I've mangled your pronunciation of your name. It's quite a long question. The next two are quite long. So do you have any advice for novice alt text creators? For example, any resources to help decide what kind of language is appropriate? Should we keep anything special in mind when describing creative works? For example, visual art in an art school context. It was a great question. I will, after we're done with this, I'll share some links that hopefully can be shared with all of you. The first rule of thumb with text descriptions is try to keep them reasonably short. If you want to take more than perhaps a sentence to describe something, then include it in the copy of the page or associated somewhere else. Text descriptions, as in the thing that goes into the alt attribute of the image element in HTML are intended to be fairly short and sweet. The other thing, and I sort of mentioned this with respect to the balloon's image, is unless it really is quote, I can the unquote, I like a flourish or embellishment. Think about why you've put the image there and if the answer is, you know, to incite a sense of feeling or invoke a particular emotion in the audience, then feel free to give that a text description too, because I want to be included in that every bit as much as somebody looking at the image. This, I will say, is something that you will find people like me who used to be cited saying, you're much less often find people who've never had any vision caring one way or the other about it. So it is subjective, but if the text description is there, we can choose to listen to it or we can choose just to skip over it and bypass it. If it's not there, of course, we don't get the choice. So, so yeah, if there's a reason you put the image there in the first place, let everybody share in that and give it a text description. Beyond that, there's a whole bunch of things around, you know, how do we deal with things like ethnic ethnicity and skin tone in in text descriptions. You know, how do we deal with artistic works. That all takes quite a lot of explaining. As I say, I'll share a couple of articles that have more words on that if that's useful. But for the artistic ones, I would very much say, yep, take time to describe them, but it may well be a case that you need that additional space rather than the text description itself to do that depends on the context. Yeah. Another question for you. Great talk, Leone. Just wondering, do you have any advice for other people who have a disability who feel frustration or resentment about not receiving an equivalent experience in life and how to manage those feelings. Also, the other conferences do not do well with accessibility. How should we deal with these situations? So the first one, speaking personally, I vea between very calmly getting in touch with the organization and pointing out, you know, carefully and thoughtfully what's not working for me and how they can fix it. And usually what happens is about 10 minutes after they reply to say, we're very sorry you can't do this. Have you tried clearing the cache on your browser and you explained that it's got nothing to do with your browser. It's got nothing to do with the way they've built the website. And then they come back to you and say, well, thank you very much. We take this very seriously. We will let our development team know that's usually about the time I go stratospheric, unfortunately, because it is just mishandled customer communication at the end of the day. After that, I will admit it depends what frame of mind I'm in. Sometimes I'll persevere. Sometimes I'll go to Twitter and kind of make it public. I'll just resignedly give up and try to find another way to do it. I realize none of those are terribly useful strategies, but it is contending with the reality of organizations that more often than not don't handle this terribly well and don't understand what you're trying to tell them. Sorry, Jeff, could you remind me the second part of the question? Yes, sure. Yes, the second part is if other conferences do not do well with accessibility, how should we deal with these situations? Let them know again would be my first suggestion from experience, unlike a lot of organizations, conference organizers tend to be more receptive to sort of feedback like that. I don't have much on the sort of conference, of course, but if you're talking about a local meetup or a conference, usually the community organized conferences, they tend to be very, very receptive conferences like this one. I think where there's a genuine interest in this subject matter, I think it's a really good idea to get in touch. There are resources out there that you can refer conference organizers to the Web Accessibility Initiative from the W3C, for example, has a whole bunch of information on holding accessible meetings and events. So, yeah, try and explain, try and point them to positive ways that they can affect change and, yeah, try and be encouraging as much as possible and, you know, if you're getting the wrong response, it's back to the same kind of thing as the organizations. You know, feel free to get a bit tougher and make your point a bit more enthusiastically. Yeah. Thank you, Conor Leonard for that, for that question. Georgie Salcedo says, highly only thank you. Sorry, my question jumped around there. Thank you for your keynote. I wondered if you have any thoughts around improving the experience of users consuming large volumes of text with a via screen reader or visually. I've said it's likely that much of the content is going to be text heavy. Secondly, is there anything we should do? Anything we should be especially aware of when providing transcripts alongside digitized documents? Another two parts. Sure. So the second part is probably the quicker and easier to answer. Make sure that the link to the transcript, assuming it isn't embedded in the same page as the media content it relates to, is positioned above or before the media content on the page. This one's particularly aimed at screen reader users, particularly deaf blind screen reader users. I've seen the link to the transcript placed after the media player quite often and I've often not realized it's there at all. Just because we tend to navigate through content in linear sequence through the page, surfacing that link so people know it's available. In terms of something else on transcript. No, I think that's probably the main thing. Obviously doing what you can to make sure the transcript is accurate, that it's got all the good characteristics like color contrast, comfortable text reading size, all of those kind of things I think is. Is also important to do. Jeff, sorry, could you remind me of the first part again? Yeah, so the first one's around improving the experience of users consuming large. Yes. So this is an interesting one and I think it's one of the areas where potentially there's a bit of incompatibility between academia and the rest of us. I say this because I'm studying to do a degree in my spare time at the moment and I keep getting told off by my tutor for putting headings into my assignment answers because that's not how it's done in academia. We just construct, you know, our flow of arguments and it all naturally progresses from one point to the next. I'm used to writing blog posts where we slap headings into everything to help people navigate through them and chunk it up you see. So I'm guessing there's going to be quite often that inherent incompatibility between the two styles and preferences, but if you do have the ability to control it, headings is a really good way, both visually and for screen readers to break up the content and make it more navigable. Having a table of contents is perhaps another way to do it. Slightly less elegant than using headings, and it probably won't do much for the visual segmentation of content, but at least it does help with the navigability of it somewhat. The other thing is, and it's sort of back to the idea of the infinite scroll versus pagination, give people a choice. Would they rather read it one chapter at a time or one section at a time, whatever segment may seem most appropriate for the content? Or would they rather have it all on one page? For me as a screen reader user, I most often prefer everything to be on a one page because then I can just set my screen reader reading it. I can grab a cup of tea, which you probably see I'm drinking away as we speak now, and that's all the interaction. I can just sit back and listen and concentrate on what I'm hearing. All the people, of course, even other screen reader users will have different preferences. So it's that idea of giving people choice, I think would be a useful way to think about it. Just sticking around visualisation then. Bernard Ogden says data visualisation is an increasingly popular way of representing complex data. I think I can see that these principles will be useful in thinking about how to represent data, but I wonder whether you have any particular guidance for complex visualisations. Actually, I'm contributing a chapter to a book that will be due out later this year on this very subject, looking at data visualisation accessibility. There are lots of things to think about colour contrast, again, making sure that your legends explain what all the different colours mean. Complex is where things come unraveled to a certain extent, though. There are ways that you can make complex visualisations accessible in and of themselves, as in you can explore the content, the visualisation itself. Accessible to screen reader users, but it's fairly limited. If the chart or the graph is something as simple as a line graph or a bar chart, it's just about possible to do it. Anything more complicated than that, then you're having to look at providing an alternative. The way I like to do that most often is to offer something like a tab panel or a set of tabs on the page. You might have the graphical visualisation version shown by default and then have the other tab that shows a text rendering or perhaps a tabular view or whatever it may be. Again, you're giving people a choice about how they want to consume the content. Again, it's not about an accessible option and not an accessible option. It's just, here's the graphical version and here's the not graphical version. Have at it and choose the one that works for you, given your set of circumstances. That's great. Rachel's minute's got a slightly different question. This is her question. I'm interested in the idea of disaffordances in brackets, so misrepresenting self to access something. Where does this idea sit within inclusive design and how can we tackle this idea when we cater to the general public to try to limit options in favour of usability for as many people as possible and want to be able to have usable or reportable data? That's an interesting question. Could I trouble you if you're asked it to explain a bit more about what you mean on that one? Perhaps Rachel can embellish that in the chat and then we'll come back to it. Mark Bell asks, do you think more could be done by the creators of the tools and frameworks used for web and app development to encourage and enable inclusive design? Yes. I do. The first thing that every single one of them could do is better at accessibility and inclusiveness to begin with. All the wonderful people who are busy contributing to these packages, frameworks, whether they're driven by big companies like Metta and Facebook or open source communities, I think if more accessibility and inclusivity could be built in to the things from the very beginning. The less hard work everybody else would have to do once they start using those packages and frameworks. We're getting there. Some are doing better than others, but there isn't a single one that couldn't be doing better and making life easier for the people trying to implement them out there in production. Just stick with the idea of end users with perhaps limited digital skills. Thomas Poole asks, do you have any suggestions to enhance accessibility through web design for audiences with very little in the way of digital skills and capabilities? I think a lot of it has similarities with the techniques that we recommend for people who have cognitive disabilities. I mentioned earlier people who find learning new things difficult or processing information or even just basic memory. It starts to fade for all of us as we get a little bit older. So trying to keep things as simple as clutter free as possible and using patterns again that are familiar. A lot of the user interface controls that we have on the web in software come from the analog world, the real world. Buttons are a very good example. We've had buttons on stuff for decades and decades and decades. There's a reason we transferred a lot of their characteristics to the web. It's because we know what one looks like. Generally speaking, it stands proud of its surface when it's not pressed and when it lies flat. We generally have come to expect a button to turn something on off, toggle it on or off. That's by and large carried over to the web. I think the more we can call on those conventions and what people expect and keep things familiar, I suspect the easier it'll be for people who are coming to the digital world for the first time or growing or acquiring digital skills. I had a question on the wrong one. I was jotting down the various principles as you were going through them. They all seem really straightforward and sensible, don't they? I guess the trick is in following them through. My question was going to be which ones do people in your experience frequently get wrong? One of our Q&A sessions has perhaps expressed that in a slightly more positive way, which is which one do you think people should be focusing on? I don't think there's one that anybody should be focusing on. I think there is a collection and to pull out one above the other. Honestly, I wouldn't know where to start because I think they're all worth thinking about. One that I think I come across probably more than the rest that people don't so much think about is a combination of the give control and offer choice. We see it in some patterns where it's become common to offer people choices, but in a lot of respects we still find giving people different ways to approach something or letting them choose how they do that is probably one that doesn't happen as much as we'd hope. Adding value is probably the hardest one because it's so fluffy. The web content accessibility guidelines, if you've come across them, they're very testable. They're all about yes, no, right, wrong, didn't, and these are not at all intended to be like that. You can find ways to do all of these things, I think, in the principles through WCAG, except perhaps the last one. So the last one, more than anything, adding value is really getting back to the idea of thinking, thought processes, imagination and creativity, really flexing our creative muscles on this one. Rachel's come back with a, you know, Rachel asked the question about disaffordances. So let me read, put it in the chat actually, so I'll read it out for you. Ooh, I'm going to be quite rude at this point and say that's lazy design. You know, the logical extreme of that kind of thinking is that we exclude everybody sooner or later for one reason or another, and you know, we've only got to look not too far back in history to realise that excluding people for whatever reason, however well-intentioned it seemed to be at the time, is generally not a good thing to do, you know, creating a drop-down list is not difficult. If you really think that, you know, female and male preferences are, you know, the majority then surface those at the top of the list, I'm sure people, you know, will not mind a couple of extra key presses or a bit of extra scrolling to drop down to the, you know, the options that are third and fourth in the list. I would hazard a guess that that would be a far more appealing experience than not being able to select their preferred gender or identified gender at all. So yes, perhaps, you know, perhaps because I have a disability, perhaps because this is my field of expertise. But back to that idea of do the hard work so that people don't have to, except inverted a little bit to say do the hard work so that people can make the choices that they should be able to make. Yeah, that's a good advice. A question from Penny Charman, from Bodleian Libraries. I'd be interested to hear your thoughts about, so I have one of those things where the Q&A thing keeps jumping on me halfway through reading it, sorry. I'd be interested to hear your thoughts about addressing accessibility with third party software suppliers and ensuring that it's kept in mind throughout development. Yeah, this one's tricky. A lot of it has to start with the procurement process. And of course, the problem with that is that an awful lot of times that horses has altered. But if you are embarking on a, you know, the search for a new third party vendor or a third party tool then making sure it's really clear in your brief in the contract that you agree with them, what your expectations are. The really important thing to do in all of that is building some kind of clause into the contract that says we either want some kind of independent verification. You may have this already. Some vendors do have what in the states they call an accessibility conformance report. It's based on the voluntary product accessibility template or VPAT. Others have accessibility statements, but you're looking for some independent verification, not just the organization's worth that whatever they do is accessible. Once you've got that in the contract, hopefully it will do two things. A, make the vendor very aware that you're quite serious about this. B, it gives you a wall to put your back against if you discover that what you've been delivered is not accessible. But it also puts the onus on the service provider to provide that evidence. Without that, what happens, and I've unfortunately seen this happen too many times, is that there's a clause in the contract that says, you know, the website you deliver us will be, you know, WCAG compliant or, you know, the tool you'll provide us, you know, will be accessible by some definition. And the vendor sort of says, oh, but it is, but it is, and you're equally convinced that it's not. And then the onus lies on you to have to go out, spend the extra budget to prove your point, to go back. And at that point they claim, well, you know, we're going to need more time, money, budget, or I'm sorry, we really can't, you know, can't do anything about it. So, yeah, get those two clauses in your procurement, if you can. If you're part of a buying, not committee, that's not the right word, but a sort of buying conglomerate, if you like, if you have other organisations and you're buying in bulk or collectively, use that. You know, explain to vendors that, you know, particularly, as I imagine many of you are, you're working in the public sector, you have legal obligations, so do they, if they're selling to you now. So hear them with that, you know, a little bit, let it be known that, you know, you will move on and look at other options if they can't meet the level of accessibility. So use your purchasing power as much as you can. Other than that, if it's existing tools and we have worked actually with at least one organisation that I know to be present today where they work with a third party agency. And there are agencies out there who are just totally on board with this. And in fact, more so than that, really enthusiastic to up their accessibility game because they know it makes them more effective, more compelling in the marketplace as well. So sometimes just talking to your vendors and saying, hey, you know, how about it? You've got something to gain in this as well as us. So what if we team up and solve this together? Yeah, win-win. Bernard asks, well, you were talking about comparability. You mentioned wanting to get away from conformity to standards. Please, could you explain more about your thinking around the usefulness of standards versus principles? So standards are important. More than that, I think they're necessary, not least because they're part of laws and policies and they're not going away anytime soon. So I think standards are extremely important. They give us the first part of the framework that we need for good accessibility. What they don't do so much, and this is where the principles come in, is think about how we take technical conformance and turn it into something really excellent. So a good example for me is audio description. If you're not familiar with it, it's a secondary soundtrack that can be applied to TV programmes, movies, online video content. And in the gaps between the original dialogue and sound effect, it adds extra narration in to tell me what's going on screen that I can't see. I always, this is my favorite example. Years ago now I watched a Samuel L Jackson movie because I'm quite partial to those sort of movies. And it was a proper kick-ass crime busting, lots of yelling and shouting and kicking and goodness knows what going on. And if you're familiar with Samuel L Jackson, you know he's a person of color. He's got a rep as being a pretty cool, the kind of movies he's been in. And the audio description for this was somebody who sounds like me. It was like BBC Radio 4. And you're thinking, hang on, you've got Samuel L Jackson in his like, you know, American person of color, cool accent and all these things going on in this fast-paced movie. And then someone describing what's going on sounding a bit like this. And it was a really jarring experience. What would have made it accessible. You know, I could understand what was going on on screen, but what would have made it really inclusive so that the experience was absolutely excellent. Would have been having the audio description voiced by someone who fit the genre and the style of the movie in question. So I hope that kind of makes sense about the difference between the two. One lets me get something done. The other really elevates it into an experience that's so seamless. I almost don't notice it's there. It's just absolutely a flawless part of the whole thing. That's a great example, isn't it? I think that really helps to kind of bring it to life. So we've got about five minutes left. I've got probably about a minute's worth of wrapping up to do. So I've saved these two questions to the end, actually. So the first one is, can you give an example of where inclusive design, as opposed to accessibility, makes a difference for you personally? I think that was it, actually. The one I just did. That's probably the best example, absolutely. OK, so the last one then. Really just thinking about where next. So thinking about the most important change that you'd like to see happen in the next five years for inclusive design. I would like. Actually, I'm going to choose two things. Sorry. The one thing I would really like is to see accessibility and inclusive design made an intrinsic part of education. The biggest problem we've got with all of this at the moment is that young designers, user researchers, developers, practitioners are not leaving school, university, college. Within understanding of how to do things inaccessible and inclusive ways. More often than not, if either thing is included in the curriculum at all, it's a separate module or syllable. And they will learn about accessibility and inclusive design, and then for the entire rest of their studies, nothing will be accessible. The code examples won't be accessible by default. The design recommendations and strategies and techniques won't be accessible by default. And until we stop churning out newcomers into the professions that make up all of this, we're going to have to keep fighting a constant regard action. So we've got to fix that. We've got to fix it at source, I think. And the same goes for blog posts, articles, online tutorials, the whole lot. We need to educate people not to think about accessibility and inclusive design as an afterthought or an extra thought process, but just as something that's part and parcel of everything they've learned how to do from the get go. Since it's unlikely that we're going to fix that in the next five years. The other thing I would really like people to do or to see people doing in the next few years is just the best they can. I mentioned this or touched on it briefly before. It's really scary when you start thinking about accessibility, because most people recognise that it's going to have a real human impact if you don't get it right. And that can lead to inertia that means nothing happened. You might also be facing challenges from your bosses, your planners, your budgeters, your accountants, all sorts of people with apparently good reasons for saying there isn't enough time, there isn't enough budget, we don't have the skills. Try and ignore them. Sneak as much as you can under the radar. Even if it's only one little change when you're building, designing, developing, thinking, planning, something, because every little thing you do will make a difference, as I said before. And believe me, nobody ever complained that someone made something too accessible. So, yeah, get crafty. Sneak it in every which way you can and remember every little bit helps. Get crafty, I love it. The message will all take away. Leone, thank you so much.