 Okay, so I don't see many people moving outside. We are almost ready to start. First, I just wanna mention a couple of things that I didn't mention yet. We have a code of conduct. It's available on our website and I would like to ask all of you to follow it. If you're not familiar with it, please stop on the website and take at least a quick look. If you see anybody, let's see any trouble, please report to somebody with a red shirt like mine. We are going to contact them quietly. Also, after this talk, we're going to have a short coffee break, which is going to happen in the lobby where you have all the sponsors and there you can also find some toilets. If you have any questions, please don't hesitate to ask me and without much further ado, our next speaker comes right now from Germany. She's going to talk about good and bad accessibility because right now she's a colleague of mine at Automatic. At the moment, she's working around integrating Gutenberg with Jetpack, but she's also done a lot of accessibility work on the new editor, so I think the next talk is going to be very interesting. Please welcome Alder. Yeah, so essentially, yeah, I titled this Make Your Gutenberg Blocks Accessible and also Web Accessibility 101 sort of inside brackets because it's mostly about that. So my name is Alta Vigtis Skarpietin Stohtir and for anybody who has trouble pronouncing that name or asks me how is it pronounced or what does it mean? Like, this is the meaning of the name. Don't call me that, by the way, but this is usually for just that, you know? So pronouns, see her and I work as a code wrangler at Automatic. You can find me as Alta Vigtis on most social media, so if you want to give me feedback after the talk, then you know, I'm on Twitter and my blog is AltaVigtis.wordpress.com. Yeah, so my first programming language that I used for real, aside from like basic and logo and stuff like that in school was PHP and I made a massive social network for my school with all the security faults and terrible injections that you can find back in 2002 and my first WordPress projects were like way, way back like 2005, 2004, I made a website for a music festival and as it became more useful, I had started switching from TruePole and other CMSs into WordPress, especially as custom post types came to be. And like, you know, way back, you know, we had to hack the core to get things working. There were no plugins and all sorts of fun things. And yeah, sort of six or seven years ago, I switched over to Ruby on Rails for the most part, mainly because not that I didn't like WordPress anymore, but I was starting to feel our WordPress work, especially good front-end services were getting undervalued over time and I was starting to get more auditing and clean-up projects that I was sort of hoping for. I was not, the designers were coming to me with a messed up HTML and markup and asking me to fix them instead of working it from scratch, which costs the same, by the way. And now I'm working full-time at Automatic. And my test and trial projects at Automatic took on usually a long time, so even if I've been only working for Automatic for the past seven months or so, I have been involved with the company in one way or another for about a year and a half, including everything. And like, if anybody wants to get some details about, you know, working in the public sector or the United Nations or at Automatic, then feel free to like, hit me up after the talk and we can have a conversation. So these are, yeah, so my, in the past I've contributed to the WordPress core and the Icelandic translation, which has unfortunately stagnated and I'm currently on the working group for the Transflag MOTC proposal to the Unicode consortium. It's a fun sort of zero, it's joint in combination. It's a fun and exciting project. But if you want to get to know like strange politics, get the silent treatment for 14 months, general ignorance, then I really recommend doing some work for Unicode. It's, yeah, it's very interesting. Yeah, so one of the steps towards working full-time with Automatic was a trial project that was supposed to take about a month. You know, they saw my resume, hey, you're interested in accessibility, like, hey, come work on the Gutenberg editor. People are complaining about accessibility. And yeah, there was a lot of controversy regarding accessibility in the new Gutenberg editor. And yeah, and I ended up working on a tiny thing there for three months. And just to spend some time, I started expanding into other things. So the project was about fixing accessibility issues in the publishing workflow, especially regarding replacing the date picker with something more accessible and like adapting it to designs and the workflow. And to be frank, like I switched over to the community site very quickly, like, and that's really where most of the work was going on. If it would not have been for the WordPress Accessibility Group, especially people like Andrea Freckja and Ryan Reed-Weld and all the valuable input from the rest of the Accessibility Group, I would not be here today. That's absolutely for sure. So my most significant work at Automatic has been Gutenberg integration in Jetpack. It's a project that we called Gutenpack internally and we started working on it very close to the release of Gutenberg. So for anybody out there who thinks that, you know, we had all the advanced knowledge or that Gutenberg is only like made to, I mean, I've heard these conspiracy theories about Gutenberg being like a way for Automatic to be ahead of the competition. Well, we were like just as frustrated and confused as everybody else. In essence, we have been developing blocks based on many of the source codes that we have. And I decided at least for the stuff that I was working on, for example, the related posts block to improve the markup and make things a bit more accessible without trying to break things. And in our case, the workflow is somewhat different than for like classic WP admin work. As Jetpack is extremely monolithic and the workflow starts with Calypso. So we start by making the admin site for Calypso with a JavaScript interface and then Calypso, as some should know, is the administrative interface we use on WordPress.com. And then we back ported the Gutenberg functionality over to WP admin. And at the same time, all the backend rendered blocks were made with WP admin in mind the whole time. So it's, yeah, so working with a monolith is can be a bit complicated but I've tried my best to sort of make that experience applied to others. So essentially my Gutenberg experience comes from working on Gutenberg components as in the publishing workflow and my work on Jetpack. So as this is a WordCamp talk and not just a, you know, short flash talk at the local WordPress meetup where I can assume everybody is like extremely knowledgeable about WordPress and you know, development in general. I'm expecting people with wide range of skills to be here and knowledge, et cetera. And as Gutenberg introduced new accessibility challenges to say the least by replacing the classic editor that was based on, you know, more than a decade of work and improvement over time. So many of us are faced with project management prioritization, especially if we work at agencies and we need to be able to justify accessibility work to our coworkers and our clients. So this is not only going to be a technical talk about how to make your blocks accessible and I will concentrate largely on the vice and then I would go into the house. The first part where I go into the basics of accessibility is more extensive than I originally intended and it's going to be the bulk of the talk to be honest. And it was written from the perspective of consultancy projects and website building in general. So yeah, I'm going to start with what I, chapter that I call web accessibility 101. So, web access, working on accessibility work is the practice of making websites work for people who have a disability. People who can't use a browser in a regular way. People who have mobility, vision, hearing and cognitive impairments, you know, have epilepsy which might be photosensitive for instance, have motor and dexterity impairments. So the common perception here is that we make websites accessible and that accessibility work is for those who are blind or deaf mostly. But the fact of the matter is that there is a much larger group that has a long-term disability or mobility issues that, you know, most of us realize and it's very common that we just think we, if you're doing any sort of accessibility work or accessibility audits that we go over things with a screen reader and if it works, then it works. So just to give a list of like some accessibility technologies that we have to account for, screen magnifiers, that's essentially, you know, programs that zoom in where the mouse pointer is or any other location on the screen. So the user can see an expanded image of what they're supposed to be looking at. So this is used for instance by people who have a hard time seeing screen readers as well that are commonly used by the legally blind. Jaws used to be a common screen reader on Windows and voiceover comes with your Mac. So you can run it in Safari quite easily and use, you know, tapping and it will read for you what you see. And there's one thing that I find really cool and that's a refreshable Braille displays. So it's, instead of having a Braille printer which is like a pop-up printer somehow, those are mainly used by those who are deafblind, those who are both blind and deaf. And yeah, they use touch to interact with their computers and their websites. Mouth operated devices for those who have mobility issues below neck for instance, this is a common device. Like it's like a joystick that you operate with your mouth essentially or you blow into a tube to click, et cetera, et cetera and keyboard navigation. Essentially a lot of accessibility works just goes into making websites accessible using the keyboard. I had an accident two years ago where I lost my mouse arm and it was the antidote just having to tap through a lot of sites and got to know that feeling of not being able to use websites in many ways in many cases or games even in a way that was originally intended. By the way, if you want to see something cool, this is a Braille display. So the user essentially touches the surface to read what's called read or interact with what's going on. If you know about or if you own or if you've seen one of these things, I have never seen one in person even if I'm following guidelines to work with these things. So actually being able to test one of these Braille displays would be an absolutely amazing experience for me. And yeah, there are things we need to consider other than just navigation and different kinds of disabilities. And for example, a color contrast between text and background elements. And this is something you can spot directly when your agency designer comes in and gives you that, you know, one, two gigabyte photos of your file and says, please make a website out of this. You can generally spot color contrast issues or potential color contrast issues. Let's say you have image sliders with like text on top. You can usually see potential contrast issues there. And there are things like user response times, time sensitive user interfaces, like typing in a two-factor authentication codes, session timing. You don't want the user session, let's say you're changing your password or whatever and you don't want that session to expire in just a couple of minutes because those with mobility issues may take a much longer time to type in or enter information, find a profile image or whatever than most of us who are not disabled. Also, accessibility guidelines like WCAG indicate guidelines about closed captioning and subtitles for video. And they specify that closed captioning should be on live video as well to include accessibility for the deaf. The problem here is, yes, there is technology for that in English and most sort of dominating languages, German, Japanese, et cetera, but for a small language area like from my country or origin of 300,000 Icelandic speakers, it would not make sense to do it. So in the regulatory implementation of the EU access, web accessibility directive, this has been sort of quietly dropped out in regards to live video. And just to give you some numbers, I looked this up last night and not giving any sources, but it's mainly like government websites that indicate these things. So WHO says that there are 1.3 billion people with disability worldwide or sort of disabilities. This could be mental disorders, this could be a witch, yeah, do you need to account for in web accessibility as well, ADHD, for instance. And mobility issues, et cetera, et cetera. The German numbers indicate 10.3 million with if you include both temporary and permanent disability, 7.5 million who are deemed seriously disabled according to the German government. Here in Austria, there was a poll made and instead of using official government numbers, people who were simply asked, a group of people who were simply asked, do you have a physical impairment or a disability, something like that? And that was 1.7, you could basically calculate that over to 1.7 million Australians, just about 20%. But at the same time, there are only like, given those numbers, there are 362,308 registered disabled in 2013 or six, just about 4% of the population. Other, and in my country of origin, Iceland, one, the general rule has been like, yeah, one of every five has a physical impairment in any way. So essentially, if you don't consider accessibility in your work, then these are the numbers of lost customers. These are the numbers of the people you were pusing out that you have to consider. And it's not like these people can do much about their disability. It's not like those people who are still stuck with an old worst internet explorer and could simply update their computer or update the browser, you don't just upgrade your disability. And those with disabilities, especially mobility issues, are more likely to do their business online or use e-commerce sites, especially if they can do it easily without much input, which is not always the case. So the proportion of the population that is disabled may of course be different from the number of customers who are on your, let's say on your online store than who are actually disabled in the society. So you may have more or less depending on how you accommodate to them. So essentially not supporting users with permanent or temporary disability issues is in fact a moral decision. Just as much as it is a business decision, yeah, you lose these customers, you could possibly write off, you know, five to 10% of your potential customers by not making your site accessible, but this is also exclusion. And there's also a key element. I mean, this is common in UI testing, you know. Sure, if you do actual UI testing with people, then they will give you feedback. Publish your website, ask people to come by or advertise it, you will not necessarily get the same feedback, people will just leave, go visit a competitor and they will not waste their days writing emails about how inaccessible your website is. It's a waste of time because you can always go somewhere else. Now for a very boring part, we're going to start out on legality and regulations on web accessibility. So especially in Europe, any organization on the national level in Europe, web accessibility regulations are generally based on the web accessibility guidelines from the worldwide web consortium called WCAG. They have mostly remained unchanged in 2008, but did receive a bit of an update last year. So I recommend checking out WCAG 2.1 if you're already familiar with 2.0. So the guidelines are essentially a list of minimal fulfillment criteria that is needed to receive a rating, ranging from, well, no rating, and then you have single-lay, double-lay or triple-lay and you need to fulfill certain criteria to get that. For example, having good enough keyboard navigation, having alternative content to something that is inaccessible, for example, good image alt-texts, and like I said before, when regulated on a national level, the regulations may skip things from the original guidelines. As an example, the original has a hard requirement for close captioning, which may be possible in English or if you're a large broadcast organization, but it really doesn't work in all languages or all regions or all countries. And like Icelandic or Faroese or Greenlandic, it would just never work out. And while WCAG is not a new thing, recent developments, especially with JavaScript frameworks, being under rapid development in the past years, I guess everybody here who has been working with JavaScript for the past, say, nine years, I mean, it's really hard to keep up with the development just there. So this has led to the attention switching really over to these new frameworks and those new work methods from the attention that accessibility was getting in the mid-2000s. So, but at the same time, there are other things like ViARIA that step in when it comes to what we call Ritz Internet Applications. And this means we have both new technologies to deal with more interactivity and we also have those increased regulatory remarks from the EU, for instance, to deal with at the same time. So if the organization or if your client works for the government in any context, it could be the municipality, it could be a non-government organization, then your website needs to have minimal accessibility. And the legal liability in question is not only moral, but it can also have financial consequences. National authorities may issue fines and even if it is not the case, it can also be dangerous waters to threat for agencies and consultants that work for public sector organizations. If you run an agency and an end user files legal action against your client, it may have a cascading effect on you. So you may become liable towards your client if you did not fulfill or advise on the legal requirements yourself. It's not necessarily common that, I mean, I've worked in the public sector and public officials don't necessarily know about all the rules they're supposed to follow. This is why you're hired as a consultant. And you may have clients that say, I just want a website, but I hope you're better than that. And it's very often just thrown out the window, maybe an SEO consultant comes in and replaces the accessibility work with SEO, but it should really hold at hand. And, but really like the technical depth that you collect by ignoring accessibility is the sort of, it's closer to borrowing $10,000 from Tony Soprano than getting an overdraft from your bank. And Tony Soprano is not a nice guy. So pitfalls and misconceptions about accessibility work. One of the things that I've seen on websites that are not in English is that labels are not translated into the original language. So you may have let's say a date picker or something at an airline. The website is in German, but all of a sudden the screen reader starts pronouncing English words with German accent and you can't understand anything. And one of the things is that if you use one technology like a screen reader to check a website, it doesn't guarantee its accessibility in any different context. Let's say contrast or closed captioning, for instance. I mean, there are other demands that you have to follow. And using a lighthouse, which is now included in Google Chrome, and it's a really good accessibility auditing test, it's an indicator, it's not an approval. There are some things you may need to review manually. And delivering an accessible website to a client does not guarantee the site owner is going to keep it that way. And this means that while maintaining a site, it's important to make sure that the content that is added later on, and if your client takes over the technical maintenance of the site and it's tax-heavy enough to install plugins or in sort of doing some advanced editing, then the accessibility may recess, in fact. Yeah, so essentially, we should make accessibility a part of our process, from the design phase to the development phase, and throughout the whole lifetime of the site. And I saw this on the street here in Vienna yesterday, and this is like, yeah, this is an accessible device next to a C Pro crossing, only for blind people, please. Yes, but in fact, good accessibility improves things that are not necessarily related to disabled users. Shirts and gins and web spiders may improve its crawling and prioritize your website, so you may get better rankings by having a very accessible site. And accessibility work may not be the same as SEO, but SEO and accessibility hold hand in hand. If you already have a code review process, then do include accessibility as a vital part of it and make sure not to dismiss or, you know, make it consider the nuisance at all stages. As an example, in the Gutenberg project itself, there was like a confirmation checkbox when you made the pull request about having taken accessibility into account in your pull request. But it was usually just brushed off as a formality, especially as things were getting rushed and everybody was like rushing towards a release. And as a general rule, the sooner you discover issues with accessibility in any project, the easier it is to fix them. Seeing and fixing them right at the design phase is far less expensive and problematic than later in the development stage. Even if the designer you work with can be annoyed or the project manager may get sweaty palms when you talk about any delay in work. And listen to feedback from users. Sometimes accessibility degrades over time and I've seen important submit buttons just disappearing from screen readers because somebody wanted to remove it from the tapping. So in essence, you are trusted by your peers and coworkers and your clients. You are hired because you're a specialist in your field and your input matters. It doesn't matter how much you know now, if you're interested in maintaining accessible sites then it does matter. So just to give you a list of useful tools and information, Lighthouse is now built into Google Chrome, I'm a Firefox person myself but if I do accessibility auditing then I switched over to Chrome. If you go to accessiblecolors.com then you can do this contrast checking and there is a playlist from Google on YouTube called Alicast which goes into the details of accessibility work and of course just reading the specs. You can basically like it's the first thing that pops up on Google. This is Lighthouse that is now built into Google Chrome and this is like the last website I worked on before at Yoint Automatic and it's basically saying, there are things to check out, there are things missing and things to check out manually. But hey, wasn't this a technical talk about how to make Gutenberg blocks accessible? Yeah. So in essence, there is really, this is all there is to know about keeping any online content accessible. If you are careful enough and not dealing with a massive monolithic code base and backwards compatibility issues. So shirts and jeans and screen readers will be your friends if you're sematic markup and if you're using technologies like a wide area may cause you more issues than you think you're fixing. Things like reinventing the button using a div is not really something you want to do unless you've really painted yourself in the corner. I do however recommend using the labeled by area attribute if you need to place a heading inside your block because as of now, it's not easy for blocks to know which heading level they're under. So if there is like eights two or eights three above the block, then that block doesn't really know which heading level it is in and therefore you can't really determine the heading level inside the block. However, blocks gave us an opportunity to read, do, markup and all the code, especially with the Gutenberg editor and compatible themes in mind. In the case of Jetpack and WordPress.com we have millions of users and sites with lots of functionality and hundreds of themes and we don't want to break them even if we want to improve things with potentially breaking changes. So it's an opportunity to pay back this technical debt to Tony Soprano especially for the accessibility issues that I've been talking about. And you can keep legacy sites backwards compatible by simply not changing the output of your short codes that you already have. So I've seen this in some plugins now that are claiming to support Gutenberg and it's basically saying, yeah, I'm rendering a block but it's actually a short code. And like I say, you're painting yourself in the corner by doing this because you want to stay backwards compatible with your old short codes but you do want to improve things in the long run with the block editor. One of the things that we need to consider in the blocks is unique IDs. So attributes like Aria-Labeled by they depend on things having unique IDs. And it's basically common techniques for accessible HTML in general like both for and ID. So if we have multiple elements with the same ID attribute, we end up in a bit of a mess. As IDs are supposed to be unique so the reference will always be towards the first element in your code with that ID. So even if it's a sibling that is referring to another sibling, it will always just go to the top of the HTML and find the first ID. For instance, like this is just an example of a div that I made last night where the div itself is referring to the name as the title for the div. So this is what you can use in your blocks for instance instead of specifying or inserting a semantically correct heading you can specify a span or a paragraph as a heading using Aria-Lables. But what if we have multiple blocks like this? Then we need to find the solution and that means we need a unique ID for the block itself or that instance of the block. In PHP, we use unique ID and it outputs a random string based on the current micro-cycle timestamp. So it's not cryptographically secure. It happens during runtime but it seems to be good enough for what I've used it for until now. And on the JavaScript and Gutenberg site, on the JavaScript side, you can use with instance ID which is a JavaScript class. So here is the PHP site in related posts in Jetpack. As you can see, I'm using a unique ID to indicate the unique ID for that specific instance of related posts. So if you have a list of posts and you have this block in it, then it will generate a unique ID. On the JavaScript site, it's a bit more complicated but you essentially, well, there is an error. This is essentially a screenshot from the documentation in the Gutenberg code base but you're supposed to import the compose as well. And this is how we get a unique ID for that specific block that you are working with at any given time. So you don't have to, and like I say, in both these cases, you don't have to worry about conflicting IDs in your blocks. And this is essentially the basics of how you make your blocks accessible without breaking everything. Yeah, so that's the end of the slides. Any questions? So I see that you have a lot of links in the slides. Where can people find them after the talk? You can go to altavictis.wordpress.com. I will scroll up here. So yeah, great. So after the talk, I'll upload the slides over to here and you should be able to find them on my WordPress.com block. Okay, so does anybody have any questions for Aldo? Right? Joe, please. Yeah, hello. I would like to know if the WordPress dashboard is also accessible or is going to be accessible, the back office of the WordPress? Yeah, exactly. I mean, that's just as important as having the website itself or the front itself to keep it accessible. And the WordPress WP admin CMS that we are all using has 15 years of history of accessibility work to it. And this is really what created this massive debate last year around the release of Gutenberg was that we were losing a lot of this work in the new editor. So there are accessibility improvements going on in the new editor. In the classic WP admin, you will have 15 year backlog of really good community accessibility work. So any other questions? Okay, come on, we have time. Ask something. Right? I've heard that it's important for users in the backend like also to, that they are presented the blocks in a way they can easily find and use them. And I've also been in the new WordPress version, there will be the possibility to arrange the order of blocks. Is that right? Yeah, so basically Gutenberg is coming into what we historically call the sidebar widgets. So this is also providing an opportunity to rework them as well. So that's really work that we can still copy from the legacy code in any case. So, yeah, this is already being done. Okay, so if we have no further questions, I have a last one. Tomorrow the contributor day, are you going to be around in case anybody wants to contribute to accessibility in Gutenberg? Absolutely, I'll be there at least in the morning and in the early afternoon. So if you want to ask anything else or try to contribute to accessibility in WordPress, I guess you can contact out later.