 Thank you. Thank you for showing up. Okay. I'm going to talk about WordPress and accessibility. And the first thing I want to say, everything I'm telling you, including the links, the link to the slides, every content, images is also available on reandritveld.com slash wceu16. So you can read the full story there. Okay. How accessible is WordPress? Well, it depends. It depends on how smart you are, how old you are, in what country you live, how good your internet connection is. If you're using existing technology, like screen reader or voice recognition software, there's not really a label you can put on it. Accessibility, WordPress, that's a number. It depends on the user, and there's so many different kind of users. So it depends on the user. But a lot of it, if you look at it overall, is pretty good. The basis is really pretty good, and that's good news. If we look at the front end, WordPress ships with the theme called 2016. That's very accessible. It's an excellent theme. You can download them for free when you download WordPress. There are other themes in the WordPress theme repository that are labeled accessibility ready. That are accessible, too. The most accessible issues are solved there. So you can download them for free. If you are a developer, you can use the Genesis framework. Together with the sample theme, you have an excellent base to build an accessible theme on. So a lot of choice of accessible themes together with WordPress on the front end. If you look at the backend, if you are a user, if you keep it simple and use the basics, then you can use WordPress very well. You can add images, you can add a title, you can add content, some images. If you don't get too fancy, you can post, you can add text, you can add a menu to your theme. Always keyword and screen reader very well done. You can add widgets. So overall, if you keep it simple, you have an accessible front end and you can use the backend also if you have, for example, screen reader or don't use a mouse. So that's good news. But there's still a lot to do. First of all, I want to address some things that are more in the blog post. Legacy code. WordPress is a teenager. 13 years. Difficult age. Trying to grow up. So a lot of code that's in WordPress now has been there for a long time. And some of it isn't really accessible at all. But because it's been there for so long, the plugins or themes depend on it. So if you change that, make it in something accessible, plugins will break. And that's not really our intent. I want to give one example. It's like the settings API. In the WordPress admin, you can adjust the settings of your WordPress install. That's built in an HTML table. And we now know a table in HTML is used for displaying data. And not for layout. But if we change the settings API into something semantically decent, a lot of plugins will break because they use the settings API for their own settings. This is difficult. If we need to change that, but if we do that, we have to work together with theme developers and plugin developers and do that all together to perform that very well, that the settings API is going to change. So that's something we need to work out. Another thing is consistency. Don't make me think. That's a golden rule in web development. Things should work the way you expect them to do, to work. That's not only for people with an impairment, very important, but also for every one of us. I want to give one example. Search in the admin. This is a screenshot of the search post. Do I have a light? No, I don't. You can see it with the arrow. Okay. The input field is on the right with the submit button. That's in most table lists screens. We're used to that. But in the themes, we want to add a new theme. Then it's on the left without the visible submit button and with the placeholder. If you want to add a plugin, it's on the right again without the submit button and with the placeholder. I don't know if I'm the only one, but I fill out the name of the plugin and I press the first button inside. That's the installed button beneath. So I installed Jetpack many times unintentionally and I'm really an experienced WordPress user, but I'm so used to having that button there so I press the first button inside without thinking. I don't want you to make me think. So that's something we need to discuss. How do we do that? How do we make stuff beautiful but also consistent and usable? Then we've got accessibility-ready reviews. This is not a code issue, but a workflow issue. If someone submits a theme to the repository, to the theme repository, she's very proud. I made this very beautiful theme and I did really my best and I also made it accessible so I add accessibility-ready tag. And then she has to wait for four months to get a response. And then, well, the response is way too long. What happens is all team authors abandon the theme. So all that's too long, I moved along, let it. Or they say, okay, well, that accessibility-ready review is taking so long, I will drop the tag. And this is such a waste of time and also such a waste of energy. There could be many more accessibility-ready themes in the repository if we could find a better way of how to deal with the reviews. This is not the fault of the reviewers because there are not many of them. We just need another workflow. Maybe automate this. If you have any ideas about this, go ask Joe Dawson. He's sitting over there. He's really interested in your help if you have ideas on how to speed this up. I want to introduce you to Eva Westerhoff. She is one of the leading accessibility experts in the Netherlands. And she's born deaf. And she has a message for you. Good morning, welcome, born, camp, Europe. I hope that you will have your pleasure having me, Eva. Okay, look at that. All the Dutch and Flemish people. And all the people know Dutch sign language. Okay. Really frustrating if you don't know what she's saying, is it? Thank you. I will subtitle it. Good morning, welcome, born, camp, Europe. I hope that you will have your pleasure having me, Eva. If you couldn't read that, she is saying, good morning, World Camp Europe. I hope you have lots of fun in Vienna. Accessibility is hard. Getting it right for everyone. Subtitles on WordPress TV. On May 18th, there were 4,648 videos on WordPress TV. Which has 246 subtitles. That's 5%. Come on. We could do better than that. If from now on, every speaker takes the responsibility of subtitling their own video or have someone subtitling their own video, that will be a huge improvement. I know it's very awkward to hear your own voice. And here you make all that mistakes. But you enlarge your audience. It's not only alone for deaf people. How many people are reading this because of my fabulous Dutch accent? Sometimes people talk very, very fast. So it's very convenient to read it back in English in text. Some people don't know English very well, but they can read it. So you enlarge your audience. So, that's a deal from now on, every speaker. This is all a work in progress. We're getting there. It takes time, it takes research, but it's work in progress. But then, some things in WordPress needs to be rebuilt from scratch. In my opinion. Guess what? The media. The media at the moment is not accessible for people with a keyboard or a screen reader. It maybe is if you are a developer and you know exactly what to do and what the underlying code is. But not for a screen reader user who doesn't know code and just is swimming around and doesn't know what to do to get a gallery or to add a caption to an image. This needs to be rewritten, rebuilt. This needs to be a feature project. So we can research, play around, see what's best, and then replace it for the current media. This will be very hard. It will take time and it will include several teams, like the core team, UX team, the design team, the accessibility team. Most teams need to work together. So this will be a huge undertaking. But I think to make it accessible and also sustainable for the future. It must also be beautiful. It must be usable. So this is a huge project and I think we should start with that. But most of all we need to keep calm and stay focused. If you are a developer we are living in very exciting times. Rest API. React. All the JavaScript we now need to learn deeply. If you developing like that, take a step back. Look at your work and say, am I developing for myself? Or am I developing for the people who are actually going to use this? I know this is very hard and it takes time and takes study. 25, 26% of the web. How many people are as smart as you are? JavaScript is not the enemy. We just need to work harder to get it accessible. It needs more research. That's enough for the preaching. Now for good news. The last two years in the accessibility team has been amazing. First thing that happened was that we had a team of developers sitting over there joined our team. He did a ton of work and research. He fixed a lot of issues in WordPress. He earned a commit status for that. Thanks to the work he did. Andrea, thank you very much. We have a web content accessibility guidelines. At the moment we are at version two. You have three levels. Level A, that's basic accessibility. AA is the global standard. Triple A is for dedicated software. So now in the core handbook accessibility guidelines are added. This is summary. John Blackburn also showed this slide. All a new updated code released into WordPress core and bundle teams must conform with WCAG 2 guidelines at level AA. And this is awesome. I'm really, really proud of this. So we are in Europe. Why is this important? Sorry for this bridge. Last month the EU agreed on a directive that all government websites and all public service websites need to conform with WCAG 2 AA. So now WordPress is getting ready for Europe. WordPress can be used for big projects in Europe. And I think it adds a lot of value to WordPress. So awesome news. If you want to know more about this and all the regulations, you can contact her. She is there. She has written an awesome blog post about this. It's in my blog post a link to that. And she will give an unconference talk this afternoon about this. So go with visitor and ask her if you know more about European law. I know this is very difficult for all of you. You have to learn accessibility. You have to learn accessibility too. So an accessibility wants to help. We are writing a handbook. It's on make. WordPress.org slash accessibility. There is a link to the handbook. We don't want to rewrite everything that's on the interwebs about accessibility, but that's undoable. It's on GitHub. We developed a JavaScript method called WP.a11i.speak. WP.a11i.speak. WP.a11i.speak. What you can do with this JavaScript method is tell a screen reader user what's dynamically changing on the site. Because a blind person can't see what's changing. So with this method you can tell the screen reader user what's changing from the site. If you have questions, please ask all your questions in the form and not on Slack because we got a lot of questions in Slack. Only you will get an answer and it will be lost in time. If you ask it in accessibility form, then everybody benefits from the question and the answer. We have a test team. photo, but we have 75 volunteers who test WordPress core for accessibility. And this is really, really awesome. They give up their own time. So if you write for core and you want your code tested or you have a question or problem, we can set up a test. We can give it to the testers, they report back, and we will report back to you about the issues or the problems or solutions. So use the test team if you write for core. To help you quickly on your way, I have three tips to improve your code. If you are a developer, one, use one H1 per page. And in that H1, tell what the page is about. This will save screen reader users so much time because they immediately know, okay, this is what the page is about. Two, if you are a designer, check the contrast between the background color and text. If you don't know how, go to the handbook or Google contrast analyzer, contrast ratio analyzer, then you can find the rules. And every functionality you build has to be keyboard accessible. If you don't know how, go to the handbook, Google it, or go to my workshop tomorrow, I'm giving that on the contributors day on how to keyboard test. So where are we now? I think we are on the right track. We really got the support of the community. And I'm so grateful for that. That wasn't the case a few years ago and look at you are here now. Thank you so very much for that. We've got the support of the release leads of most of the core developers. We're pristine developers are picking up accessibility themselves, like in the Genesis community. That's really, really wonderful. We don't have to do everything ourselves and explain people are actually picking it up. I also noticed that on the contributors days. The accessibility table gets more and more crowded. And in London, two months ago, we had an absolute dream team. That was really awesome. So I want to finish with the request and assignment. While you are learning JavaScript deeply, learn accessibility deeply too. Thank you.