 You're in core accessibility, building inclusivity into the Drupal project. Welcome to our panel. Today, we're going to cover some basics of accessibility, just so we're all on the same page. What it is, why we need it, some great just general accessibility features found in Drupal 8 core already, some initiatives that we're working on, and how you, the audience member, can get involved. Here are the speakers. Myself, I'm from Hook 42. My name is Carrie Fisher. We have Mike Gifford down there from Open Concept, Helena McCabe from Lullabot, and Katherine McNally from Phase 2. And if you need to contact us, that's our Drupal.org information, and then our Twitter information. All right, so Helena's up first. So I'm going to kick us off here with what accessibility is and why Drupal needs it. So at the heart of it, web accessibility is pretty simple. It's about building websites with the necessary accommodations so that people with disabilities can use them easily. As I explained to a client once, web accessibility is like the wheelchair ramp at a store, but for websites. It's not a thrill, or not, yeah, it's not a thrill, it's a quality issue, and it's especially important to our Drupal community. As we go through this high-level overview on the accessibility basics, so bear with me if it's something you already knew, but we're just kinda, I'm gonna layer on the first FYI, and then I'll go into the deeper stuff. And I'm gonna explain why that is. So there are a few different types of people who benefit mainly from web accessibility, and that is the visually impaired. Those are people who might have trouble distinguishing between colors, viewing content without enough contrast, or they might not be able to see it all. We also have deaf and hard of hearing users, and they may have trouble understanding content that is poorly captioned or not captioned at all. They benefit from a chat option instead of having to call in, so that's always a good thing to do. We also have users who are motor impaired. Those are people who have fine or gross motor problems. That could be anything from a tremor from Parkinson's to being paralyzed from the neck down, anything that makes it difficult to use a mouse. We also have people with vestibular issues and seizures, and these issues are extremely important and often overlooked. They're one of the most direct ways that a poorly built website can physically harm our users, so it's really important to be mindful of these. I know Parallax was all the rage a few years ago. A lot of companies still really like it. Designers are really fond of it, but people with vestibular issues can get motion sickness from those types of event effects, so it's really, really good to be sparing with them if you use them at all. And websites with fast, bright, flashing effects. Those can trigger seizures in some people, and seizures can be very dangerous. So no matter how important or exciting that blog post is, please don't use flashing effects to pull someone's attention toward it. You could really injure them. And finally, we have people with cognitive disabilities. We have a large aging population that's online, people with Alzheimer's, and more people with conditions like Down syndrome and autism are working than ever before. So supporting these communities by helping them be as self-sufficient as possible is an important goal that we should be striving toward. So how people with disabilities use the web differently? The biggest one is keyboard and screen reader accessibility. Most blind people and people with motor disabilities don't use a mouse. They navigate the site by keyboard. And that means that nothing on your website should require a mouse to access or interact with. This is one of your biggest accessibility wins because it covers so many diverse disabilities and is heavily needed by so many people. Usually when blind people are keyboard navigating, they're also using a screen reader. So that means we'll wanna be sure we're being mindful about what will and won't be read when someone is navigating our website. It's like providing descriptive text about the destination of links instead of just an image or the words click here using appropriate alternative text on images to describe them. And it's important not to co-opt those accommodation tools for black hat SEO keyword stuffing. Please don't just jam a lot of random keywords into that. That's really harmful for people. Captions and transcripts. Deaf people need captions to know what's going on in videos with speech, especially when the speech is a narration of imagery. Transcripts and captions are not the same thing and they serve different purposes. Captions happen in time with the audio and they're primarily for deaf people where transcripts are of, okay, sorry. And transcripts are a full description of both audio and visual information provided by a video. So these are particularly useful for deaf blind users who will usually translate this information into a braille reader to get the full rundown of what that video contained. We also have color and contrast. For low vision users, especially the elderly, contrast can really be key. I know light gray text on white backgrounds and these hair thin fonts are so subtle and stylish and popular, but they're really hard for people to see, especially people who are low vision. So to hit double A compliance, the standard is a contrast ratio of four and a half to one for normal text and three to one for large text, which is anything above 18 pixels. And finally we have our cognitive. We often think of accessibility in terms of physical accommodations, but cognitive accommodations are equally important. People with dementia and Alzheimer's benefit from websites with a predictable, constant, intuitive layout so they don't have to constantly reorient themselves from page to page. And people with intellectual disabilities or sensory processing issues like dyslexia may need more time to digest content, especially if it's complex. Using the clearest language possible and not forcing users through content at a pace beyond their control, looking at you auto advancing homepage slider with text, is really helpful for those communities. So our need for accessibility in the Drupal community comes from three main sources. We have Drupal users who are the end users who will build our web, or who will use our websites. And this is the group that we most frequently think of when we talk about accessibility, but that's really only a part of the picture. We also have our Drupal developers, our community members who will build websites using Drupal. And I know blind developers who love Drupal 8 because of how easy it is for them to use on the backend. People with disabilities aren't just consumers of content, they're creating it too. So an inclusive Drupal community needs to be built to include everyone who wants to use these tools, not just the easiest bodies to build for. And of course our Drupal clients, which are the businesses and agencies that Drupal developers build websites for. One of the most pervasive excuses for skipping over accessibility on web projects is that it's an edge case. And this really has to stop because it's not. I've heard countless times that there's no budget for it on the project because there were other features that the client wanted and so accessibility was de-prioritized as an edge case. And in every instance this has happened, IE testing and support has stayed on the roster. So to put it into perspective, we've got somewhere between 12.6% of all people in the US having a disability and somewhere between 3% and 8% of all people using IE. So why is it that as an industry we're fascinated with accounting for a browser that very few people are using but routinely ignoring or de-prioritizing accessibility? At 12%, 12.6% of the 2016 population, that brings us to an estimated 40.7 million people in the US with a disability. That's about a million more people than the entire population of California. Or, since we're in Nashville, around six times as many people as the population of Tennessee. So why do Drupal clients need accessibility? Well, we have improved access to customers because 12.6% of the population is a lot. And we have legal safety because being sued is bad. So we have Section 508, the WCAG 2.0 and Title III of the ADA. And the main one I wanna hit here is the Americans with Disabilities Act of 1990 because in 2017, digital spaces became the legal responsibility of the private sector. We've had a lot of landmark lawsuits in the last few years. The federal court just ruled that Winn-Dixie's website being inaccessible violated the ADA. So there's legal precedent now for the private sector as well as public. So if you thought, oh, well, we don't have to do it because we're not under Section 508, which applies to public, no, now the ADA applies to you as well. So the bottom line is that Drupal's a big deal. We're estimated at a market share of about 2.2% of all websites. And even if that number doesn't seem like a big one, when you consider how many websites actually exist, it's massive. The work we're doing here matters a lot. And agencies may not always know how or they may not make time for accessibility. So the better our core product is out of the box, the better accessibility will be for everyone. So now that I've given you a high-level overview of what accessibility is and why we're doing it, I'm gonna pass it off to Catherine, who will tell us about what we've done recently to make things better. Thanks, Elena. So I'm Catherine from Phase Two. I'm Asim Adi who is deaf. I really appreciate when businesses and companies try to implement accessibility from the very beginning. So that's why it's so amazing to see accessibility out of the box in Drupal 8. So I'm really excited to go over some of these accessibility improvements that we have to make Drupal even more accessible. We're getting a stronger foundation that we can build upon. And so some important Drupal wins as of late. The inline form errors. If you recall previously, when there was an error, it was just a message at the top of the screen. You had to figure out where the error is gonna be. So these inline error forms are really useful because it actually shows you where the error is. But not only is that great, it's also added on the layer of Drupal Announce because it's gonna alert the screen reader user that there's an error. Previously, when there was an error, the user of a screen reader wasn't immediately made aware of it. And that led to user frustration. I'm like, why can't I submit this form? They couldn't find the error. So combined with Drupal Announce and the form errors, we'll see a lot of improvement in reducing user frustration and friction. Numami out of the box is a theme in Drupal 8, which is not quite out yet. It's still an experimental mode, but there's just a great example of an accessible theme out there. It's got some great accessibility for landmarks, headings, link structures, and some enhancements are in the pipeline. But I'll go over some of these enhancements in a few minutes. And then we finally got this point release going right now, in which we will have to wait for a major update to see some improvement because you see more incremental updates, which is gonna really help us test out new accessibility features and see if things are responding well in the market. As I mentioned, Drupal Announce, I'm gonna show a screen reader demo. How many of you have heard a screen reader before? Oh, okay, great. So this will be like, oh my gosh. And again, a screen reader experience is completely different that we as sighted people can't experience the same way as somebody who is blind will have slow version experience, because there's so new to it. It's like, it's a part of the experience, but we should still be thinking about how we're gonna create these experiences. So this is usually the new mommy theme, and I intentionally submitted an empty search. And so you should be hearing the Drupal Announce right away. Let's see here. Oh dear, I think we were right before. So, that was good. Yay, Drupal Announce. So what happens right after submit? They were immediately made aware of those two error messages. Previously, it would load, and you have to go through Skip to Main until they found the error. So that's awesome. Let's see if I can go to the next slide. Okay, great. So Drupal Announce is still a model that you have to enable. So we're still missing the mark in Drupal Core. You know, there are more options and more places where we can apply Drupal 8. I'm sorry, Drupal Announce. And you know, how are we gonna make, how can we help the community be made aware of this model and implement it into the model so that if there's an error, that Drupal Announce can come up and be beneficial for screen readers. And do model owners even know about it? Cause that's something that we need to be talking more about. That's something that's gonna be really useful. And so new mommy accessibility. So we've got some menu accessibility enhancements and some menu, mobile menu fixes coming down. Primary tab, theming updates is a really good experience. Heading structures of landmarks are in place. I'm gonna play a video of the landmarks. And so I'm gonna go through all of the landmarks. I didn't do any additional coding. They did all new mommy in Drupal 8. It's a landmarks. It's pretty great. And then I'm gonna stop it kind of appropriately. I'm about to have another section of the video. So just forget me if I stop in the middle. Can you hear me? Main navigation navigation. Account search, main navigation navigation. You are currently in a navigation. Heading level two, main navigation, list three items. Visited link, home, one of three. Link, articles, two of three. You are currently on a link. Visited link, recipes, three of three. You are pressed, visited, but the recipes were... So that is not doing anything from a container to a developer perspective. So they're just really encouraging and really promising to see that this theme already has these landmarks in place. And landmarks are really useful for screen readers because they give some context in a center place. And in announcing the menu, one of three, two of three, three of three helps them with the center of order and how big the menu is. So those are all really promising things, you new mommy. I don't want to do that, I'm sorry guys. I'll just go to the next slide. All right, great. And so we've got some color contrast ratio updates that need to be applied. Redundant links. I'm seeing this more and more. And then you have like an image, the title and a read well link. Kind of a card, a post that gives you a grid. And a lot of times it's three links together. So it becomes very redundant to a screen reader. And so we need to be wrapping it as one link item. So like baker cookie would be one recipe link. And so I'm gonna see if I can play that for you guys. All right, it's right here. Articles two of three, you are currently on a link. Visited link, you'll press visited in the demo web content. Main app search, use breadcrumbs. You're heading level two link, deep Mediterranean quiche. The same link. So those are the three of the same links. And so the screen readers can have to repeat themselves. So one of the updates that we're working on, what the community is working on is making that one whole link. So that's just gonna make a much more intuitive experience. So that's great. So really exciting stuff with the theme coming up. I think in some, in the air measure states, having colors, icons and text is gonna be something that's gonna be working on in the theme and the layout builder. There's still a few issues with getting the layout builder to be accessible. And so still some good stuff coming up, really promising, really exciting to see all of these foundational and the community coming together to make something even more accessible out of the box. So I'm gonna turn it over to Mike and he'll give you talking about more of the initiatives that we're working on. Thank you, Catherine. So first of all, how many people have contributed at all to issues in Drupal accessibility over the years? Okay, that's great. And how many people here are familiar with or have tested it all with accessibility of Drupal? Excellent. So that's good to see that there's that many people who've looked at and evaluated this. Accessibility is very much a journey and not a destination. So we're never going to be able to get Drupal to a point where it's perfectly accessible. So it's something where we're gonna keep needing your input and direction to find ways to make it better and better as we go ahead, especially as we keep adding new exciting features. I've gone off and used some notation here that I think should be common in Drupal. Most people will recognize this if you're familiar with the issue queue. I'm just using the hashtag here in brackets, which will in the Drupal issue queue go off and give you a link to the issue. So rather than putting in the whole Drupal.org issue, I'm just providing the short form. And this is something that I'll just use that for a couple slides to go off and give people some reference to some existing issues. So one of the things that we need to do and haven't yet found an implementation for is looking at providing some sort of a test swarm for Drupal accessibility. We had an early one set up on Quail, which is a JavaScript library that was built for kind of for Drupal, within the Drupal community. And it was a standalone, initially PHP and then JavaScript library that was developed and that was really good, but it's no longer being supported. But there's opportunities to go off and to build a test suite for either Pali or Axcore or even with tools like Tenon, which are great tools for doing automated sort of site-wide tests, but it's something that takes people who have interest experience and background in developing JavaScript testing environments and given the size and the complexity of Drupal, we need to be able to monitor whether or not, just basically our error is going up or down. Are we finding this, are we in a situation where with every patch that's submitted, with every build that goes out, are we finding ourselves to be more accessible or less accessible? Keep in mind with any automated test, you're only gonna catch a fraction of the accessibility errors that are out there. There's some really good tools out there, but they're not gonna catch everything. And so don't assume that just because it passes the tests that your code is accessible. Likewise, don't assume that if your code fails the test, it doesn't necessarily mean that there's an accessibility problem there, either, the tests are just tests. So there's a lot of opportunity around continuous integration and establishing a stronger testing infrastructure. And the issue number, if you're looking for it, is 285-7808. And if anyone here wants to step up and take on opportunities to go off and to build in more automated tests into Drupal Core, that would help moving ahead quite considerably. LeoBuilder was another interesting challenge that we ran into in Drupal. And LeoBuilder is a great initiative to allow us to more dynamically go in and address how pages are designed and how content is organized on a page. Unfortunately, there are no good patterns right now that are widely accepted for how to do drag and drop functionality. So we've done, there's an issue queue that we've worked on, which I, oh yeah, it was issue 292006, which is, we needed to go off and identify what those best practices were. And one of the great things about working on Drupal accessibility is that we can actually take a pioneering role in identifying and creating the best practice for the web. And it's a, we've did that with both the CSS Display None alternatives, which were brought in in Drupal 7. That's a really great way and it's a, we've seen other software projects adopt a centralized CSS management for invisible or hidden or on focus text. But it's still something that's not everyone knows about. And it's really important to have these kinds of centralized functions because it allows us to be able to be future compatible. Technology changes all the time and if you centralize functionality like drag and drop, then you can, you can fix it, when the browser's changed, when the assistive technology is modified, when user functionality is adjusted, then you can update that pattern in one place and have that roll out across not just your site but all of the sites that use that particular library. So, you know, we wanted to go off and make sure that we have a good pattern in place and there's some interesting tools that are being built with React right now that we might be able to use to leverage the interesting work that's being done to try and update the JavaScript, to have a JavaScript driven backend for Drupal. So again, that could be quite useful. It is a bit unclear right now in some ways when the Drupal accessibility team identifies a problem with the issues, who's responsible for fixing that issue and how, you know, the accessibility team is really quite small. We're active on the Slack chat, you'll be able to see a link to the Slack chat. It's just the Drupal, there's an accessibility channel in the Drupal Slack chat, but there's a few of us who are engaged there and Andrew McPherson has been a real bonus having him on board, because he's taken on a whole other range of initiatives looking at WCAG 2.1 and looking at trying to do more work on the user testing and having more people look at ways that we could make Drupal better is really important and Andrew's taken a wonderful leadership role in that. We really wanted to bring him over to the UK, but couldn't justify that. So with the drag and drop functionality, we have a couple of patterns, we need examples of, we need some help testing and choosing the pattern and hopefully being able to roll that out so that we have a common pattern for the layout builder that we can use across the board and make sure that we're able to proceed with this. And this is actually, this is a problem that we did kind of address in Drupal 7. Many of you may have looked at the widget, the show high widget above tables. If you're doing a table drag, I mean that's essentially a kind of drag and drop functionality except that our solution in that case was to build a widget that disabled the JavaScript. And that kind of, that has some problems and some advantages, but that's how we tried to go off and address that. We need a solution right now that works for a two dimensional world so that you can go off and move items both left and right and up and down and know where that item is after you've moved it, whether you're using a keyboard or whether you're using a tool like voiceover or NVDA. And that's definitely a challenge. But we also need to be thinking ahead because at some point we may be having VR or AR integration with our websites and we might need to be able to not only go off and worry about moving it left and right but also forward and back and what is the language and the patterns that we use to communicate about moving things around in those different dimensions. So I mentioned a little bit about WCAG 2.1. This is a standard which has not been released yet but like all other standards on the web they change and evolve over time. And WCAG 2.1 is an effort to try and modernize and bring up to date the guidelines that were set up. WCAG 2.0, although it's new to many people in the United States, that's actually a guideline that was put forward in 2008 and it's now 2018. So it's more than time for us to go off and update that standard and to look at who we've missed and who we need to go off and bring into the community. And one of the big areas that's being addressed for WCAG 2.1 is cognitive disabilities and things like, you know, we haven't done enough to try and address issues like plain language. How do we make sure that we're communicating to people in a way that they can understand, particularly in a very busy hectic world that we are all living in? Area is another one and we've implemented some area in Drupal, well, we've implemented very little in Drupal 7, we implemented quite a lot in Drupal 8 but these standards are evolving over time as well and we need to go off and make sure that we've implemented the correct way and that we're not, that we're appropriately labeling our templates as well as the functional elements of our site and are able to keep up with the best practices of the web. There's some amazing opportunities to try and insert accessibility into all kinds of things. You know, many of us are still at the stage of looking about how to go off and migrate information over from a Drupal 6 or Drupal 7 website into Drupal 8. Wouldn't it be great in the process of migrating your site over that you were able to clean up the old, you know, HTML for code, be able to bring that up to a modern standard for a modern responsive website that you're able to strip out all the font tags, you're able to verify which of the pages you're migrating over are missing alt text and might have broken links and other things that are a problem for the user with the migrated content? Wouldn't it be good if we could try and do that as opposed to leaving this as this nasty problem? Well, we could look at this. We could build this into the migrate module and find ways that we're able to test user content as it's being brought in and make sure that especially at these big pain points for organizations that we're able to help them adopt best practices going forward. The media module is another one where things were, it wasn't a concern in Drupal 8.0 to have a, to look at a lot of the structure of it. Actually just to mention, we've tried to go off and look at the incorporate ATAG concepts into Drupal 8. ATAG is the authoring tool accessibility guidelines which for, especially for any institution like a university or a government agency, ATAG it seems like it's a really wonderful way to go off and save a hell of a lot of money and resources. If you can improve the authoring interface so that it's easier for authors to produce more accessible content by defaults then you will save money. It's just, it's a no brainer but nobody wants to invest in that and find ways to make sure that that content is, yeah, that they're helping their authors out as much as they can and using the tools and the technology to be able to help their authors produce the best content possible. But now that we've got the medium module into, actually as of 8.4, we need to be thinking about how to go off and think about ways to make sure that we're addressing images and videos more effectively in the authoring process. And with Yamami, again, there's a lot more that can be done. We're, especially as content is being added to the site, I find that it's great to have this demo site out there and it's amazing that people like Carrie have gone so far to go off and make the alt tags not only there but actually tasty. Like if you look at the alt tags, if you're reading the alt tags, you should feel as hungry reading the alt text as you are looking at the images. And it was wonderful to go off and to see the alt text or to talk about the initial story of Yamami and how that was, the making of the photos for Yamami is as part of the keynote this morning. And again, if we can try and take some of that passion that went into making these images and finding ways to actually make it also accessible so that everyone wants to go off and have a cookie or a brownie or that delicious soup. So yeah. So there's a number of strategic initiatives that are being set forth by the Drupal core team. The theme component library and the JavaScript modernization movement. There's issues around the experimental admin UI, the outside in process and each of these, like there are accessibility elements in all of them and they need to be tested and evaluated and the accessibility team is really quite small and we might have the ability to go off and to jump up and be involved in some of these things but we need really to have more people looking at these and finding ways to evaluate them with tools like the wave tool bar with Tenen with color contrast tools. There's a lot of the stuff can be tested quite easily with automated tools and you don't need to be an accessibility expert in order to do them. If you see a red flag, then if you see something say something like that, like we can have people participate in the issue queue, we can find people to participate with creating patches and some of these things are very easy to evaluate. There's harder things as well that do need some experience but so much can be done by just, can you tab through the interface? Do the, when you're building a test, can you evaluate whether or not it meets if the wave tool bar or the axe core, do they produce any errors that you're identifying? If we can have that testing being done by other people in the community, it helps a whole lot and we can always use more people in the Drupal accessibility team as well. So jump up and join the Slack group and find ways to get involved. And now. I can speak more about that. Absolutely. This is the part, as Mike said, that I've been working with accessibility for a few years now and I've written things and I've done testing and have clients and built this cool like accessibility component library. And I got to do a lot of fun things but I, and I've been in the Drupal community since 2005 but I had never contributed to the code base until this year and a couple months ago actually with the help of my company Hook 42 and Amy June that works there and it just happened to be Umami which everyone's talking about and it's very exciting and I got to do some things that, even though all the stuff that I've done with accessibility I literally wrote text to describe an image. And so it's not that you have to be this person. You can be the person that wants to describe what a brownie looks like on a plate. And you can still be a core contributor to Drupal and that's kind of sad that that's like in my core credits but I did a few other things but yeah. So don't think of this as like a huge accessibility issue but there are some challenges and we're gonna kind of talk about some of the things that people do are worried about. So again, if you think okay, I'm a beginner into accessibility and how can I contribute? I'm just interested in the topic but that's great because that's where we all started from. We all started with just an interest and a drive and so it could be that you just check the color contrast and verify that code is correct. It's just like all these little tiny things that add up but speaking of automated testing, they're really only catching right now about 20 to 40% on a good day and all the different tools that are out there for automated testing, some are better at some things and some things are better at others and I'm actually excited about the day when we're gonna catch 80, maybe 90. I'll never say 100. I feel like we'll never get to 100 but maybe I'll prove me wrong, please. But so that's a challenge because if you're only running automated testing, you're only gonna catch let's say 40%. So then you can go on to manual accessibility testing which includes things like using keyboard navigation to tab through a page or using assistive technology devices to see where the errors are but it can take a long time and can be difficult and it is also one of those things that you kind of have to practice a little bit before you can feel like really confident in what the problem is and how to address it. And then on top of all of that, we have this accessibility as a moving target. So we're talking about the WCAG 2.0s that we're on right now. 2.1s are coming out in June. You got all the other A tags and you've got the ADA and you've got all these laws and regulations and then you have browsers, right? Browsers are not stagnant. They keep evolving and changing and introducing little fun bugs and things that we have to squish. Assistive technologies themselves also change and versions matter. And one assistive technology on, I don't know, Chrome version, whatever is gonna be different possibly on Safari version, whatever. So it's not even like there's consistent bugs that you're seeing also. And then users, we're all unique people and we all have our unique abilities and limitations. And so these are a lot of challenges but I'm gonna make you feel maybe a little bit happier and give you some of the why you should help. So we talked about some of the things that we're doing in Triple 8, some of the things that we wanna do in the future. But why should you help, right? If you're an organization, there's a lot of different reasons like saving time and money, it's the law, that sort of great stuff. As an agency themselves as a leader, you want to attract these employees, you wanna attract clients. Think of it as, if we're talking about one billion people in the world who have identified as having a disability, that's a large percentage of potential customers that you could have. So if you kinda switch it around a little bit, it helps bring in the money and the time and the effort. And then the community, if we can develop skills we have a great team, we can get together as individuals, you can grow as well. So there's a lot of really great reasons of why you should help. So we'll get to the how and we'll go through it a little faster so we can have time for questions. But how can you help? So again, going to events like this, going to sessions like this, that's great, checking the triple.org issue queue. If you're an agency or an organization, give your volunteers or your employees some time to do this. Maybe a little bit of extra research time or allowing them to go to a conference or a local meetup. There's a lot of great things. The community, also it's one of those community, you have to be a good community source as a person wanting to learn, but then you also have to have the people who'll step up and teach. And I might not be an expert at the latest, I don't know, back in whatever. But then I know that this person knows this so we can put our skills together, accessibility in front end, and then they're back in skills and we can talk about like, how can we make a solution that's holistic? So I think it takes all of us. So a couple of ways we've all talked today about code. We've talked a lot about code. So like U-Mommy updates, JavaScript, workspace experimental modules, there's a lot of things. You can easily find issue queues with the accessibility tag. But beyond that, there's so much more that people can do too. And I feel like that part gets really lost, especially at tech conferences, but documentation, documentation, documentation. You may not know everything, but you can start to write about it and you get into it and you get to deep thinking. Mike Gifford, myself, Andrew McPherson, we all have access to the Drupal.org documentation module or pages. So if you get in there and you've seen this and you say, oh, Mike, we're missing this section, I think you need to change this or edit this page. You can either send that to us directly or you can edit the node and then we can just submit it and then we can press okay and basically publish your changes. But if we're not doing it, we also want you guys to do it. So it's a team effort. So these other ones too, connections and meeting up. We have this Drupal group and we have a monthly accessibility meetup. So it's virtual. You can do it in your pajamas and whatever. Whatever time it is, you're in your time zone. We have the hashtag ally talks and every month what we get is we get an expert from the accessibility community to come in and talk about a various topics. So we've had things about documentation. We've had people come in and talk about JavaScript. We've had people who come in, even Helena was on a panel where we talked about how we use Drupal and how we use accessibility in our daily lives at work and what it means to us. And so there's a lot of different topics and a lot of things to learn. So you may not like this month's challenge or this month's topic, but then the next month it switches and all of that is recorded to you on the YouTube channel and connections. So besides Drupal, there's this crazy big world out there accessibility world and internationally it is huge. Like Canada and Europe especially are like, I hate to say that but they're light years ahead of us, right? And they've been doing it a little bit longer. They may have slightly different laws or rules. But I mean, if we're talking about WCAG 2.0 that's international standards. So there's a lot you can learn from people who've already done it as well. If you do want to have people to look up to that you've been doing it for 20, 30 years. I'm not quite there yet. I don't, maybe Mike is there yet but the rest of us have a few more years to catch up to Europe. But besides that, there's the W3 Slack channel. So if you want to get outside the Drupal Island that's a great place. I love it. There's so many really wonderful people there. Twitter, company blogs, tasks, writing projects. Just it's all over there. And if you need help, look, we have resources. So I won't read all of these because we don't have time but we'll keep these, the slide deck will be on this presentation and so you can come back and reference it some of the things that we talked about today if you want to get in a little bit deeper about those. Accessibility statements. These are all the Drupal ones. This is the documentation I was talking about earlier. And then some of the groups. So the Drupal Slack, W3C and then you have these other meetup groups. I threw up my style guide in case you're a friend and developer and you care about that. But also this accessibility people and company list. This is just on GitHub and it's got a great list of people and companies that are contributing to the accessibility worldwide, the cause. And so they are a wealth of information. So that's about it. I'm going to read this real quick. This is one of our favorite quotes collectively because I chose it. The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect. And this is Tim Berners-Lee which is a W3C director and inventor of the worldwide web. So it's important. And even from the very, very beginning, they knew that that was something that was very important and equalizing for all of us. So thank you guys. That's our formal presentation. Now if you have any more, if you have any questions, this would be a time. Oh, I can go to the mic if you can. Only for a minute, I'm at 18F. I'm at the 18F. 18F. 18. 18F. Yeah, they've got some good accessibility resources from the government. And if you come up, I can give you your output and they have some neat federal government accessibility practices, how tos for specifically section 508. Yeah, there's mass.gov. I don't know if people have mentioned that one. And there's the UK one. Is that the one you're going to mention? Yeah, the government digital services in the UK has got some wonderful resources and it's a great place to look at. And they're also leading the open government initiative in a lot of ways. So if you're looking for open and accessible, like the UK is a great example internationally. You mentioned Peronax effecting some users. Are you aware of any emotional background, video issues with those same people or some of the same users? Yes, anything that, Oh, there goes my phone. Yeah, people who get motion sickness, I mean, people come in all stripes. So, you know, what impacts one person may not impact another, but videos that have a lot of motion when the person is not moving, anything that can make you feel like you're moving, like a video out the window of a car, you know, out of the window of an elevator, things like that can cause motion sickness for people. The accessibility module that I know exists for people seven or eight and then adding that to core. And the reason why I ask is where I work, we do use the Lizzie Wink module, excuse me, and CK editor, I know is now a part of people eight. The accessibility module, in theory, but it works correctly. I know you need about three or four patches in order to get it to work correctly. Does work for developers who are developing towards the site, and it allows user, or those who are developing, a site using the accessibility, using the site to actually keep notes in order to explain how or explain what those tests are. Has there been any thoughts about that at all? So, two responses to that one. One is the, there's the CK editor accessibility plugin, which I'm not sure, is that the one you were referring to? No, there's an actual. Yeah, there's an older module for Drupal 7, yeah. Yeah. There's a quail, but a quail still brings up it. Yeah, the quail is no longer supported, nobody's touching quail, so that's a real problem for both the accessibility module that Kevin had set up initially that was using quail to go off and to do those tests. But it's also a problem for the CK editor accessibility plugin that some people are building in because they're running JavaScript on their site, an unsupported JavaScript library in their site, and what are the security implications of just leaving another unsupported JavaScript library in your site? It may be nothing, but I don't recommend it for any of my clients and I wouldn't recommend it for anyone else. So, in terms of upgrading the Drupal module that helped test the development of, the development environment, to test the site itself, there haven't been any efforts to try and upgrade that that I'm aware of, and partly it's trying to go off and get to finding a way to go off and to incorporate AxeCore or Pali or, there is a Tenon module that you can download for your site that will plug in, and I think there's both the Drupal 7 and Drupal 8 version of that. That's probably the closest that we have for that style of Drupal module to provide accessibility evaluations. But hopefully that will change, and especially the Chrome toolbar that's the Lighthouse developer tools, that involves an accessibility component that a lot of people don't know about. So that actually will test your page using AxeCore to go off and to evaluate it for basic accessibility too, and most of your developers will probably have that Chrome developer toolkit enabled and using it all the time. So convincing them to go off and to use the Lighthouse web accessibility tool is probably an easy sell. Do you know any of those tools offer feedback for content editors which is kind of what's the drawback when I initially saw that module be accessible to the module, which we're not using anyway? Yeah. But do you know any of those tools that offer that? I don't think so. There is a tool though that can check your, I have to, I'll send you a link or something, but it will test your content for obvious accessibility errors and the reading level and whether or not, it's got all these little facets and stuff and actually one of the presenters at one of our monthly meetups is the one who told us all about it, but it's like an external tool and I think that's maybe the reason why people haven't updated the accessibility tool inside of Drupal, is there all these great, very nuanced, great tools out there already that can do some of these very specific things and with great reliability that maybe they haven't wanted to do that, but I can get you a link for that particular one if you're talking about content-specific, but... There's another one by the Khan Academy, it's called Tota 11i, totally, and you can put it on Drupal, but you can also have it at the Chrome plugin and the cool thing about it is it checks all of the front page stuff, so that could be for the content editor stuff. So what it does is it will scan it and it will say, oops, there's error, consider doing X. So it not only tells you it was wrong, like how to fix it. So it's pretty cool for like cutting, so like how do you skip the heading, make this heading bore or something like that and bullet list and that kind of thing. So it's totally Tota 11i. Another good one for that is Wave Tool and that also will do the same thing, it'll tell you what's wrong, but it'll also tell you why it's wrong and explain how to fix it and then there's another tab on it for outline and it'll give you an outline of the page structure so that you can make sure that all of your headings are nested semantically. Yeah, but that's almost like a difference because it's markup versus like actual content. You know what I mean? Yeah, but it's checked. I mean, it's not until they've put it up, but once they've put it up, they can see have I used headings properly or am I using them for decoration, things like that. There's a tool for everything. Yeah. I didn't talk, just in the questions. I don't think I mentioned Lighthouse prior. Yeah, I was gonna ask. I'm guessing that it's somewhere around 25%. There was the closest evaluation that I've seen of this recently was the UK government did an assessment of these various tools and they created a dummy page that had a number of accessibility problems with it and said, you know, they tested these tools and including ones like Site Improve and looked at how they did and I don't have the numbers offhand, but if you search for the UK government accessibility, you know, tool checklist or survey, you'll be able to find that. Okay, thank you. Yeah, it's this really great page where everything's like broken. I mean, you can see how well your tool is. Oh, so this is what I put this slide back up because we have the contributed accessibility modules for D8 and those are the ones that have been deemed as tagged with accessibility and then there's notes like the one with the Quail.js and being a security issue. So that might be a good reference for... So there's an issue to try and add the CK Editor accessibility plugin to CORE, but that is postponed and because the parent project CK Editor is, they have to go off and fix the... They have to swap out Quail for AXCore or Pali in order before that can take place. So until CK Editor fixes that problem, we aren't going to be upgrading that in CORE. I think I saw a question over there. I'm curious, did there's some of the documentation that's on DIO, which is definitely adding so much to that. I'm curious though, because one of the things that's really annoying whenever you're writing, or a few responses, is you'll get an EMAT apartment. And I haven't seen any of my web scouring, like I've fully available EMAT for Google, which is kind of disingenuous, it's not all forced up, you have to dress, and there's a lot of things you have to do, security modules and just sweating blood. But I mean, how do we now have it generally done? I wonder if there would be a place on v.co or somewhere else that would be appropriate for community-led response for Google? And where do you guys think that would feel best? That's a good question. So it is. First of all, I do have a GitHub page that references best practices for accessibility procurement. And I think that this is a big part of it, because a lot of organizations say, must meet WKG 2.0 AA, and that's the bullet point that they list in the site. And that's the best case scenario. I saw one from a municipal organization that said, WCRG 2.0 AA is like they got the acronym wrong, so like, well, what is the legal implications for an RFP response that didn't get the acronym right for this? Yeah, exactly. And you can do that, but you just don't have the budget for it. Like there's, you know, you have to add a zero or two at the end of your, in order to go up and meet that triple A compliance. But in terms of VPATs, I mean, VPATs have been reformed recently, so they're better now. It's still problematic because the VPATs don't actually require a third party evaluation to see that this is anything more than a sales job. And nobody in the Drupal Association, or nobody in the accessibility team has been interested in pursuing the extensive sales piece that needs to happen in order to go off and to fill in the VPAT in order to make claims and assertions that may or may not be true in order to go off and make this a valuable document for procurement purposes. Because it's... What is VPAT? Let's see. Voluntary Accessibility, yes. Something rather, voluntary. It's a government, it's a government, you see US government accessibility procurement loophole, or they put up so that they can go off and put on to vendors. You know, is your site accessible? If you've got a VPAT statement, then we've covered our ass, and we can make sure that we've gone off and done our due diligence because they have a VPAT statement, therefore the accessibility problems aren't our fault. I think that's it too, like why people don't want to touch it is because of the legal implications and the liability. So I... You know what I mean? I'm sure you can find something open source or free on the web, but I'm not really sure how specific that is to your organization or your company. There's a lot of things to consider. So what I'm hearing is that we need something that puts something out there, but others... We could add it to our documentation if you want to help write it. Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah. I would think so. I mean, if we could put something like a template or something... So, yeah, I mean, if you wanted to go up and put up a Google Doc or a GitHub page to go off and start this, they'd be happy to promote it. And if you're able to take the lead on this and try to build something that's a credible VPAT statement that allows Drupal to have a leg up over others, and it would be interesting to go up and see, well, what has the WordPress community done? Do they have anything? What have any other open source community done? Generally what was being done for the US government is say, okay, well, it was accessible enough for the White House. It's not anymore because they switched to WordPress, but it is accessible enough for so many other lead government agencies that it's accessible enough and it doesn't really require a VPAT, so, but that may not count in this day and age, so. We promised to adhere to Workag 4.0. Yes. Level CCC. Yeah. Yeah. Thank you. Thank you. I'm all being touched on it, and I'm sure it'll make a credible amount of girls help, so I don't think that'll happen. Cool. Excellent. All right, well thank you for there's no more questions. There's a couple more accessibility opportunities. There's a buff right after this. If you have very specific questions or you wanna talk about any things that we talked about today in more in depth. And then tomorrow, I guess tomorrow's Wednesday, right, the accessible editor, and then also a smarter way to test accessibility. Those are both coming up tomorrow. And we'll have these slides, we'll tweet about them and how we tweet about them and just... I don't know, we'll send them a link or something. Yeah, something like that. So we can post up something and retweet that, so take an eye out for that. All right, thank you guys. One more thing. We are also going to have a little open Q&A at the Lullabot booth tomorrow, so if anybody has a question that they didn't think of today and they wanna swing by, I don't know when it is, but I will tweet it. And I'll hashtag it, DrupalCon, so that you guys can find it. There you go, perfect. Thank you. Very lovely. Oh, hi. That is good. I found it. Oh. I thought those things, yeah. Alcohol, battle, and firearms, is the only website? Uh-huh, yeah. Don't worry about it.