 Oké, who's afraid of ARIA? On the slides is ARIA Stark from Game of Thrones looking very frightful, frightening. Oké, I'm Rian Rietveld almost. I'm a senior accessibility consultant at the level level. And I'm also a teacher at the level level academy where I teach all stuff accessible. The slides are on slideshare.net. Rian Rietveld. And I've got a code pen made for this. That's on codepad.io slash Rian Rietveld. Because I'm going to give some live demo screen reader stuff. Wish me luck. Oké, in this talk I'm going to explain what is ARIA. The first rule of ARIA. And if you are like me, I'm a developer and I like examples. Copy, paste, tweak. So I've got four examples of how to use ARIA the right way. And after that I will give you some good resources. So how you can start from there. So what does ARIA mean? W-A-I dash ARIA. That's the official name. W-A-I stands for Web Accessibility Initiative. That's a working group from W3C. And ARIA stands for Accessible Rich Internet Application Suite. So it's actually ARIAs, whatever. And this is the definition. ARIA defines a way to make web content and web applications more accessible to people with disabilities. That's a very broad definition. But what it actually is, it's all about giving feedback. If you are blind, you cannot see the screen. So what's happening on the screen? What happens on a page? What does it mean? How can I interact? But first rule of ARIA. I guess. Don't use ARIA. That sounds very contradictory. But it's not. And I will explain you why. Don't use ARIA to fix meaningless or incorrect HTML. If you say our accessibility is wonderful because we put ARIA on all the things, that's not the right approach. I will give you an example. Hamburger menus. This is a way to do a hamburger menu. About 50% of developers think that. You have a div. You give it an ID, for example, menu to put a JavaScript on. You give it a name menu and div. It works for you. All the JavaScript is written and it works with the mouse. And then somebody tells you, oh, but it also has to be accessible, operatable, with a keyword. And you go testing. And the div is skipped. A div doesn't get the keyword focus. Okay, then you add a tab index is zero. It gets keyword focus. But the JavaScript isn't fired. And then you throw in a bunch of ARIA. Roll is button. ARIA press is true or false. And then it actually works. So you have to put all that extra stuff in. But actually HTML5 has this wonderful element called button. So don't use this. This is wrong. Use a button. Because then you get all functionality for free. This is right. Semantics gives you it over free. Always go for HTML5 first. Learn HTML5 deeply before you learn ARIA, before you learn JavaScript. Because that's what interacts with your browser. Your browser generates, that's what interacts with your user. Your browser generates the HTML5. All your JavaScript, all your framework, all your PHP, what it does, it generates HTML5. So that must be correct. And that's what interacts with all the devices. And we get more and more devices interacting with your website. If you use code, semantic HTML5, then it works. It's all about feedback, ARIA. What happens on a page? What does it mean? How can I interact? Oké, I will give you four examples how to use ARIA in a good way. And the first one is ARIA expanded. Is something open or is something closed? If you can see, you can see that menu is open or closed. Or if you have an accordion that is open or closed. If you cannot see, it has to be announced to you. And that you do with ARIA expanded. En nu komt de demo. Wish me luck. Oké. Can you see the HTML? Or must I enlarge it? Who cannot see it? Is it good enough? Is it a bit larger? Oké, my glasses also. Can you hop? Better? Oké. We have a button. En de button has the ARIA attribute, ARIA expanded. En it sets to false. Below that there is a list. And the list is hidden. With the HTML5 hidden. You can use CSS, display none, whatever suits you best. And this is the JavaScript that belongs to it. You can all do that much better than me. I'm not a JavaScript programmer. But this is the basics. You have to toggle. You have the list. You set an onclick. And that listens. If the list is open or closed. And it toggles. So. And this is how it's done. And now I'll fire it. Command of 5. Voice over on Safari. Code paying. ARIA. Window. Board focus. A screen reader before. Oké. This is voice over. That's built in in the Mac. And you can use it the best with Safari. It's a very simple screen reader. But it's very good for testing. So. If I could focus on the ARIA expanded. List. Collapsed button. And now it announces. It's a list. It's a collapsed. And it's a button. So. If you interact with the button. Something expands. List. Expanded button. If I press it again. List. Collapsed button. So this is very useful if you have for example. A menu. And says collapsed. And you press the button and it's expanded. Then the blind user knows. Oké, if I tap further. I tap through the menu. If I choose not to open the button. I can tap further. For example to the content. So it gives extra information. Of what you can see. To someone who cannot see. So. This area expanded. If you want to. List. Expanded button. List. List 4 items. Bullet 1, bullet 2, bullet 3, bullet 4. Visited link. Back to home. So you give the user control. About what to read or not. Oké, I'll stop the screen reader. Voice over off. Area expanded. The next one is area live. Tell me what's changing. If you can see. You can see what's changing on a page. But if a page reload. Then you know oké. Something new is coming. But if you have a change without a page reload. For example if you have search results. And you do a search. And dynamically you show the search results. Without a reload of the page. If you can see you see oké. New search results. But if you cannot see. It has to be announced to you. En dat je doet met area live. So. Area live. For example. This is very brief. You have a submit button. And if you press it. It says changes. Saved successfully. You can see that. But a screen reader cannot. Announce it. Because it is not in the area live region. So you have to add an area live region. An area live region. This is the area live. Can you see this? This is the button. Submit button. And this is the area live region. It says area live polite. You add that div. And then the screen reader listens. If there are changes in that div. And you have two area lives. You have area live polite. Then the screen reader waits. And you have two area lives. And then the screen reader waits. Until announces. Until you stop interacting. And you have area live assertive. Then it is in your face. Immediately for example with severe errors. So. How does that sound? I will reload the page. Screen reader. Voice over on safari. Code paying. Submit. Now because of the area live. The screen reader announces. Changes safe successfully. So what should you announce? If there are new search results. Don't announce all the new search results. Because that's very annoying. You have to give the user control. But what you can do is for example. There are new search results. Or there are 24 new search results. Or there are no search results. Find another keyword for example. Edit text. Area live equals polite. Content selected. Voice over off. En dan in WordPress we have. Thankfully. The JavaScript method. WP Ali speak. That's built in into core. And you can use that. In handbook. Accessibility handbook. Oldwordpress.org. Is completely written out. How that is done. There is a link in the slides afterwards. I have a demo of that. I can show you how it works. This is a demo by Sami Kayone. And what he did. That's a filter. And there are cities. You can select a city. And below that he shows. For example, contacts in that city. Okay. Now. How does that work? Voice over on Safari. Wordpress speed. Menu. Tick. Heelsinki. Okay. I'll select contacts in Helsinki. Select city. Pop up button. Filtering contacts was successful. Sami chose to have a message. Filtering contacts was successful. So you know there are new search results. What you do as message is up to you. You have to say, okay, I will place myself in the search. In the position of someone who is blind. What information should I give? You can give other information. We have three contacts. But you can also say a filtering contact was successful. That's up to you. So. Voice over off. I will do an inspect. Of the code. I'll show what happens. You have to say if you can read this. I'll show what happens. You have to say if you can read this. That's div. Can you read this or enlarge it? Can you see this? Yeah? Okay. So. What the function does. The function does it adds two divs. On the bottom of your DOM. And it says a div. An area life is polite. And you have a div. Area life is assertive. En dan. With the JavaScript method. You can actually fill. That area life with what you want to announce. In this case. It's in the area life polite. It says filtering content was successful. And then because the screen reader listens to both. Divs. The assertive and the life. If there's a change in one of the divs. The screen reader will announce it. So that's area life. I will give the resources a link to the handbook. And there is a full explanation on how to do this. Okay. Area label and the screen reader text. Class. What you hear is what you get. I will give you a short demo. And then explain. These are four links. Are they large enough? Yeah? Okay. There is one without an area label. There is one with an area label. There is one with an area label. Edit my awesome post. But beware. There is also one. Delete label. Delete link with edit my awesome post. And there is the last one. That doesn't you lose area. But you use CSS. Okay. I will let you hear it. Voice over on Safari. Code pay. This is just normal. Edit. But if you cannot see. You maybe don't know what the edit is about. Maybe it's from the content in the layout that you know where the edit is from. But if you don't know that because you cannot see it, it's just an edit. So what you can do is overrule the link text with area label and give it an edit my awesome post, for example. Link. Edit my awesome post. So it still shows as edit. But it announces for screen reader as edit my awesome post. I will show you the code later. But beware. It overrules completely the link text. Link. Edit my awesome post. You see. Delete. But it announces something different. And now you can use CSS. My awesome post edit. I want you to notice. My awesome post edit. It's the other way around. It doesn't work. Okay. Voice over off. I'll show you the code. A bit enlarged. Can you already see it? Okay. The first one is just an A normal with the href edit. And the second one at the A, at the anchor you add area label is and then with the text. And it completely overrules. In the last one area label edit text and it overrules the delete. But then there is also the screen reader text class. With the screen reader text class this is a CSS and it looks like this. Then you can hide something from vision but you can let it announce for screen reader. You make it very small. You give the height is 1 pixel. And also width is 1 pixel because if it hasn't got a height a screen reader doesn't announce it. Margin minus 1 pixel. Position absolute. And that's the reason why Safari mixups the order. And you give it a wordrappist normal. And wordrappist normal means if it's Safari sees it's a very small space like 1 pixel. En we gaan de letters 1x1 En als je de wordrappist normaal dan is het een normaal woord. En dit is hoe de screen reader text lijkt. Je hebt een edit en dan heb je een span met de class screen reader text en dan mijn awesome post. Dus dit is wat is aannounced de span en de edit. Je ziet alleen de edit maar mijn awesome post is ook aannounced. Als je een area gebruikt en een label of de screen reader textklaas gaat naar je, het is op jouw situatie maar bewaren als je een position absoluut is, Safari mixes het op. Het eerst zegt mijn awesome post en dan edit. Het is heel ongelooflijk. De screen readers zijn niet perfect. Dus dat is de area label. En dan de laatste example area described by en area labeled by. Hoe voel ik deze vorm uit? Oh, de demo, ja. Als je bijvoorbeeld een vorm met een naam en een input field en je hebt wat extra informatie onder dat. Dat is heel speciaal. Like, please give your first and last name. You want to add some extra information. You want to give the user to fill out the form. But if you have a screen reader you tap from focusable element to focusable element in a form and then the extra information isn't announced. So they miss on vital information. How do you solve that? There are two different ways to solve that. With area labeled by that replaces the label text. An area described by that adds content to another element. For example you can add that to your input field. I will let it read. Voice, name edit text. We start here. Selected. Please give your first and name. Edit text. Name edit text. This is just normal. And the text below is not announced. Please give your first and last name. So now is the label replaced by please give your first and last name. And the last one, area described by name edit text. Please give your first and last name. Then it announces the label and it waits a bit. And then announces the area described by. Now is that done. Voice over off. So this is the first one. You have a label and a name. An input field. We all know now and everybody does this from now. If you have an input field you also have to have a label. And the label is connected to the input field by the ID of the input field. So you have an input field with an ID that's unique for the page. And a label with a 4 referring to the ID. That's the correct way to do it and then it's announced properly. Ok. Then you use label by. The text you have you want to announce with the label. You give an ID. You give an ID description 1 in this case. And then with the label you say area labeled by and you refer to that ID. It works the same with area described by. You have a P with an ID. In this case description 2. And here in the input field you add area described by and then you add the ID from the message you want to announce. So there's two different ways you can do that. I will show you how it works again with the screen reader. Aria name Without Please give your first and last name. Now it's replacing the label. Name Please give your first and last name. Now it's announced with the input field. Voice over off. For examples. So this is to give extra information to people who cannot see. What's happening on a page. This is not to repair en to fix broken HTML5. Ok, resources. These are the specs. Wai area authoriting practices. They are rewriting the specs. And this is very good news because the specs were actually unbreedable. But now they are giving examples good practice and more better text. So I'm really proud of that. They're really doing a good job in the W3C. So if you were burned out on the specs. I think this I cannot handle. Please go back. They really improved them. Then accessibility team has done a lot of work to give good reasons on the accessibility handbook. On Make Wordpress.org. And we've got examples of area of good HTML5 about the CSS class. And there's also a good documentation about the WLE speak method. In the slides there are links to these pages. And then there is inclusive components by Hayden Pickering. And Hayden has done a lot of research with different screen readers with different browsers on how to make inclusive components. Like how to do a tooltip. How to do a carousel. How to do a slider. How to do a to-do list. It's a book and a website. I would really recommend it. Here is using HTML5 and CSS3. And add area to that. So if you want good examples buy that book. And there's the DQ University. They have a website with free widgets and code examples. So read that. Take advantage of that because they also do excellent research. And if you want to study further Mike Gifford has a GitHub repository and with all kind of courses. Free, paid online, in-house there's a wealth of different courses you can take. So if you want to study further this is a good point to start. So I want to end my talk with a quote. Make it work before you make it nice. Thank you. Questions. I had so many questions but a few that came on mind was just a couple I'm going to ask you. Are all screen reader texts in English? Does anyone work to translate those? To localize them. Because it's text. So text must be also in language. And my other question is are screen readers the browsers of five years ago are they all different? It seems like every time we try to solve some issue it will work in two of the screen readers but not in the other one. And how do you solve that problem? Actually now we I'm sorry. He's asking I screen readers just like browsers from the past like they're all different. Yes they are. So I actually choose a few to test with and discard the rest. NVDA for windows JAWS for windows and voice over for the Mac. And now you have a new one, a narrator for edge that can do a little bit stuff. It's not so sophisticated but all the rest I just discard because it's not doable otherwise. And also you have to voice over you have to test with Safari because in Firefox voice over announces nothing. JAWS you have to do with I think internet score 11 I'm not sure about that but you have to pick the right browser also with the right screen reader. And that's making life not very more difficult. Sorry. I can't give an easy answer on that. I have a question over here. Thank you. Do you have any suggestions on convincing a larger company to invest in ARIA and more accessibility on the website? Google is deaf and blind and there's everything you do for SEO for accessibility is good for SEO Google can index your page much better if it's accessible. There's a legal consequence if you don't make your website accessible there are legal consequences especially here in the US. On the website from the W3C there's an excellent article about that about a case business case for your accessibility I will share that on Twitter. Yeah. But there are various reasons. Yeah. There is a user interface where there are controls in a sidebar and manipulating those controls updates the content in the main body of the page. How can we let users or screen readers know that that content has changed and how to I guess jump from those controls to the content to see or to hear rather that changed content. If you give the controls a good heading so that's really easy to jump to a heading and when you change something in the controls there is something changing in the results just new results found or the filter I don't know what it is. But do you need to have a way to jump to the content after it has changed? No, in the area life you just change you say what has changed but if there are headings or focusable elements they can switch between that control that you can link stuff together hardly no screen reader supports that so area controls is not really something to to use but people navigate with links and with headings so if both have a good heading they can jump from heading to heading Is that a good answer? Is there any penalty or conflict for using area hidden on items is it visible? Area hidden hides from a screen reader Is there any penalty to that even if you're remaining it visible to the scene public? Well if you decide a screen reader user doesn't need to know what's there you can hide it with area hidden but the penalty is like do you mean legal penalty or? No, I mean just is Google going to penalize you and why you're taking this whole text you're showing it to these people Google doesn't know area yet I don't know I'm not an SEO expert so I can't answer that Hello, thank you for the wonderful session When coding hyperlinks should I no longer be using the title attribute? Yeah, a title attribute should die Yes Because you only give the information about the title attribute to someone on a desktop with a mouse and someone on the tablet doesn't have it and screen reader users are not consistent of announcing area of title attribute some do, some don't some replace the text with it some announce it double so if you have a consistent user an accessible tooltip for example, or an area label if you want to replace it and make it more clear for the screen reader user Is that as easy as if I've been using title tags doing a global search for place and changing title to something else well title attribute if it's an additional to the link text well it may be sometimes it's just additional or some new information it depends on how it's how it's constructed in your case you can use area label to completely overrule it and give all the information in the link text and keep the visual link text the same but if you have or you can have an accessible tooltip instead of a title attribute and if in Haydn's book from Haydn Picker inclusive components there are examples of accessible tooltips Thank you Hi Are there any methods for delivering the area code in the HTML only to screen readers as opposed to everyone Sorry If you're outputting the HTML with all the area labels and code only the screen readers can use that Is there a way to deliver the HTML Well you can use maybe CSS to expose you know what I'm saying is like a sighted a person who can see has no use for area so why is the code being delivered to them in the HTML is there a way to split it so that sighted users get non-area HTML and why would you split it to make your code cleaner lighter pages well I think you have to offer the DOM to everyone it's not like you have to have this site is for blind people this is for normal people like this is very insulting I think I think you need to code properly So you're saying that's not a suggested method No, I think you have one DOM and you offer every functionality to everyone and some people can see a user screen reader so they have also the extra information so it's not like one user of more people having the advantage of that so I would suggest one DOM it's also easier maintainable I think Ja, that's why the questions Thank you