 Thank you for making it this long to the last session and we want to present to you checking under the hood, auditing your website for a smooth ride. So I want to introduce myself. My name is Sean Dietrich. I am a senior operations architect at Canopy Studios and I'm Amy June Heinlein. That's the title camel case for programmers out there and I'm the community ambassador for Canopy so I just set up the community and advocate open source software. So why audit your site right? There are lots of reasons to audit your site. One reason could be it's slow to load. Sites pages take more than three seconds to load that can be problematic. Your site might not be responsive anymore. The site doesn't display well on tablets and phones and that kind of thing. You may be having content flows. So when you try to update content you know that you're having issues and difficulties and problems and it can be frustrating. Maybe your users are confused. Your site visitors can't find what they need. This can lead to lower conversion rates and possible negative feedback on the site. The site has, well, troubles using your site. So visitors get agitated when they can't use your site with assistive technology. So that's an accessibility issue. And maybe you're having a disastrous experience, right? There's bugs and there's defects in your site that keeps the site crashing and it's impossible to keep it current. Maybe you haven't made changes to your site in a while. There's nothing new for visitors to look at. And maybe your site looks antiquated and outdated. And then maybe you haven't made the switchover to HTTPS so your site could be insecure, causing security warnings. And maybe your site is hacked, right? You have problems with the content and the code being compromised and so it may not be secure any longer. Is it really that important for us and our product owners to address these issues? Of course it is, right? You know? A website that isn't working optimally can affect your bottom line. Right. And as time passes, websites get outdated and even poorly designed websites can have a negative impact. It's estimated that 39% of people stop engaging with the website if the content for layout is unattractive or unusable. Therefore, it can damage your credibility. Additionally, it's estimated that 1.14 billion users are using tablet and even almost, I would say, even double, even triple that now are using phones to access sites. So it can make you seem out of touch and make it seem as though you are not trying to keep up with technology. And then some of those negative impacts could also cost you customers. Unhappy customers end up looking for other places to go. 39% of people will stop engaging with your website if images won't load or it takes forever for the page to load. So now we jump into, at this point, we jump into an audit. You decide as a product owner or as a site container that you want to do some sort of audit and understanding the different aspects of it. First, we look at the fundamentals of it. To really see an optimal website, we look at both the code side and understanding a really solid code base along with a technical foundation. With that, you have to couple that with smart user experience. Those together is what brings you a really optimal website health and great website for people to use. At Canopy, we specifically like to make data-driven decisions. So we dig into things such as actual site usage, what features work, what doesn't work. Does the site meet the you expect practices? And then we provide some recommendations. Some of the ways we collect data are surveys, heat maps, analytics, and as well as just speaking with users. The next aspect is the technical audit. We take a look at things. We took at the technical side. We strive to know how everything works from the most simplest thing to the most complex feature of the site. This in turn makes it easier for supporting the client and as part of that we also look at hosting and performance issues confirming that the client is getting the best features for what they're paying for. And then we provide the feedback to the client in ways to be efficient, effective, and easy for them to understand. Most of our clients might not be a technical and so being able to give those digestible pieces of information is really important. One of the things we also strive to do is an accessibility audit. Understanding exactly who the users are on the site and can the site effectively communicate with those users. So first we're running an initial scan with tools to check basic structure. We are trying to identify top pages, top traffic pages using analytics, and then running additional tests on those to make sure we are tackling those first. Additionally we're using keyboards and we're using screen readers to make sure everything is optimal for the person. And then periodically we check in and we review accessibility because as the site is updating with content we want to make sure that everything is still up to date and everything is working optimally for everybody. So now we've gone through those kind of aspects of the audits. What do we do exactly? So when doing the technical side of things we do a preliminary setup. These usually include items as looking at the status report page in Drupal, looking at log messages, looking at top page not founds, and then additionally with some combination of some contributed modules such as the security review module, the hack module, and even unused modules module. Say that ten times fast. It gives us things as where there's possible security holes. It lets us know if any of the modules, the contributed modules, or even at core has been modified in any way. And then lastly it calls attention to any modules that might be in the code base that aren't being used. Things that you know we might have enabled and then disabled or sometimes even if we've enabled part of a module and we're not even using it. After that we examine the theme. From there we strive to really figure out how the site is, what the looking field looks like. Are we, we're checking file structures for template files, we're making sure that what is the site using? Is it using flat CSS files? Is it using SAS or some sort? And then from there we also are making sure JavaScript best practices are being used. And then finally one of the big ones, I actually shouldn't say finally because there's a few after this, but one of the big ones is we're checking the site for SEO. Most businesses rely on Google to get their message out there. Most organizations also rely on Google. So checking how you rank within Google is a big thing. So we're reviewing simple SEO basic things just out of the gate. Do they have a sitemap? Has that sitemap been uploaded to Google even something like search console? And if it hasn't given that recommendation that setting up for an account and using that as a way to see if Google comes up with some issues. Additionally there's some other help on modules which we've listed that usually we recommend having installed because they give extra functionality to a content editor, to a site user, to someone who's adding in, you know, adding an update in content frequently. And then because Google is starting to take an approach where mobile first is becoming a big thing, we also ask them, we do a review on Google PageSpeed to see what their ranking is. Google is now starting to take the mobile side of PageSpeed into effect when it starts ranking you and therefore sites that have a lower number can start being impacted negatively. And of course, like most people, we review their custom code. Sometimes custom code is necessary to build things. We, you know, Google has a lot of wonderful things but sometimes out of the box and with contributing modules we can't achieve some of the ends. We need, so custom code is needed. And when it is needed, we like to look and see how is that written. We like to know what it's actually being, what it's being used for. And then even so, if there's multiple modules, are all of those modules enabled and are the ones that are not enabled necessary. And then we try to look and make any recommendations about if any of that functionality can now be moved over to a contributed module. The biggest thing is we look to make sure there's documentation. There's, when you take over something, someone else's work, someone else's baby, as we'll call it sometimes. Being able to understand what the function and what the purpose of that is super important. So documentation is always a key thing we try to strive with our customers. And then we access the code quality because not everything, you know, as developers we sometimes write really quickly. Sometimes we're not always for the most efficient. We try to make sure that everything is written easy enough for people to understand regardless if it's the original developer who wrote it or a new developer down the road. So when doing that, we review custom modules through a PHP code sniffer. One of the great things is that Drupal has some code sniffing standards, coding standards that we can run through and checking to make sure that the same thing we do for our custom modules are the same things that we do for Drupal.org and the contributed modules were also doing for our custom modules. And additionally, one of the new things recently for Drupal 8, we're running modules through Drupal check to see what where they rank as part of upgrading to Drupal 9. And the biggest part of that is that as Drupal 9 gets closer and closer, we want to see how much more extra work we need to do. Is there dependencies? Is there dependency injection that's needed? Are there outdated or deprecated code that we need to replace? And that's a big one that we've recently started introducing. We check code for comments. And then we review code for possible improvement. So that seems to be a constant theme we always do is seeing where there can always be room for improvement. The biggest thing for not just code or technical or or the theming, we just check to see if there's documentation. How do we install the site locally? How do we set up the theme locally? How do we? Where's the site deployed at? Is there documentation about who work on the project? Is there? I mean, I can go on about different types of it, but those are some of the biggest things you know what tools and dependencies are needed to properly get that set up. The next thing we try to test your accessibility, test the accessibility on the site to figure out where some of the holes, you know, they're depending on what the organization is, the organization has different sets of standards. In the US, we're a lot of our government and our nonprofits as well are really strict. And I believe they require double A. A lot of the schools and universities, they require double A. So making sure that we're constantly doing those is important for some of our organizations. They may not even care necessarily about it, which is not necessarily a great thing, but they may have less of an importance for it. And lastly, we push the performance of the site. We try to figure out where their bottlenecks in both code, in infrastructure on in every possible way. So if we're caching, making sure we're caching for a long time, are we using CDNs? Are we using something like Redis or Memcache? Are we using something like Varnish for some front end caching? So we're purely looking at from a performance side of you, what can we do to make the site load? Because there's a huge difference between taking a site that loads in six seconds to dropping it down to something that loads in 50 milliseconds, which doing things like just caching can be huge improvements for. Okay, so I'm a hospice nurse by trade and technology is sort of my third or fourth career. So accessibility is something that I have a passion for because I have experienced people not being able to access the same information as more able bodied people. So with accessibility, it's important to make sure that our assistive technology works on our site. And that can include screen readers, magnification apps on your on your phone, tablet and computer. It can be alternative input devices like head pointers or motion tracking, single switch devices, and also includes keyboard accessibility and alternative speech input devices. So those are all things that can be qualified as assistive technology. So why do we want to design for accessibility? Well, first of all, it's the law, right? So that's one good reason. Another reason is it's essential for developers and organizations that want to create high quality websites and web tools. We don't want to exclude people from using our products and services. We want to make sure that everyone has equal access to the information. According to the CDC, 26% of people living in the United States, sorry, I'm a United States person, I should have thought about that when I put in the stat, but it's pretty global that for North America, 26% of people live with a disability. That's one in four. That's 61 million people in the United States. So remember that there's all kinds of disabilities. There's situational disabilities, there's temporary disabilities, there's unseen disabilities. So basically when you when you create your site and you're doing an audit, you want to make sure that it's easy to see so you accommodate people's visual needs. It's easy to see here, so you accommodate their auditory needs. It's easy to interact with, so you accommodate their motor needs. And then you also want to make it easy to understand, so you accommodate cognitive needs. I'm going to go through a couple or a few little items just to sort of make a checklist of what you might want to test for it when you're auditing your site for accessibility. Users with mobility issues, including repetitive stress injuries, may not be able to use your mouse or truck pad. So can keyboard users navigate your site? Can we tab through the site and get to the same content in the same way someone who uses a mouse can do? If you enter a component or a modal and things like that, can you get out of that? Can you escape that or are there keyboard traps on your site? If you can enter it, you should be able to exit it in the same manner. Does the page have sufficient means to skip features in an application? Is there a skip to main content link at the top so people don't have to navigate through your headers or menus? Pages with a lot of content should be broken up because even as able-bodied people, we don't read anymore with scan, so content should be broken into smaller chunks. Do all the elements on the page receive focus when you're using a keyboard? Meaning, can they tell where they are on the page? And does that keyboard focus have enough contrast where you can see where you are on the page? So all menus and levels of a site should be accessible through your keyboard. You don't want to leave out buttons or action items that only amount. Well, you want to leave out action items that only a mouse can use for functionality. So you want to make sure that there's different ways that you can input those buttons. Do all of your images contain alt text? Are there any images of text? Because remember, you know, if it's a screen reader, a screen reader can't read an image. You know, so if you have like a banner on your page with a date, make sure that there's another way to access that information instead of just visually. Do any of your images contain alt text? Are there images of text? If you turn off the CSS on your page, can you read through the site without getting lost? This is not only for screen readers, but it can be for people who have images turned off on their site for maybe sensory overload or places that don't have high-speed internet and it takes a long time for images to load. And of course not just images need alt text. You have icons you have or not all images need alt text. And this is sort of one of those things like it's a rule for images, but icons and things have different rules and decorative images have different rules that you don't necessarily need alt text. But if it enhances your user's experience and helps them understand your content, alt text should be there. Not just because it's not, you know, a law doesn't mean it shouldn't be there. Do you use tables for more than tabular data? Remember, you know, back in the day we all did our websites and tables. Well, we don't, we shouldn't do that anymore. We need to make sure that our tables have headers and rows and columns that explain how the cells correspond with each other. So we want to make sure that all that data can be read and navigated through and skipped as well. So does your screen reader read all the content as presented on the screen? So this includes modals, it includes dialogues, it includes overlays, it can include pop-ups, light boxes, slide shows, error messages, page updates. We want to be sure that if the stuff pops up and alerts you on the page that the screen, a person using a screen reader has access to that information as well. So I'm getting older and as we get older, our eyesight deteriorates and I am a big fan of magnification in Zoom. So can your text be resized without obscuring your content? Can you get to it without having to scroll horizontally and vertically too? That's important because that can be hard to do. You have to do both of those navigations. Are your landmark regions properly defined between ARIA and HTML5? So I don't know how many of you have heard it, but in the accessibility community we have this, you know, the first rule of ARIA is don't use ARIA because HTML5 is semantic now and so whenever you can use that semantic markup, use it and then do the ARIA for the things that that are beyond that. So content is just as important as code. You can have a website that the code is completely accessible, but when your end users enters content, now it might change, right? You have a WYSIWYG that injects divs and styling and that kind of thing. So we want to make sure that not only our market, but our code is accessible. I mean, not only the market, but the content is accessible as well. And then we need to remember too that as the internet expands, the world, the internet creates a world stage, right? So remember that reading and understanding English can be a privilege to some folks. So make sure that your content is easy for everyone to understand, and I'm going to go over what that means. So plain language. This is kind of a big deal. Of course, there's there's edge cases like medical papers and, you know, research papers and that kind of thing where some of these rules don't necessarily apply because you have target audiences, but according to usability.gov, we want to strive to write at the ninth grade reading level. The ideal standard is there should be no more than 20 words per sentence, five sentences per paragraph. We want to use plain language when we can, you know, if you can want to use a word that's five syllables or something like I do technical documentation. So the word tech navigate, you can break that down into the word go. So if you can do that, do that. And remember what I said before, no one reads anymore. We scan, so we want to break up our content into smaller chunks, and bullet points and numbered lists some ways that you can do that. Captions, subtitles and alt text. So we want to be sure that if we have images and videos and visual information on our website that we provide alternative text. So when creating the alternative text, you want to make sure that the text contains the message you want to convey. So if your site contains a slideshow, make sure that all of those slides have alternative text as well. You want to make sure that each photo has alt text and can be navigated via the keyboard. You want to make sure that you have tab indexes and that sort of things. Captions should include inflection, such as yelling or dog barking or music playing, if that adds to the content, if that they need that piece of information to understand what's going on, you know, and you should do it because it's the right thing to do, because it's valuable, you know, to have the same information available for everyone. Image captions, so there's a couple of things like an alt text would say maybe a man and a boy playing basketball, where a caption would say studies show that bonding between fathers and sons helped with this sort of thing, you know, so there's different details depending on what, you know, between the alt and the caption. Table data and infographics should have clear headings, so assistive technology users can be able to navigate and interpret the data as presenting on the screen. We want to make sure that audio and video files link to transcripts if that's, you know, important content. PDFs, we want to make sure that our content that the site links to is also accessible. And PDFs are kind of a tricky thing, you know, they're working on that in the different PDF programs, but it takes work to make the PDF accessible. Bolts who utilize assistive technology rely on clear and concise alt text for viewing their information. And this goes into maybe your whizzy wigs, what you see is what you get. So headings are for organizing content and not for styling, right? They're, they have a function and people who rely on adaptive devices depend on that concise and predictable navigation. We want to make sure that it's consistent and predictable so people have an easier time consuming our content. The h1 and h6, you know, they go in order where the h1 is the most important thing and the h6 is the least and we want to make sure that those are nested. And we want to be sure that there's only one h1 on the page. And I think the rules are changing with that depending on how you break up your content. Do you know anything about that? I just, um, a few uh, a few colleagues of mine, we do a talk called ally talks and we had a speaker on a couple months ago that talked about the headings. And so those rules might be changing in the WCAG standards as far as the h1. All right, so as we're wrapping up, uh, the biggest thing to mention is audit, uh, maybe if I could talk, audits are important to not just developers but to site owners so they know the status of everything and everything from a theme to a module. And audit can consist of different sections. It can consist of technical, uh, which is code, theme, uh, UX, how people use the site, uh, how the site map is laid out, and accessibility, how users need to, how users can interact with the site. Uh, when reviews, uh, when reviewing the technical side, look at different aspects from Drupal's initiative report, initial reports to reviewing the performance to reviewing the performance of the site. Uh, when conducting any sort of UX audit, data is important, uh, to make the best decisions. Uh, so any way you can get data, uh, surveys, analytics, speaking, uh, actually doing interviews with the users is sometimes, uh, beneficial. And then web, web accessibility, uh, can encompass all disabilities that affect access to the website, or to the web just in general. Uh, accessibility isn't just code, but can consist of content. And, uh, when reviewing accessibility, uh, code makes sure to check your, uh, checking against the, the CAD standards. And then finally, uh, when making sure content is successful, uh, make sure it is structured and understandable. And that is if anybody have questions, I went through that a lot quicker than I thought. Yeah. Can you tell us what kind of software else you're using to test the page speed? Yeah, so we're actually just using Google page speed. So, uh, if you, I might be able to bring it up. Well, when you say you think your quality goal besides subjective, uh, about from yourself, at least script or software? Yep. So, let's see if, uh, page speed. So, you can go to Google page speed and you could type, type something like canopy. And what will happen is it will run through this, uh, and it will give you what the page speed is. And it will give you both a desktop and a mobile version. It could take about a minute sometimes. Oh, I can't do that. It's apparently really horrible. But yeah. So, up at the top, it gives you the mobile by default. And then it gives you what the desktop is. And as I was saying, mobile is starting to become the standard of how they start ranking. So, being sure somehow to improve that. They also give some ideas on how to improve that. So, they say like, uh, the first content painting. So, the first time they seize anything, it's about four seconds. And they give you some other suggestions like eliminate rendering or render blocking resources, uh, unused, remove unused CSS, uh, and etc. And then they'll sometimes tell you like minify JavaScript and will tell you like what specific you are, what specific scripts to work on. And then usually, it will tell you a lot of the good things you did also. So, as a people, we don't like to just hit it bad. We like to hit it good. And like, what did we actually pass? There's another tool. So, this is one tool you can use. Another tool which isn't always, I wouldn't necessarily, it's always reliable. But it's Lighthouse. So, in Chrome, by default, in Chrome by default under the audits tab, what this can do for you is you can run this on both mobile and desktop and give different audits you want to do. One of the great things about this one is it can do, it can do a brief accessibility audit on that current page. And this is very similar. So, this one takes a few minutes as well to run. The difference is that Google runs theirs on their own machine. This one runs off of your internet connection. So, sometimes you might have a really fast internet connection and your speed might be a little bit better than, say, somebody who has a slightly slower connection. But this is also a very similar one where it will give you a lot of the same... So, you'll get, like, performance, accessibility breakdown, and, yeah, the different things that you could be doing and the different audits that are running. I want to speak to accessibility testing with automated tools. So, programmically, they're only programmed to catch about 30% of errors on the website. So, be sure to do what we do at Candies. We're sure that we have manual testing as well. You know, if there's a lot of errors that you can catch manually that those dashboards don't catch. So, it's important to remember the manual testing part of that, too, for accessibility. Yeah, there's a lot of things we can script, and there's a lot of things we can account for. Sometimes, just mangle I is also a good one where, before we even turn over a report to a client, we definitely double-check it and make sure everything that's come out of that report is actually correct and accurate. In any of those tools, we do a double-check, not because we doubt them, but because if sometimes we want to make sure that the numbers we're giving are the accurate ones or the true ones. So, they help us give a quick analysis, but then we also do a little bit more deep-diving. Did you ask something about the PHP part of it? No, he was just asking about the PHP. I know what you thought is more of a once-in-a-while type of process. Do you pick and choose any of these things and roll them into your regular update script to catch absence of alt tags or the low-hanging fruit type of things? Do you automate any of that for regular questions? Yeah, so that's a good question. The question is basically, do we automate once we've done an audit every so often we'll do another audit, but how do we do this regularly? So the first thing is we definitely do a full-length audit whenever a new client comes in, and the biggest thing is to make sure both internally we know what we're dealing with, but also the client knows what they're dealing with. And then we do. We build it into our workflow to check these every so often. We don't automate it just because one, I mean we could technically do it into our code deployments. All our codes, our sites are scattered among different hostings, so it's harder when someone's who's hosted on like a site we can only connect to at the FPP sometimes, but there are tools definitely we can do for like accessibility audit, so the biggest one is site improve. We definitely, we suggest to clients to sign up with an account for them because that can consistently monitor coding standards. Those are definitely stuff we do check. We check as part of our code deployments because that is something we are, we are very, we're very passionate about is making sure at least on the code end of things we're good. But site improve seems to be the best one we recommend to clients just because it can do things automatically regardless of what platform. Site improve does more than just the accessibility testing again. This is true, yeah. Yeah, but they have a, a plugin for Google Chrome to do the accessibility testing. I just, I actually just found that out the other day, so. You can't help me too. That was pretty interesting. Yeah. Is there a requirement? Because I mean, I can't remember, I don't know the difference between the states, but so in the states is there a requirement to have a accessibility statement? So depending on the level of organization, I believe it is required. So. And does that accessibility statement require a statement of issue as part of the accessibility statement? Yes, it does. So as I was saying, some, it's not required for, I believe private organizations and it's not required for, I believe even public organizations, but although that's becoming a big thing we're. So it has to have now, which is real, it's any organization, any organization with 50 or more employees. Yeah, it's definitely not like, so in the states, it's any public, any government based organization. So a lot of the state universities definitely have to have it. And I believe very many of the non-profits have to have it as well. If you're getting federal dollars, I think it's a criteria for that. It would make, it makes it almost a requirement to have something that could audit on a regular basis, because that statement has to be current. They're audit. They don't have to be. And accessibility sort of a moving target to, you know, with the standards changing. I mean, if it's a dynamic site, if it's a static site, then it doesn't mean. Yeah, so to give you an example, we just launched a new, I think we just did a read, we just did a retheming of a site. Didn't really change structure, but we just replaced like the shell of it. So the header, the footer, and the homepage. One of the things they required from us is to fill out a form, basically stating that accessibility on that homepage. And even on some of the internal pages, even though we didn't touch those, was up to date. So anytime you really do a retheming, it has to, I know that they required it. And I know that seemed to be if you have it, I don't know what the expiration date is of it though. However, so often you have to do it. Because yeah, contents, those one of those things that I don't think, yeah, especially the ones who create content constantly. I don't know if that's something that could constantly be created unless you do have something that augment itself. I mean, the WAI has a generator, so you can fill in and just fill it out. And it will generate an accessibility statement provided all the information is, as you know, as. Oh, that's a good point. I don't know much about that, unfortunately. Yeah, it's good. But it's like, we're supposed to have a current. There's a date, so it's a date long. That's actually, so in the future we should figure out what the length of that accessibility statement should be. And anyone else? All right. Well, thank you very much.