 everyone. Good afternoon, good morning, good evening depending on where you are. Thank you for joining. We're gonna start in a minute, our webinar about building accessible websites with Drupal. While we wait, I'd like to roll out a poll just to get a better idea of who's here with us today. So hello, Susanne. Would you like to start sharing your screen? Sure. Can you just check for me if I have my notes open? Can you see the notes? No. No? Okay awesome. So I can cheat by having notes. Okay. So just let's wait just one more minute in case we have any anyone late. And in the meantime, if you'd like to go to the next slide, I can introduce you. A speaker for today will be Susanne. She's the co-founder of the Drupal Web and she's also a Drupal expert that loves teaching Drupal. She's gonna be talking to you today. And I also like to introduce Evolven Web. Evolven Web is a web agency where right now over 40 designers, developers, strategists and project managers. We've been specializing in Drupal for the past 13 years and we don't just build websites and hope for the best. We focus in design for inclusion and accessibility. We have a user-centric approach to design. We're data-driven in decision-making and of course we always bake in security and stability. So with all the introductions made, I'd like to start. I'm gonna end up pulling Susanne so you can see the results and have an idea of who's here today with us. So yeah, so we have lots of developers but actually a good representation of designers as well and content editors and project managers. And then most of you are from other industries. So that other category captures where most of you are working but then there's also some government higher ed NGO folks here which is often a key audience for content about accessibility but it's great to see a broad interest that's exciting to see. So like Perina said, I have been using Drupal for many years and wearing different hats and one of those hats is as a trainer and I've trained people who are using Drupal for the first time if they're content editors or developers or project managers and there's a growing interest in accessibility which is great to see and it's one of the deciding factors that people have in selecting Drupal over other platforms. But that being said, just because you're using Drupal, it doesn't mean that your website is instantly accessible. So the session today I want to cover kind of what Drupal gives you out of the box in terms of following those accessible best practices and then what your team needs to do to leverage those features and maintain that accessibility so that you can really benefit from it. So I'm going to start. I know many of you are well versed in what accessibility is and you probably some of you have that responsibility on the projects that you're taking on. But just as a quick intro for those of you who are more new to the topic, accessibility matters for a broad range of reasons. It's important to make your website accessible so that the broadest audience possible can access it and can find the content that you're publishing. That's kind of the number one reason is just the inclusive design aspect of accessibility. But at the same time, it's the law that your website is accessible in more and more places. And if it's not the law now, it will likely be soon, depending on the type of website you have and your jurisdiction. And so increasing your accessibility compliance is just a good forward-looking thing to do. And then beyond that, there's also really an alignment between web accessibility and other best practices, like having a website that is better optimized for search engines, is better compatible with an API first approach, and provides a better experience on mobile. And so that being said, for all these reasons, typically a more accessible website is just a better built website and a more robust website and one that's going to better interface with other systems. And so there's a huge number of benefits besides the fact that it might be the law where you are and the fact that you really do want to make sure that your website is inclusive. So sure, this is very important just to define a little bit more what web accessibility is. I think that I see in a lot of RFPs this requirement to make websites 100% accessible. So you can have a website that complies 100% with an accessibility guideline, but 100% accessibility is not really possible. So if we think about the fact that there's such a wide range of abilities that people have, your website's never going to be 100% on every measure. But we do have guidelines in place. And those are those help us prioritize what to work on. And that helps us decide, you know, what what level of accessibility is is necessary for the site to be available to that wide audience. And then another thing that we always hear about when we when we learn about accessibility as assistive technology. And that, you know, building for accessibility often just means, well, it means building with assistive technologies in mind. And that doesn't mean that all of us who care about accessibility are going to be assistive technology experts, because we're probably all not using these tools day to day. Maybe some of us are, but I'm certainly not. And so I rely on the expertise of others, I rely on testing tools, but having some understanding of how assistive technology works, and how those interact with your site can give you a much better instinct for what to do when you're putting your site together. And we'll get into that a little bit with some more specifics later on. And then just before we jump into the Drupal part, one last thing is that there, there's certain aspects of your website that will make your website more accessible. But just because you check every item on that list, it doesn't mean that your website will be user friendly. There is some overlap for sure. But there's actually a lot of subjective decision making involved. And when you're labeling things when you're creating any interface, there's a lot of judgment calls that you have to make to think what you know, what would be the best user pathway here, or what would be the best user experience there. And that applies to accessible design as much as it applies to any other type of design. And so there's not not a way to fully automate the solution. And there's not a way to just use technology to to fix everything in a flash. Every project that I've worked on, there's always been this manual subjective work involved. And so that's part of the challenge and that's part of the fun. So now we can move on a little bit to what role Drupal plays. So I started using Drupal about 13 years ago. And Drupal six had just come out. And accessibility wasn't really on the tips of people's tongues at that time. It's definitely become a topic of more and more interest over the years. But what what I did love about Drupal from the beginning was the fact that Drupal provided a way for us to create really structured content. And that had such clear advantages. So if you can divide your content up into separate building blocks and separate components, there's so much more that you can do with it, you know, you can create better interaction, better consistency, you can get everything translated. You can export and import content. There's just so much functionality that you can build on top of something when when your content is structured. And it turns out that that the fact that Drupal Drupal at its core, it's really all about structured content also means that Drupal lends itself well to building accessible websites. It's the number one reason why you are able to make a Drupal website accessible. And how does that work? It's because Drupal provides us a way to to build structured content and basically to define what what what each content element means. So when when you go and for those of you who have done some Drupal site building, you know that one of the key things you do is you define content types, and you go in and you define other content elements like blocks or paragraphs. And these these are the building blocks of any Drupal site. And just in me doing that definition, you're performing this act of structuring content. And then when that content gets displayed in the in the back end and the in the actual HTML, there's tags around that content, of course, and those tags indicate what the content is all about. And so we call that building, you know, some a semantic website or building semantic markup. And it means that the structure of the HTML really reflects what the content is all about. So even if you don't you're not into HTML, you probably know just a little bit just enough to understand that if you have something like a link on the website, it needs to have an a tag around it. You have a paragraph that has a tag around it. And so those tags are what tell the browser how to display this content. And so if you stripped all of the CSS and JavaScript and styling away, would that content, would you still be able to tell what that content was kind of about just by by looking at the raw HTML? And if you could that it's probably does a pretty good job of being semantic. And so triple by giving us the ability to create structured content by having a theme system, it allows us to really control the output of the website and make sure that it makes sense, both to a browser but also to, you know, other ways of interacting with the site. So it's a bit of a technical explanation, but it kind of basically is tied to Drupal's flexibility. So the fact that it's flexible means we can control the output. And that means that we can fix accessibility problems if they arise. But it also means, and this is this is always a case with with Drupal, is that Drupal's flexibility is the reason that we love to use it. But it also gives us a huge amount of responsibility. Because with Drupal, you can, you can fix accessibility problems. You have the tools to do it. But you also have the tools to cause accessibility issues, like to to cause those problems. And the fact that Drupal is flexible means it's very easy to make something that's not accessible. And I'll give you some examples. So with Drupal, you could go in and just edit one single template. And you could remove a heading tag. So imagine you go into the main template that controls every page on your Drupal site. And you just say, Oh, I don't want the H1 here. It's not looking the way I want it to. I'm just going to take that out and replace it with a div tag. And suddenly, you've made it harder for users to identify the purpose of your content. Now, it's kind of extreme case to remove the H1 on every page of your site and someone would probably notice. But it, it's a minor change to remove, you know, a heading two in a little block over here. And it's it's a minor change to maybe change something from a link to another kind of tag that that doesn't have that same meaning. And by making those little changes, you're making your site less, less structured in the same way, less semantic, like we say, like it doesn't it doesn't have this meaning built into the to the HTML. So it's very easy to make these changes. And then and in another case, I mean, depending on what you're doing, the more functionality that you add kind of the more responsibility that you have. So I know I've seen sites, and I've interacted with sites as a user where there is a form on a page. And when I go to that page, the focus is immediately set to that form because someone really wants me to fill that form in. And a little tweak like that a little change, which is very easy to do in JavaScript, and it's easy to do in Drupal, that can cause screen readers to jump directly to that form, and then they lose the context of the content of the rest of the page. So that's the type of thing that we can do easily with Drupal to compromise accessibility. So we have to keep aware of those things. So some accessibility features out of the box, I don't want to I don't want to be negative. I want to I want to go through first, all of the things that we get by default, the things that Drupal takes care of us. So if you were to just install a Drupal website today, what do you get? What, what do we get done for us kind of for free? So there's quite a few things related again to the structuring of the content. And there's also some things related to the content editing interface. And then just the general flexibility, the fact that that you have a templating system. So I'm going to go through a few of these features in a bit more detail. So the first thing that I I found really interesting, I was looking into, you know, trying to increase my knowledge of assistive technologies. And I was looking into screen reader use, just to try and learn a bit more. And I found this really interesting survey. And I'm sorry the link here is, is cut off in the visual. I'm going to fix that. And we'll send you the slides after the presentation. But there's this, there's the results of this survey that tell us a little bit about what screen reader users find use usable or not usable about websites. And there's this question on that survey that says, you know, when you're trying to find information on a lengthy web page, what, what method do you use to find it? So if we are looking at that page visually, we probably subconsciously do a mix of skimming down the page. And maybe we look out for headings and links. And it turns out that that's exactly what screen reader users do as well. There's a rotor tool that comes with screen readers that allows you to see or to for the screen reader to read out what are all the headings on that page or what are all the links or what are all the landmarks. And headings are the number one things that users find helpful to jump down to the section of the page that they actually are interested in. And so that's kind of a basic finding, but it can really guide our work as web developers. And it means that it's really easy. It's really important to make it easy to navigate to content on the page. And, and that is something that Drupal does well out of the box. So if we look at the default markup for content, and the building blocks of Drupal tend to be things like nodes, which are pieces or pages of content blocks, which are elements that appear on the page, maybe not the primary content of the page, we have menus, we have lists. And so all of, or most of these elements include headings, the nodes, the blocks, the menus out of the box are going to include headings. And, and that's a great help just to begin with. And those headings might not be visible if you're looking at the page. So for example, for menus by default, even if you turn the menu title off visibly, it'll still be there in the markup, it'll still be accessible. The content also follows a natural order. And that's a small thing. But basically, it's to say that the main content of the page appears before other, other sections. And the fact that there is a content model means that content tends to be predictable. So if you break up your content into content types, and every event has roughly the same markup around it, that means that it's much easier to for for somebody looking at a series of events to know what to predict in terms of the content. So they're always expecting the fields to appear in the same order, it will be easier for them to understand the content. And that goes for whatever way you're using to access that content. There's also in Drupal a built in skip to content link, which is a small thing, but it is important. And that means that on every page, there's a place that's considered the beginning of the main content to the page. And you as a developer might want to, or even as a designer, maybe you want to indicate this, where on the page does the actual content begin? Where, where does the user want to start reading that really pertinent information? That's the main thrust of that page. And you can make sure that that anchor link goes in the right place. But by default, it's there. And by default, it's at the top of that content region that you will find in Drupal. So if you are just to install a Drupal site and these screenshots I have here, these show what the rotor in a screen reader actually lists out and reads out for headings and links, for example. And these examples are from the Umami install profile. So Umami is a tool out of the box that you have with Drupal to kind of demo Drupal functionality. And a lot of work has been put into making it accessible. And so you can kind of use it to to look at things and see, okay, what does an accessible Drupal site look like? And you can get ideas that way. But this is just to show that you do have headings for many elements on the page by default. And then you also have the ability to skip to links. And there's been work done to make sure that you can customize what those links are. Because as you might know, if you if you have some accessibility knowledge, it's important for your links to really explain the purpose of what you're linking to. So you don't want to just have 10 read more links on a page. That would be pretty unhelpful. You want to have links that are much more specific. So with Drupal we can produce that. So that's kind of like getting to the content on the page that you're interested in. That's a really key feature. Another key feature is that when content is displayed like a more specific element that it's displayed using the right HTML. And that's important because the HTML is going to determine how well it determines how browsers display elements. Sometimes we override that with CSS. But also it also dictates how an assistive technology will interpret the purpose of that element. And and also as a third thing, it also changes how we can access and operate those elements if they are interactive and we'll get to more interactive features in a second. So by default, Drupal attempts to just use the right element for the right thing. But this is partly the responsibility of the site builder when you're creating new types of content to use the field types that make sense for the content that you have. And that's going to make sure that Drupal in turn uses a default tag that makes sense in the template layer and the theme layer. So when you're doing site building, you're actually doing quite a bit of work building markup. And the markup is assembled behind the scenes. You might not be thinking of it that way all the time. But the choices that you make are going to influence that markup. So that's something to be aware of. But you're taking advantage of work that's been done to map those field types to tags that, that that makes sense. And something just to keep in mind. So this is a little diagram here that shows that HTML is used to is interpreted by browsers to display content, right? We can take a page of HTML. We open it in a browser and we see lists that look like lists and headings that look like headings. And at the same time, what you might not be aware of or you might not be thinking of all the time is the fact that that HTML is also used to build an accessibility tree. And that accessibility tree is then used by screen readers to interpret the page and decide what to read out. And so it's important that your HTML is correct because the browser needs to interpret it. But it's also important that it's correct so that the assistive technology knows how to read it out. And even though a browse in a browser, you might be able to make a div look just like a heading in in an accessibility tree. You're not using that kind of CSS to alter how things are interpreted. So you need to feed it the right HTML tag the first time. And so Drupal helps us with this. It helps us with the defaults. So we have something good to start with. So then there's alternate ways that we probably want to give users often to consume media. So this is one of media is one of the things where we need to put on our accessibility hats and think, OK, how is this content going to be interpreted? So obviously we need to provide alternate ways to see images, but to have the image purposely read out. And then for things like audio and video, we need to provide transcripts and captions. And so one thing that Drupal does out of the box, which is kind of a baseline thing, is it provides an alternative text field for every single image. But that field, it's not, I mean, it's always there. Like you can always turn it on, but you can configure it. And that's really the important part. Because not every single image has a purpose as content. Some images are more decorative and there's actually no purpose to the image other than to kind of create a feeling. And the alternative text that you would use for such an image might be identical to the title of the element that is also being displayed and read out by Springeater. And so it's really important to think through when you're planning your content, you know, what images actually need alternative text. And if they need it, it should be required. And if they don't need it, it should be removed and it should be handled through the markup. And so what Drupal does for us, it doesn't figure this out for us. It's not able to figure out for this content type should this image alternative text be there or not. But it does give us the tools to customize that to customize each image field. And that's going to help us. So it's going to mean that we can build that workflow and make sure that those alternative texts are there when they need to be there. And then for other kinds of media. So this is maybe less, you might not think of this as out of the box, but for every other media element, you can add fields to it. So it is up to you, but you could add, for example, a transcript field to audio files. So every audio file on your site has to have a transcript field. And that field could be a link to a transcript. It could be an upload document. You know, you can you can decide what makes sense for your content. But the fact that media or fieldable means that you can add this extra level of context for users is other way for users to interpret media elements. So a couple more things. So Drupal is full of, you know, bits of functionality that you're going to add. You're going to add forms to your Drupal website. You're going to add maybe a customized menu and then maybe other elements like like search interfaces that are customized or customized calendars. And so there's so much interaction that you're building into a website as it grows. And the nice thing about Drupal is that it has a feature which has been in Drupal since I started using Drupal. So practically from the beginning days, I think it's since Drupal 5 and or maybe 4.6 or somebody's going to tell me in the chat that I'm wrong. Since very early days it's had this feature called the form API. So that means that every form that you're displaying in Drupal that you're using Drupal to build. So whether you use custom code and use the form API or whether it's coming from a module and that module uses the form API. All these forms that you see in Drupal they typically use the form API. And what does that mean? It means that forms are really displayed in a consistent way. So, you know, when you're developing websites from scratch, you have to come up with this form markup all the time like, oh, am I going to make a text field? Let me make this text field tag and make sure I add the right attributes. But with Drupal you're not using that. You're using an API to build your form elements. And the advantage of that is that Drupal has a way of formatting each form element that is standardized. And so some work has been put into making sure that those form elements are accessible. And if you come across something where you don't think it is or, you know, you're not happy with how some form elements display, like you come across some corner case or you're coming up with your own custom form elements, it's still, if you're using the form API, you're still doing everything in a standardized way. So if you fix a little piece of the puzzle, you're fixing it across the board. And so just by using that and by building forms in Drupal, we're making sure that our forms are standardized and that we have things like labels for each form element. And you'll notice this when you tab through a form in Drupal that you can tab through everything and the order makes sense. You also have required form fields that are indicated, which is kind of a baseline thing, but Drupal does that for us. And then there's also a module that comes with Drupal Core called inline form errors. So if you have longer complex forms and there's errors appearing, it adds an indication inline so that the error appears in proximity to the form element, which is also helpful. And beyond forms, of course, there's other other elements in Drupal. A common thing you interact with is a menu. So menus in Drupal are keyboard-operable by default. And so the last little thing I'm going to cover, and this may be not, maybe not a little thing, is that the content-authoring experience in Drupal is also accessible. And if you're using Drupal out of the box, you can use a new theme, which you might not have tried before. This is available in Drupal 9. And it's called the Claro theme. It's also available in the last version of Drupal 8, but you should all be moving to Drupal 9 now, so hopefully you have access to that. And Claro provides increased accessibility for content editors. So just out of the box, the interface in the back end, when you're editing content, the way that the elements appear there, that has been optimized recently. So it looks more modern, but it's also more accessible just in terms of the contrast of text and whatnot. Like a great deal of work has been put into this. And another thing you'll notice on the back end is that there's, of course, a lot of drag and drop that you can do. And drag and drop tools are like the thing that everybody loves about content management systems. But the drag and drop tools on Drupal, it's not the only way to update your content. So if you ever see, like, in the back end of Drupal, you want to change the order of a menu, of course you can drag and drop with your mouse, but you can also use your keyboard to change the order of elements. There's this thing called row weights that you just have to toggle on and off. And I love this because I've had to update a Drupal website before when I was on a bus and I was just using my phone. And this makes that possible. But it also means that you can operate forms with a keyboard and you can operate everything that way, which is excellent. It's not, I don't think it's common in content management systems. And then just a couple other little examples. So of course a simple form for adding a piece of content is maybe we take it for granted that that should be accessible. But there's a lot of other interfaces in Drupal, things like the layout builder, things like the media library and care has also been taken to make these interfaces to make these interfaces accessible and that was a key goal in developing these. So that's all well and good. There's lots of out of the box features that you get. So the first day that you're working on your new Drupal site, you just installed Drupal, you're taking, you know, you have all these accessibility features and you're feeling good. You run your accessibility test and it's basically 100% good to go. But then as you work away at your site, of course there's this responsibility to keep that level of accessibility and to continue leveraging all these features. So how do we leverage these features as we continue to customize our Drupal websites? So the first answer I give is maybe a sneaky answer like well if you want to keep Drupal accessible just keep using Drupal and don't customize so much. And that's, you know, easier said than done. But it's true that a lot of times when we are building Drupal websites we're making decisions about should we use this, you know, should we use the default kind of content type structure in Drupal or should we add in a module to do something? Or should we add in a kind of third party tool to augment what Drupal does? Or should we build something totally custom? And the more totally custom you have and the more contributed modules you have, probably the more accessibility issues you're going to be introducing because those things don't tend to have the same test coverage. You know, most people developing contributed modules, you know, they might think about accessibility but it might not be their number one concern and they might ship something that produces markup that's not accessible. And the same is true of your custom code that you're writing. So the theme that you create, any modules that are producing output, like if you have a module to display podcasts on your site and it looks really cool, that's great. But is that template file that it includes to display the little podcast player? Is that going to be accessible as well? Well that's something that you have the responsibility to test. So when we think about how Drupal websites are constructed, Drupal Core is this huge part, but there's all these other pieces that you're building on top and that tends to be where more issues are going to come in because you're adding custom code and that all needs to be reviewed. And I would say your contributed code, you should be reviewing as well. You can check for accessibility issues in modules that you're downloading to see if things have been flagged or if the module developers made a commitment to make it accessible. And so many modules have gone through that testing and that's fantastic, but it's not guaranteed. So that's sort of an easy thing to say and like I said there's just basically a lot of testing involved as you add custom pieces. But let me go through some more specific advice about how to keep that level of compliance up as you are customizing your Drupal site. So my first piece of advice, and this one I feel like is really achievable, this is something that you can think about when you are creating those really interesting landing pages and really engaging content on your site. So pretty much every website these days, you know, the marketing team wants to be able to produce campaign pages. The home page has to be super engaging and interesting and often that means that our great ideas about structured content don't apply across the board. So we might have some pages that don't follow so much the template of a content type, but really define their own structure like oh there's going to be this beautiful hero section at the top of the page and then there's going to be this call caption and then a video and then an image. And so we don't have that that structure that we get with more consistent content types like events or articles or recipes. And so for these types of pages what we're often doing is defining block types or paragraph types that create these content components. So even if you're not familiar with all the Drupal terminology, you're probably familiar with the idea of building content components that you use to create a page. And so when you're doing this, validating the markup and design used for each component is going to be really key. And if you're giving content editors that as a building block like here's this piece of the puzzle that has a nice title that where the heading is defined, the heading level has been thought about, and then the fields get displayed in a certain way. If you really streamline the creation of these pieces and you break it down into separate fields, you're going to be able to then go and define the HTML and validate that the markup is semantic. And that's really going to help you achieve your accessibility goals. One other piece of advice is if you can limit the amount of custom HTML that editors are using and the amount of design flexibility that they have, that's going to be great. So an example is if you can see the screenshot on my page, there's a picture of a phone with a blue background and white text on it, and there is enough contrast. This is a government of Quebec website. There's definitely enough contrast between those two colors. But if you were to allow content editor to pick the background color because you're trying to make it more flexible, then that's going to for sure at some point produce something not accessible because there won't be enough contrast. But if instead you give the author a couple options like okay you can have a light on dark background or a dark on light background, and both options produce something accessible, that's a much better result. So limiting the options that you have with these content components, but still making them flexible enough to meet the content editor needs, that's probably the sweet spot. And that's really the key message here as well, like balancing flexibility with consistency is the turkey part. So just another bit of advice here, often we receive designs for a website, maybe we're not the designer, maybe you are the designer, so that's great too. And at some point though you're going to think about how you're going to implement these various mockups. And one thing I would always think about is taking a look at what the header or what that first content block appears like on every one of those mockups or wireframes. And think about the fact that that's the first thing that a user sees on the page if they're looking at the browser. And it's the first thing that a screen reader user is going to interpret as well. And so is that content consistent enough that if I'm browsing through the site that I'll be able to understand like what's the page about? Is it consistent enough that I'm going to be able to understand the content? Or is it going to be completely different on every page? So if you build the kind of, if you use a layout builder tool or if you're using paragraphs and you're allowing content editors to change what that first element is on every single page, that that creates a certain inconsistency that might be really hard to use for all users. And then the last bit of advice here is around permission. So Drupal has a very flexible permission system which allows you to restrict what different types of users can do. And you can actually use that as a tool to limit the amount of flexibility so that users aren't able to add unnecessary markup. And that might take many different forms. You might think about your text formats. You might think about the WYSIWYG settings that you have or you might just think about whether users can move blocks up and down the page or what types of block types and paragraph types your content creators have access to. There's lots of ways to interpret this but basically the more flexibility you give, the more chance there is for the markup to become not semantic and not accessible. And then one other thing in terms of your development plan when you're working on building out your site, if you are on the development team or you're managing the development team, of course you need to pay special attention to everything that's interactive. And I already mentioned that the form API is going to help you a lot with custom forms but there's all kinds of other elements that you might be building like modals or sliders or search interfaces and these might be introducing patterns that are harder to use. And so you have to think about the fact that you have to be able to operate all of these elements with a keyboard and you have to be able to tab through them and as you add these types of customization you need to set aside the time to do the testing involved. And one specific thing about doing this in Drupal, of course this is a challenge, this would be a challenge with any web development project but with Drupal when you're developing something more interactive, if the actual DOM of the page is changing like if the, if what content is being displayed on the page changes as the user is interacting with the page, you can use this JavaScript method Drupal.announce that actually gives the screen reader a cue that something has changed and it can do things like you want to give more instruction and to explain what's happening and you can also perhaps change the focus or at least think about where the focus is on the page. So this requires definitely custom testing if you're doing custom development so that's just something to plan for. And then I actually, I kind of already talked through this but just provide, just thinking about encouraging editors to do the right thing, you know we have so many tools in Drupal to customize the backend of our website, we can add help text, we can add good labels to fields, we can think about the permissions we're giving to users and content creators have so much to think about in this slide I'm just showing all the different responsibilities of content editors, you know finding and publishing, going through a publishing workflow, validating their content and then actually expressing an idea. You know they have so many things to handle actually and accessibility is one of those responsibilities so we need to really guide them and help them do that work. We can't just kind of give them the platform and hope for the best. So some specific modules I would recommend considering because Drupal out of the boxes is great but as soon as you start digging into things you might want to consider adding additional modules to help you make the interface more accessible. So I've just listed a few things here, text resize, external link, these are going to help with specific elements, external link is because if a link doesn't just do the simple thing of going to another page with the link with the to another page that has that purpose that the link text describes. If your links are doing anything else you know you have to give some cues to the user so external link helps you do that and can help you do that for all users actually. There's a really useful module block area landmark roles and this is going to help you fill those gaps when semantic markup isn't enough and you actually have to add some extra instructions for screen readers. There's different things for CK editor, I just put one example here the CK editor abbreviation module, CK editor is the WYSIWYG editor for Drupal so it's very customizable. And then a couple tools for accessibility testing, I'm going to give a shout out here to site improve because you know they have a platform that helps you keep content consistency and content quality and of course it will check your website for accessibility and they'll do that in an automated way but the module that it has for Drupal is great because it'll allow you to preview whether the content is going to be accessible before you publish it. So site improves the paid service so it's a third party thing but the integration with Drupal is really nice. And then the last module I'll just mention is called Editorially and this I believe was developed by the team at Princeton and I think I have a little video of it because this is another testing tool that is great for content editors because it just highlights accessibility issues with the content. Like you can tell it what the content part of the page is and then it's just going to test that and it allows content editors to kind of review those aspects of the page that might be an issue where an error might be there it'll flag errors and it'll also flag things that have to be checked manually. So that's a nice additional tool and that's Editorially like Editoria 11Y if you're just listening to this then that will help you find it later and then I have I will send out this slide later but there's also a link here to some additional modules you might think about. So just a few challenges because not everything is easy with Drupal. You know not everything is just going to be given to you and as I've kind of indicated the more customization the more complexity you have of course the more testing and the more work you have to do to make your website accessible. So some specific challenges that I would watch for and these if you're a project manager this is where you listen up and think okay this is where we need to just have more time or more expertise on our team for doing these things. So the first challenge I see is really in the content. So Drupal is great for building these websites with tons of content and that means that that means that you probably have a lot of content to deal with and maybe that content has been written over the years and has been edited maybe in another platform maybe in Drupal and so if you're migrating that content to Drupal or you're just dealing with it in the context of Drupal but it's been edited using who knows what tool you probably have a lot of accessibility issues just in the content itself. So I'm just talking about like the body text inside your article content that has HTML here and there and often this is a real challenge for projects. It's a challenge to take that content to make sure that it's brought up to line with your standards and so something you can do there is you can think about I'll give you a couple things you can think about first of all if you're doing a migration process so some of you might be like we're in Drupal 7 we're moving to Drupal 9 or maybe you're revamping your website or maybe you're moving from a completely different platform to Drupal so if you're going through that kind of content migration planning that's a great time to look at your content look at some representative examples of content and identify what are some issues within that kind of HTML content where there's accessibility problems and what are the patterns so there are patterns of using a tag that's incorrect that should be replaced or using an attribute that shouldn't be used or using a combination of tags that doesn't really make sense there might be an opportunity in the migration process to fix things because Drupal's migration framework is really flexible so you can say well pull in all this HTML but replace these tags with those or look for these patterns or whatever it is you might be able to do that the other thing that you can do is you can systematically go through your content and that doesn't have to be done after migration it could be done before so you can actually start improving the accessibility of those content pieces that you know you're going to be migrating over so that can be of help and then you can also use accessibility testing tools that are going to really hone on that content of the page and allow content editors to review that specifically another thing that is a real challenge is streamlining the content editing experience and giving content editors like empowering them to make accessible content but also training them on what their responsibility is because you can limit what HTML they can add and you can make sure that the standard output is semantic but you still end up with some choices that they're making like you know what what kind of image do I upload and is there enough contrast or is this the right alternative text or what kind of options do I choose from the WYSIWYG editor when I'm creating this content and so streamlining that content editing experience can help prompt them to make the right decisions just you know taking the time to do the training as part of content entry but also putting in cues into the interface to help them out Building interactive experiences is just a hard thing like just you know if you're doing things like creating a complex map an advanced search interface kind of a checkout booking system anything like that where there's a lot of interactivity just take the extra time to plan like a real accessibility audit and don't don't just assume everything's going to work out I've talked to my the front-end developers that I work with I used to be a front-end developer I don't do that so much anymore but um from from what I understand missing area labels or inconsistent landmarks these are real challenges when when building a website and Drupal does something to make sure that landmarks are labeled but then if you start to kind of customize things it might conflict and so just to take the time to learn about those things build that expertise on your team and and test it and the good thing about those things is it tends to be something where you can fix it once and then it works so just a few last bits of advice I'll leave you with to set up your team for success this is a quote from my colleague for that who's our UI engineer so he does this handoff between design and development and he takes a lot of responsibility for the accessibility solutions that we put together and so he says you know you can follow a set of roles but really developers have to know how to prioritize accessibility issues and that's a key skill now it's not it's not something that can just be one person's job it's kind of a a skill that the whole team needs to have and there are lots of automated testing tools that you can use I mentioned acts is a great one that you can use for automated testing wave is a great tool and then site improve also has that capability but testing is something you have to do actually throughout the entire process of your project so content planning I mentioned some things you can do before you start to kind of do a content assessment design of course you have to be planning the accessibility in terms of the color palette the typographical choices all the design elements in terms of development there's work that should be done before the QA to actually think about okay we're building this kind of feature what implications does that have and then in the QA you can have some dedicated time to doing maybe a more thorough audit and content entry there's training that has to happen so accessibility isn't something that you just can think about oh well that's just one step at the end of the process it's really more of something that has to come through throughout the process and that's actually true of like lots of things like inclusive design and security and other things so accessibility should be one of those priorities that you're just keeping an eye on all the time and then one thing I'll just leave you with so Drupal you know Drupal out of the box great for accessibility as you start to customize it things start to stray and you have to take time but Drupal also comes Drupal Core comes with three themes and a great deal of energy has been put into making these accessible and so you can find great examples of accessible interfaces built with Drupal right in your Drupal Core install so if you have like a sandbox the cheese for Drupal try installing it with the umami install profile that comes with lots of content content types configuration and you can see what the interfaces there are like work has been done to test for accessibility and time has been put into thinking through through those interface elements the new Olivero theme which is the new default theme for Drupal Drupal 9 you can look at that and you can also look at the Clara theme which is the backend theme so these three interfaces they're built in Drupal so you can see how they're put together a little bit if you dig in and they're accessible as as much as can be of course there's probably some someone will put in the chat well I found this not accessible thing so there's of course always work to do but for the most part those are accessible so I'll send you the slides for this we have a guide and I hope we have I'm going to take time to look at the Q&A now yeah so the first question do I understand correctly that Drupal is accessible out of the box after it's installed so yes it's accessible out of the box after it's installed but like as soon as you add something to it it could be not accessible so if you're if you're doing that kind of running your testing tool right away you'll probably see it's 100% but you know things things come up even if you just see that kind of accessibility tool you might find that there's some manual testing that you have to do so it's asking you to decide how accessible this or that is but yes out of the box second question has anyone tested Drupal's own accessibility so I think here the question is more about Drupal's accessibility in terms of the backend and that is one of the big differentiators so other you know when the layout builder tool was being developed for Drupal there was research being done into how can you build a tool that allows users to drag and drop content components into a layout how do you make sure that that's operable with a keyboard and you know that it actually is is a semantic in the markup that it provides and it was really hard to find good examples but the work was done to make those accessible can you say something about the issue in making uploaded PDFs accessible so this is actually something that came up in that survey that I shared with you earlier the one where it said that screen reader users really care about headings so it turns out that inaccessible PDFs is actually one of those big pain points for for screen reader users and it's one of the most frustrating things about about the digital experience so basically taking the time to make your PDFs accessible or putting that content of web content is is a big win so if you have other questions feel free to follow up we'll send it we'll send an email and you can reply to that email with any other questions we do have an accessibility training coming up June 28th to 30th and then it will run it again in December so if you want some more hands-on learning about all this stuff feel free to sign up for those as our paid trainings and we'll send more information about that out in a link to you and all our trainings are available at EvolvingWeb.ca and feel free to contact me my email address is here susannaevolvingweb.ca and thank you so much all for coming to this webinar I really appreciate the interest and enthusiasm for this super important topic and great to have you all attending amazing thank you so much Susan thank you everyone and happy global accessibility Awareness Day and we will send an email with the recordings and the slides and the transcript of the captions and more information thank you very much thanks everyone