The PHP podcast where everyone chimes in.

Originally aired on

July 20th, 2018

075: Web Content Accessibility Guidelines (WCAG) 2.1

New accessibility guidelines are coming down the pipe that will impact our apps with the new WCAG 2.1. We chat about what the guidelines are and how we can start preparing our apps for them.

with


Web Content Accessibility Guidelines (WCAG) 2.1 Show Summary


Full Transcript

Sammy: [00:00:02] Live tweet going out now which is usually the beginning of every one of the live broadcasts I've realized, is talking about what I tweet I'm not tweet and where are my show notes, here they are. Thanks for joining us once again. I'm Sammy K. Powers and this is the PHP Roundtable. This is a live podcast of developers discussing topics that PHP nerds care about and the ultimate goal of this podcast is to learn a little something from each other. If you're listening live and want to be a little part of the shindig send a tweet to PHP Roundtable. I've got the notifications in front of me. Eric Eggert just tweeted the live now tweet. Thanks Eric. And we're going to be; he’s actually on the panel right now. So we're only going talk to these really cool panel here in just a second.

Sammy: [00:00:46] So the World Wide Web Consortium also known as the W3C is an International Standards Organization that has been creating official recommendations since 1994 and on June 5th 2018 a brand new official W3C recommendation came fresh out of the oven, toasted perfectly to a light golden brown. We're talking about the Web content accessibility guidelines or WCAG 2.1. So what is this WCAG 2.1 thing. It's the latest official recommendation designed to help us Web nerds make our web apps more accessible to those who need accessibility accommodations. So really important stuff and that's what we're going to be talking about today. So now that we know that we're talking about let's meet our fun loving panel. I have not met. I've only met like one.

Sammy: [00:01:30] I think it's just met Nic in person. But first time meeting a few other people and before we get started we're just sort of chit chat and I can tell this is a really fun loving group of people so I'm really excited to get to know all of them in a little bit better but where start off in no particular order. As always we'll start with Nic Steenhout. Nic is a web accessibility specialist with Knowability Inc. or Knowbility Inc. I should say. Right. Nic often speaks at tech conferences about accessibility. And he hosts the A11Y Rules podcast. Welcome Nic.

Nic: [00:02:07] Welcome. Thanks for having me.

Sammy: [00:02:09] Absolutely. We also have the retweeter of retweets here Eric Eggert. Eric works with Knowbility as well and the W3C to teach web accessibility. His work is best described by translating WCAG to human Welcome Eric.

Eric: [00:02:25] Hello. Thanks for having me.

Sammy: [00:02:27] Absolutely. We also have Tobias Nyholm. Tobias is the CEO of a Stockholm-based startup called Happyr. He also maintains plenty of open source libraries and is a recent member of the symphony core team. Welcome Tobias.

Tobias: [00:02:41] Thank you for having me.

Sammy: [00:02:43] For sure. We also have Glenda Sims who is the team A11Y accessibility lead at Deque. She has a infectious Open Web Evangelists active contriubuting member of the W3C WCAG 2.1. Welcome Glenda.

Glenda: [00:02:57] Howdy from Texas!

Sammy: [00:02:59] Woo Texas! We were just talking about the W11Y. I'm sorry W11Y. I don't know what that would be Wallabilality. This is A11Y and how to pronounce it. What do we say? A11Y. I look at it and say “ally” in the background but you were saying that some people do say that, right.

Glenda: [00:03:17] Some people say a-one-one-why, some people say a-eleven-why, some people say ally. And you know in this world of accessibility that's all welcome.

Sammy: [00:03:25] That's awesome. A nd they have A11Y Cats, that's right?

Glenda: [00:03:29] Yeah that's what Eric got on his T-shirt, right now very cool.

Sammy: [00:03:34] Nice.

Eric: [00:03:35] I'm not used to being t-shirt model. So excuse me for not having the right post or something. This translates terribly to a podcast, sorry!

[00:03:43] (laughter)

Sammy: [00:03:46] Yeah, the people who are watching, uhm are listening on audio are like “Wait, I want to see the shirts” So you have to go watch the video to see it. Finally we have Sandra Eriksson. Sandra is a web accessibility specialist at Funka in Stockholm. Sandra spends her days at the office writing WCAG audits and guiding her clients on how develop accessible Web sites. Welcome Sandra.

Sandra: [00:04:08] Thank you.

Sammy: [00:04:10] So we're finally getting to this topic. I'm really excited to jump into this as I was kind of preparing for this. I was kind of looking through all the guidelines and kind of really trying to get a feel for what WCAG 2.1 is all about. And before we kind of dive into WCAG I kind of wanted to… Well first of all what is WCAG… We've been saying wicked. I actually learned from Nic at whatever last conference we are both at and WCAG is pronounced eick-ag but in episode 69 we were actually talking about how you had these acronyms that don't necessarily have the vowel sounds to actually pronounce it like JWT.

Sammy: [00:04:46] We usually sometimes say Jawt, throwing an A in there. So WCAG, is it the most widely adopted way of pronouncing this, or….

Glenda: [00:04:56] That's the way I see it. And that's the way usually hear it, yes.

Nic: [00:05:00] I've heard it said wick-ag double-u-cag double-u-cee-a-gee.It’s a little bit like A-eleven-why or a-eleven-why or accessibility that as long as you know what you're talking about and pretty much everybody knows what you're talking about when you start pulling out those alphabet soup. So it's all good.

Eric: [00:05:23] Yeah I heard Australians say wuh-cag. So there's yeah you can say whatever you like.

Sammy: [00:05:33] I guess as long as it's mutually intelligible. That's the key is that we're on the same page. Exactly. What did I think. I think that's kind of part of the what the document actually talks about and we'll get to in a little bit deeper talking about making sure that things are mutually intelligible. I do want to kind of look at before we dive into the docs. Tobias and Sandra were working on specifically adding some accessibility things to the symphony's form themes. And I'm kind of curious from you what that process kind of looked like working together to add accessibility to an open source project like symphony.

Tobias: [00:06:14] There was a few months ago. The bootstrap 4 forms theme was [?] was announced. So we were working in Bootstrap 4’s forms theme and we were like hey why don't we make sure this is accessible for everybody, because everybody building symphony apps on Bootstrap should be a good good start on building successful websites. So I created a site where I showed all the items or elements of a Symphony form. And then I sent that website to Sandra and, Sandra, what did you do there.

Sandra: [00:06:44] I did do that much really because I think you had already done the hard work. I think I had a few opinions about a few error messages but besides from that I thought it looked really great. And yeah like you said it a few months ago now so. But I was just involved in a short period of time and in the end before the deadline so I wasn't really a part of the process that much.

Tobias: [00:07:18] I said the process was quite short. I mean I got some issues from you. You listed three or four issues like for example there is a make sure a remasters or properly properly shown. I mean there are message just in plain red and it's been hard to see plain red if you’re color blind.

Sandra: [00:07:34] Yeah it look like they have something else beside the color to point out there is an error.

Tobias: [00:07:42] So it's I think when I got the list, I added four or five requests with like just changing 50 lines of code. Those pull requests questionssaid here is what the accessible expert said, here is a reference to WCAG and they were fairly quickly merged. And since, I mean we did one thing we put the error message inside the labels because then when or you… Why did we do that?

Sandra: [00:08:10] We do that, because we do that because the labels are properly connected to each field and when the user has focused on an input field they will also receive focus on the error message, when there is one, so that is Funka’s recommendation to to do it that way. So that's why I recommend that as well.

Tobias: [00:08:33] We got quite a few questions Symphony to remove that.

Sandra: [00:08:39] Oh, that’s funny….

Tobias: [00:08:39] They were like “Hey, error messages shouldn’t be in the label because that's wrong”, they said they and tried to remove it with no particular reason.

Sandra: [00:08:48] OK, but if they don’t have any reason they should definitely be there.

Tobias: [00:08:54] I told them, no, no, this is actually intentional. We want the error message to be here because of this and reason, we need to document the code better to make sure nobody ties to make a pull quest to reverse the changes.

Sandra: [00:09:07] I suppose, it also depends on where you want to place the error message because it's very common that you want to play for error message a message underneath the input field. then it's much more difficult to embed it inside the label, honestly. Maybe I don't know. Yeah, I have to keep it that way.

Tobias: [00:09:30] Yeah. Because that was quite the process. So I said something to Sandra, Sandra reviewed it and then to make some fixes them then just rinse and repeat.

Sammy: [00:09:39] Cool. Now now I'm going to have to make sure that my next form that I play with because I deal with a lot of forms for some reason but now I'm going to play with this. Putting that error message in the label that's really cool.

Nic: [00:09:55] This is the thing is there's one way to do it. And yeah and one most frustrating thing answers is I give to a lot of people asking the questions about accessibility is it is “It depends”. You know you can do it that way. But there's there's other ways to do it you can put it in a paragraph after the input field and tied the paragraph to the input field with aria-described-by. Yeah, there's several different ways to achieve an accessible results. That doesn't necessarily mean you have to go one way it depends on your context.

Sandra: [00:10:28] That is very true. I think the main reason why we at funka at first hand do not recommend to use WAI-ARIA is that the support for WAI-ARIA in different screen readers is there is a lot. You would… It’s possible that you would have a user that has a screen reader that does not support WAI-ARIA correctly and then that user wouldn’t perceive that error message at all. So if you can't find other ways to do it using native elements you should.

Nic: [00:11:02] So, that is the first ARIA, isn't it. The first rule of ARIA is “Don’t use ARIA if you can help it”.

Sandra: [00:11:09] Yeah, exactly!

[00:11:13] That's interesting so I'm curious, just sort of on the same lines like talking about moving the error messages into the label to kind of make them more accessible. Are there certain common things you see in the wild that aren't accessible that could have a totally quick and easy fix to them that would make them accessible by just tweaking one or two things. And this is just to anybody by the way.

Nic: [00:11:38] Go on, Eric you're dying to say something.

Eric: [00:11:43] Well, I mean there are a lot of things that are like easy fixes. You know one of the biggest mistakes we see is the alternative text that is just not there. You know when you have an image you have to describe it for people who can't see it. Another thing is is fonts and buttons and keyboard interaction. So when people navigate the site using assistive technology, so a screen reader or a switch input, and you can google what that is. It's really hard to explain but it's it's quite interesting so it's basically one big button where you can move around on the page. They are basically using the website using the keyboard only so they don't have a mouse attached and they don't use the mouse. So you have to make sure that everything works. Also with the keyword. And those are the big things that we see that are really like mainstream things that are um ah yeah that are basically broken by web developers every single day because, a standard HTML website is pretty much accessible. And then you basically take out the accessibility because you do something fancy and you forget to fix the stuff that you changed. And that's where WCAG comes in and gives you are good guidelines where you can test your solutions and say: does this conform to WCAG, does this are really meet everything I need to think about in terms of accessibility.

Sammy: [00:13:26] Interesting so it mainly without doing all the fancy things were mostly Sybel by default when we stick to the old 1990s way of doing things. But once we start getting into the latest and greatest thing that generates all this insanity and on the front-end then we start like losing accessibility right.

Eric: [00:13:43] Yes. You can say it like that. The core of every web technology that id developed is accessible. I mean is not developing anything that is not accessible in its core. And of course you got so many things that you can do with javascript and, you know, modern coding techniques that you can use stuff differently than you intended, than it was intended. And that can create issues.

Glenda: [00:14:11] And the way I think about it is that if you use the native elements accessibility is a freebie. It's already in there. If you're going to you develop something from scratch you now own the responsibility to build the accessibility. And so it's not you can't do anything fancy it's just you just took responsibility.

Sandra: [00:14:36] That’s very well explained, I think.

Sammy: [00:14:38] For sure, for sure. I'm curious just sort of before we jump in I do want to jump in to WCAG officially but there is one other question that's kind of related to this: On the flip side of what I was asking about was what's easy to make accessible. Are there things that are particularly difficult to make accessible on the web.

Glenda: [00:14:54] So I'm going to answer that case. I first want to say that I love the ones that are super challenging. And so when I think about accessibility I like to start with the really hard stuff like can a blind person drive a car? Not have the car drive for them but can they drive that car. Can you make a museum accessible. Okay. Those things are hard. And in that area the things that I find the most challenging right now are virtual reality. I haven't quite figured out how to make that accessible and highly visual games. There's a game on iPhone and Android, called black box, I dear you to go download it and play it. It is so visual. It's accessible. So you know I think driving a car by yourself, and virtual reality, those are hard ones.

Nic: [00:15:47] But the other thing is that most of the people that are going to listen to this podcast there are developers and I have yet to meet a developer that doesn't like a coding challenge. So instead of thinking about accessibility as a hey it's difficult, it’s such a chore. Why don't you look at it as a coding challenge. You have parameters to play around. And there you go. There's your coding challenge. Force yourself to do something you don't normally do and make yourself better, develop your skills and you're going to find out it's actually quite fun.

Eric: [00:16:23] Yeah that's that's a good point. The other thing is that we see a lot of people doing experimental stuff like you know really big like the sliders on the whole page or infinite loading Web site and stuff like that. And that can sometimes be very hard to make accessible because of the underlying technique used. But in reality 99 percent of all work is the basics, you know, is forms, is links, is a good document structure. And let's concentrate on that before we think about what is really hard because you know that's the bulk of work that needs to be done.

Sammy: [00:17:03] For sure, for sure. Well this has been good. I want to start diving into Wicca. But this is the not the the first WCAG we've seen. This is 2.1 that we're talking about. There is a decade old WCAG 2.0, so how is WCAG 2.1 different from 2.0, is this like a complete rewrite or is this like just sort of an addendum?

Glenda: [00:17:23] It’s 12 new requirements added on to the already 38 requirements that are in what WCAG 2.0, and when I say 12 new requirements on top of WCAG 2.0 38, I'm talking about at the A and AA level. So what WCAG 2.0, even though it's a decade old is solid as a rock still what you want to do. And then we're adding twelve more requirements on top.

Sammy: [00:17:53] Very Cool. So you mentioned A, AA, and AAA. What what are those things?

Glenda: [00:17:59] So when they first wrote WCAG 2.0, they wanted to break it into levels and it giving people an option like perhaps you might just go to the first level and say: Alright I'm going to unlock the door for some people with disabilities and let them in. That single A, like if you don't do single A you've basically left the front door locked and nobody can get in. Double A is taking more disabilities into account. And everywhere that I've seen, internationally, in the U.S., everybody's requirements are A and double A, when we go all the way to Triple A. It is… There's some stuff in there that's really fantastic to do. But it may not be something that we can all do. So Triple A becomes things you win competitions on or you're like super cool.

Sammy: [00:18:55] Very Cool. So I'm curious if WCAG get, I know it hits a wide spectrum of different disabilitys and different devices. Is it, does it touch anything with tech touch devices or anything like that.

Glenda: [00:19:13] Yeah. What can see point one is the first time we got to pick up touch devices because when WCAG 2.0 was written it was finalized and published in 2008. Right. Do you remember what your mobile devices looked like in 2008. They were like candy bar phones, y’know. And so that was just added. That was one of the big adds in 2.1 Is to pick up mobile accessibility needs as well as low vision. And one cognitive, we go a long way to go on cognitive. But we did get one added.

Sammy: [00:19:50] So if we're just starting to make our websites more accessible the first time we've looked at WCAG do we want to start by looking at 2.0 and then moving to 2.1 or should we just start just looking at 2.1 straight away.

Glenda: [00:20:01] So Eric and Nic, what do you think. I knew it I think.

Eric: [00:20:06] Well, you know WCAG 2.1 includes everything from WCAG 2.0, and I think that's something we need to reiterate and reiterate because it's something that hasn't sunken in with a lot of people. So I think if you really want to make your accessibility stuff you know future proof you should dive into WCAG 2.1 Immediately and take it on. You can you can take the 2.1 stuff on the side and to give that a lower priority but you should have it on your radar because you know here in Europe, for example, the the legislative stuff is moving relatively fast to adopt WCAG 2.1. So there might be regulation coming at you and then you've got to look up from other people who are still a decade… a decade behind. You know.

Nic: [00:21:01] The thing is that 2.1 is adding a few things but it's not it's not really technically demanding. I had the pleasure of working with Goodwitch to help make sure that my accessibility rules podcast was actually 2.1 compliant. It was one of the implementation Web site for 2.1 going forward and it's not that difficult. Sure you have to think about things a little bit differently from what you know choose to think about that. But why not do it. Is there it exists. It's a good guideline. And ultimately I would hope that people are interested in implementing accessibility because they want people with disabilities to be able to use their sites not because they want to be able to take a checkmark and say hey I comply with 2.0 AA or 2.1 AAA or whatever. So it's really more about helping us understand how to code our sites to make sure move more people can then can use them.

Glenda: [00:22:12] And the cool thing about WCAG 2.1 is that it's picking up on some areas that like Nic said just broaden your market so much because low vision. There are so many people with low vision. We all have low vision when we're trying to use a mobile device in a highly sunshine vicinity, where you got tons of glare and then mobile devices and speech as input. Back when WCAG 2.0 was written speeches input was not very common but we talk to our devices all the time. So there's some important things in there. And for the record nobility and Nic's work with the A11Y rules, Funka and Dequeue where already WCAG 2.1 compliant. In other words: we're doing it. I have… I have customers… Oh! Funka’s is AAA: Very cool like that.

Sammy: [00:23:16] That’s awesome. Well if we were if we were to go look at 2.1 on the Web site it is really long page. It takes a long time to scroll through, so might be a little daunting.

Nic: [00:23:26] Try printing it.

Glenda: [00:23:29] No, don’t.

Sandra: [00:23:30] Think about the environment, please, don’t print it.

Sammy: [00:23:33] Absolutely, the funny thing is there's as long as there are pages there's technically only 13 official guidelines right within the whole document.

Glenda: [00:23:43] So guidelines aren't measurable. So when I saw your question about the guidelines I think that's a really good way to think about it from the high viewpoint. But if you're actually going to test, and I'm sure every other expert on these calls agree with me we don't just stay at that high level conceptual, we go down to the individual success criteria of which there are 38 of those checks success criteria in 2.0 and twelve new ones in 2.1 If you're going to the level so, it's more, it’s 50 checks.

Eric: [00:24:28] Yeah, I like the guidelines because they give you the overview, like erm like something you can aspire to or you know. If you got the guidelines and you say okay that's that's actually what I'm working towards. And you got stuff like adaptable distinguishable. You know those are really catchy words that can guide you through a designing or devlopment phase of your website and that can help you to to have your thoughts. And then you look into the success criteria which give you stuff that you can really test on. So for example before adaptable it says ah make sure that you can orient your phone or your device in any way you like. You know and your website doesn't break when you when you rotated it to landscape. And that's that's important but you know that's adaptable. And once you read through it once you probably got that in the back of your head and you're done you know you don't fix that into one orientation.

Sandra: [00:25:29] Personally I rarely use the guidelines that much because from gas developed our own set of requirements that corresponds to WCAG in different weights. For instance there are one of our first requirements is that you you should use techniques that can be used in an accessible way or you should code forms correctly or whatever. So I use those more than looking at the guidelines but sometimes I have to go back to WCAG and to read reading to what WCAG said exactly in order to make a good judgment on how my client responds to it. So for me our requirements are a bit more specific to measure.

Eric: [00:26:21] And I think that's that's a good and valid point and I don't want to get into some sort of place saying that but in reality you know the WCAG 2.0 and 2.1 success criteria they are written in a way so they can adapt to a lot of different circumstances. For example to kiosks or banking terminals or mobile phones, so they can apply to all of them. And then we got the techniques where you get the technical details that you can, how you can implement something. And that's another level deeper than it gets into really a lot of additional guidance and a lot of many more pages, if youj wants to print it, so please don't.

Sammy: [00:27:10] Yeah, the success criteria. That's pretty interesting. I was reading through those and it's like it's like OK so here's one success criteria and it gives you one A basically, right. For this guideline but if you want to take that guideline and make it even more accessible, here's a double success criteria that you can try. It is that kind of the philosophy is that like the more success criteria that you can apply to your Web site the deeper down the accessibility rabbit holes validation you get, or?

Glenda: [00:27:37] So what happens is when we're trying to reach consensus on what's reasonable to say as a requirement, because we understand that WCAG 2.0, WCAG 2.1 and future WCAGs often get adopted into legislation. And so what you're going to see is at the A level you're going to see you've got to do this and then at the Double A level, Let me be frank, the stuff that the double A level is if you don't do that you've locked people out with different disabilities. So they got lower level in the first version. If I were in charge there would be two levels: The “I need to do this” level and the “I want to be better” leve, because AA really isn't like a nice-to-have if you've got low vision if you've got some of these mobile ones you it's just not work. It's not until we get to the triple A where yes, you're getting the color contrast has to meet this requirement at the required level. But if you want to be even cooler, go down to AAA, not all SC even have that, not all success criteria have “nd here's the deeper”.

Nic: [00:28:54] I like to use an example that people can really almost touch. It's like when you're building a house if you were to look at a single A level. It would be basically make sure you don't have a step in front of the door. So a wheelchair user can get in. At the double A level it would be make sure your door is wide enough for all wheelchairs so that you can have a no step entry. And then that's accessible for people that use walkers canes and wheelchairs. But a double level the suddenly someone who uses a power wheelchair, that's a bit wider, than they too can get into the house. So that's one way to look at it.

Glenda: [00:29:38] That’s a good example.

Sammy: [00:29:39] We should really be shooting for double a at least and then hopefully get to trieple A eventually, right.

Glenda: [00:29:47] Triple A, I actually think most people just picking she except for full got just like. And they just AAA do it.

Eric: [00:30:01] Yeah but you know if you're picking up shoes from AAA it depends on the content you have on your site. So for example AAA has stuff like live captioning for live streaming video if you don't have live streaming video on your site you don't have to you know whip up you get to know you get that for free because you're using it so you don't have to make it accessible.

Nic: [00:30:26] Sammy, I bet but you didn't know that you needed to provide captioning for this live podcast, did ya.

Sammy: [00:30:29] I didn’t until like yesterday when I saw that. I'm like oh this is embarrassing… I’m having a live stream about this very topic.

Glenda: [00:30:39] I can help you. It was really neat because the environments for humans used to hold the accessibility summit. And I helped them figure out there's the reason for live captioners and oh it was it was fun.

Sammy: [00:30:50] That's awesome. That would be so cool. Yes.

Glenda: [00:30:53] Captioning is really not anywhere near as expensive as most people think. I will admit live captioning is a little pricier but when it comes to captioning something that's recorded. You can outsource it and it's really reasonably priced. Cool. That's that's good to hear.

Sammy: [00:31:10] Yeah definitely. So this is like a spoiler alert for. Maybe in an episode we're probably going to have in about two or three months with Nic again bringing in Nic to do a live accessibility audit of the PHPRoundtable.com web site. It's not designed with accessibility in mind, it was just like it was just get it out there fast because I'm busy but then I need it. This is embarrassing to have actual episodes about accessibility and then not have an accessible website, like that's kind of like that's kind of that's not okay we're not actually doing this live that other people can maybe hopefully be inspired by like oh it actually isn't that hard or like oh I had that same problem.

Eric: [00:31:46] So yeah, we love to guilt people into updating their websites….

Glenda: [00:31:50] Inspire! Inspire them! (laughter)

Eric: [00:31:50] In English it's only my second language. So I… (laughter).

Sammy: [00:32:06] Well, so diving down into this WCAG document. It's really long but it is broken up into you four primary principles: perceivable, operable, understandable, and robust. And this really helps digest the guidelines a little bit easily a little bit more easilier. Well a little bit more easilier a little bit more easier.

Nic: [00:32:26] Is english your first language, Sammy.?

Sammy: [00:32:31] It’s not, it’s not, I’m actually linguist, believe it or not. So I was thinking maybe we could just go through each one of these guidelines or principles. I don't want to say guidelines, because they're not guidelines, the principles that encompass guidelines and kind of you all’s thoughts on maybe where you've seen these in the wild or just kind of just some examples or something like that just kind of give people a good idea, like, the higher up view of what WCAG 2.1 is all about. So starting with perceivable, the little little one sentence thing is information and user interface components must be presentable to users in the ways that they can perceive. So this means provide text, like we've mentioned before, text alternatives for non-text content like images and things like that provide captions and other alternatives for multimedia which we were just talking about, create content that can be presented in different ways including by assistive tech including by assistive technologies without losing meaning which is an interesting one and make it easier for users to see and hear content. We kind of we're talking about this one a little bit already but it gets a little deeper then kind of that the higher up stuff that we've been talking about right.

Glenda: [00:33:42] So what I love to think about perceivable is that we're trying to make sure that the content of our digital content can get into a person's brain. It's perceivable even get it into your brain. And what are the new requirements in WCAG 2.1. We had a color contrast requirement in 2.0 but it's only for text. And so if you have anything important on your Web site that's not text that's an image maybe you got the picture of a printer to print something but there's no words around it. There's no requirement that that printer be visible. It can be the lightest Grey. On another light gray where a 20 year old with 20/20 vision can see it, but the rest the world is going “what? what?”. So that's an additional requirement that I'm happy to see in 2.1 – make those important non-text objects have decent color contrast.

Sammy: [00:34:51] Very cool. So Perceivable is the first of the four principles. We have another one operable user interface components and navigation must be operable. Now these by the way these little bullet points I'm taking from are from the weekend to point one at a glance page on the W3C website. It's… do I say that right, W3C. I always say either WC3 or W3C….

Glenda: [00:35:18] W3 – World Wide Web Consortium.

Sammy: [00:35:21] I switch the 3 and the C around all the time without even knowing it. So I at least had to double check to make sure it's clear but there is a Web site or a page out there on the website that's called to one at a glance we'll get a link to an it so you can see all of these bullet points in front of your face. But ahm for operable, it says these guidelines are make all functionality available from a keyboard which I guess removing like. I think it's really popular back in the day to remove the focus attribute or the focus using stylesheets, right because it gets people didn’t like that little outline that happened when you click on things.

Nic: [00:35:54] Funny thing I was actually just speaking with Eric Meyer for my podcast last week and I discussed that with him because he he admits to one of his sin. He wasn't really thinking that people wouldn't read the notes and the CSS reset stylesheet. That said you know we're setting that to zero but it's up to you to design it. But people weren't going back and redesigning it so he removed that from his version two of the CSS reset but then it was too late. It was… It was adopted Bootstrap and to Wordpress and everybody thought “Ah well if Wordpress does that then we should do it” and it became a really massive pain point for from an excited keyboard user's perspective. So yeah. If you have links dont remove the default outline. Just dont. Really, don’t do it!

Sammy: [00:36:59] The other point operable. Always give users enough time to read and use content. Do not use content that causes seizures or physical reactions which is one that they feel like comes up… Was it the Incredibles, the latest Incredibles movie has has a problem with people who have seizures can't watch can't watch them the movie. So it's not an accessible movie. That’s really weird.

Nic: [00:37:27] One of the things to consider is that it might not be a promo triggering a full hour grand mal seizure but it can be as simple as someone is going to get so nauseated that you have to go lay for an hour or two. It's it's a wide range. We shouldn't always think of the edge cases of someone is going to fall flat on the ground and flip like a fish out of water. That's that's not it. It can be a whole range of different reactions that are pretty disturbing. Uncomfortable reactions so it's it's something we don't want to do.

Sammy: [00:38:02] Totally.

Sandra: [00:38:05] And I suppose in some cases you don't even need a disability to get affected, it enough being burned out or something. Yeah.

Sammy: [00:38:21] Absolutely. Well the final two guidelines under operable: Help users navigate and find content and finally make it easier to use inputs other than the keyboard. Now that's an interesting one because I guess just without actually diving into that when I haven't looked at that one in detail but just thinking of how many times I've tried to hijack an input to form a credit card number or format a phone number something not even really knowing if that's going to work with out a keyboard. Do any of you have any particular experience with making sure that the inputs work with something other than a keyboard or any thoughts on that.

Glenda: [00:38:56] Absolutely. When was the last time you talked to your car. Did you use a keyboard when you were talking your car and telling it where you wanted to go. No, you were using voice input. So voice input is a wonderful example of not using a keyboard. There are many others.

Nic: [00:39:17] I know someone who was a star skier and she skied into a tree and became paralyzed from from the neck down and she uses a technology called sip and puff. Basically it's a straw and she sips and puffs in different patterns and that allows her to control a wheelchair going forward backwards, stop, turn, what not. She also does solo sailing so she goes into a sailboat and she controls her entire sail boat with that sip and puff technology. She says one of the biggest frustration she has is some website will just not work with her sip and puff access to you know she's basically using a switch a variation on keyboard and she can't use Web sites and she can sail across the Channel between France and England by herself in a sailboat. But she can't use your website.

Sammy: [00:40:17] Wow.

Glenda: [00:40:20] That's a great story.

Sammy: [00:40:21] Yeah. Well looking at the third of the fourth four principles: Understandable. Information and the operation of user interface must be understandable. And so there's three main guidelines under this which is make tax readable and understandable make content appear and operate in predictable ways and help users avoid incorrect mistakes. This one almost feels like just more more like just improving user interface design for everybody. Right.

Glenda: [00:40:58] It is.

Eric: [00:40:59] Yeah you can totally see that. So a lot of accessibility improvements help everyone, You know. The difference is that for people with disability it's really really really important, you know it's, because they otherwise have big barrier and probably can't overcome it. So yeah I mean everything that is in the section is giving you time to to make sure you have put in the right data and and everything is described nicely and in a way that you can, you can understand that that's really important and that you know where you are in a process. When you're out in the shopping cart that you can clearly and easily and simply identify where you are and what you need to do next.

Glenda: [00:41:53] My favorite experience when I was working at the University of Texas at Austin and working with Dr John Slatin, who was a blind professor. I would go and test our new website redesign with John and what I would learn every single time is that we had a fault in our early designs that he would pick up on faster than any sighted person. And for him like Eric said that fault in the design and the accessibility problem would be a barrier. Once he pointed it out to me I would go: Oh it would be better for everyone if we redesigned that. And it might have to do with an error message that you know sighted people are like: Oh what just happened… Oh!. You know, and but for John he would go: Glenda I don't know it happened and it was wall.

Eric: [00:42:50] Yeah and I think it's also important to are follow the three principles that you already named. It's really important that those are principles that are not only are are addressable in the code, you know. You have to you have to start from the beginning from the design stage from the planning stage. Like when you have life video you know who is doing the life captioning, as an example, or who is doing the captioning afterwards. If you want to go to AA. That stuff is a way where you have to come in and you have to plan and manage your accessibility. And it's not just throwing a line of code somewhere. That's not how that works.

Sammy: [00:43:37] True, ture. Well moving onto the final principle: it's robust. Content must be robust enough that it can be interpreted by a wide variety of user agents including assistive technologies and the guidelines that maximize capability with current and future user tools. All right that's compatability: Maximize compatibility with current and future user tools. So what? I'm not. I don’t know – I don't quite understand what specific examples or what kind of what this one's kind of shooting for. Then it seems like you just kind of want to make sure that you like we were talking about earlier with where you put the error message, putting it inside the label seems a more robust way versus using the ARIA tags, is that kind of what robustness is shooting after.

Glenda: [00:44:25] So that area down there when I think of it there's there's two main pieces in 2.0, and that is did you write your code according to standard, can it parse correctly by assistive technologies or any technologies that we are not even aware of yet. So one of the recommendations, I bet Funka does it, is validate to the HTML standard. If you're writing HTML, validate to the dang standard. So that's the first one, it has to do with passing. And then the second one is name role value. Remember when we talked about the responsibility of the developer when they decide to build a widget. If you were gonna use a form control, a radio button, something like that and you're just gonna use native HTML, everything's already built in to that radio button from HTML. But if you're gonna build from scratch using a div and javascript then you've got to give it a name and a role and a value. It is a button and what is its role here and what is its actual value. Those things don't come for free. So that area down there is for when you're building from scratch.

Eric: [00:45:37] Yes. And you also have to think about the proper use of the keyboard. So building an input of whatever from scratch you have to follow the aria authoring practices document that has like really outlined what you need to implement in javascript to make it work like you know the same thing on the desktop or built in HTML. And that's usually a lot of work. So better use the stuff that's written in the first place. That's what I always recommend. And in 2.1 there's also status messages, which is new, right. So can you talk a bit about what that does.

Glenda: [00:46:24] So status messages if we interpret many of us that are already in love with accessibility have already been making status messages, error messages apparent to screen readers by default. But WCAG 2.0 only said the error message must be available in text, which means a developer can throw an error message on the screen and not tell the screen reader, the person who is blind that that new content has been added. So you and I saw it because it was big and it was bold and it made the page kinda changed. But the screen really user it happened above where their focus is. How do they know to go easter egg hunting for it up there. And so the new requirement on any new content that truly is a status message that you would need to understand to know something was successful or there was an error or to move forward in the process. You now have to programmatically make it possible for assistive technology to know: new content here. It's up here.

Sammy: [00:47:29] This was sort of like a flash message, so like you a create something and then it refreshes the page and it has that new status message at the top. It's like a flash mess is only there for that one session. You like programmatically making sure that assistive technologies can see oh that's the message they need to see on this page?

Glenda: [00:47:44] And whether it's a toast message that pops up or one that just occurred above where you are because understand a screen reader is working linearly so they were down at that submit button and when they try to press submit and the page didn't submit because they had error and you threw in the error message up here. Their focus is still down on the submit button. How did they know that error message got added there. You and I see it because it was red and flashed at us. Or maybe we saw it. How many times have you been on a form where you are like enter, why wont this enter? And it’s like there's a little error message up there but it's so like not paying attention. So the cool thing is, while I just described it from a screenwriter's perspective. There's a big cognitive perspective here. Help me, help all of us, understand where this new content changed. So that's what we get into the fun stuff when it's not just helping one disability type, but actually makes it better for all.

Sammy: [00:48:49] Yeah. I think that's a really really huge selling point especially when talking with shareholders and being like hey like we need to go through and you know make this more accessible and they're like well we don't have anybody that needs that. No, no, no, let me talk about how this improves the overall user interface and experience for literally every single person who views this Web site. That's the core selling point.

Nic: [00:49:08] You know the other thing on this we don't have anybody who comes to our site that needs accessibility. Way back when I lived in Chicago and I found a mechanic, he was brilliant. He fixed cars quickly. He was honest, he wasn't expensive. The only problem is you had a step in and Transend to tours is right to his office. And third time I went to see him as a pet. You got to put a ramp in and he says why should I put a red in. You're the only person in a wheelchair that comes to see me. And I said Pete, look at the step. Why do you think that is that nobody in wheelchairs come to see you. And suddenly I that a penny drop. It's like oh my god. Spent three hundred dollars put in a ramp into his office and suddenly I was able to refer him a dozen other people in a wheelchair that needed a reliable mechanic. So you know sometimes maybe you don't have anybody that has a disability because they can't get in. Then again on the Web we don't have any metrics. We don't have any way to measure who comes to our site with a screen reader who uses keyboard only, who is colorblind. We don't have that information so we can't assume that we don't have anybody any visitors or even any of our staff that don't have disabilities. I know I know actually web designers are colorblind you know and it seems weird but, we're out there people with disabilities, we're out there. There's 20 percent of the population that has a disability so you can't say oh nobody with disability comes to our site because you just don't know, right.

Sammy: [00:50:54] You may have just locked them out, like you said, like they are not there because you locked them out.

Eric: [00:50:59] Yeah yeah. And from my experience, a lot of times accessible solutions, once they are found by someone they spread around like wildfire. So one of the conferencing options was very is very accessible. And now everyone is using them because it's such an accessible thing and it just you know it just spread around so it it makes sense to be implement it and just, you know, make make a point of catering for, not just for, you know a majority.

Sammy: [00:51:34] For sure, for sure. Well this has been really good. We do have to kind of wrap it up because it's getting close to that wrap-up time. And I have more notes here. I think we probably have to just maybe copy paste these into the next accessibility episode like I mentioned before in a couple months when we bring Nic back on to do live accessibility audit of the PHP Roundtable make me feel really bad about all my code but that's ok.

Glenda: [00:51:54] Inspire you!

Sammy: [00:51:56] Exactly, inspire. And I'm totally ok with being the one that gets picked at to inspire others and be like, hey his code sucks too I don't feel so bad. So I definitely hope that inspires others to kind of try to make their sites more accessible. I already I know you've got this probably in your shameless plug Nic but you have a Web site out there specifically for making podcasts more accessible and I've gone through and I started kind of preemptively thinking like oh let's see if I like how good I'm doing so far and I'm like it's kind of been like oh boy I’m in for a lot of things through this live accessibility audit. But the developer shout-out is that typically the segment that we transition into next which is recognizing a developer in the community for doing something awesome. But for this episode I dropped the ball on the developer shout-out again, and this is like I keep doing this I apologize it is just kind of busy. There's a couple of quite a few sponsors actually who have been reaching out to me wanting to sponsor episodes and I haven't been giving them that the stats and sponsorship prospect this stuff that they need. I finally got one after what I think four years of having a podcast I finally have a sponsorship prospect. This PDF I can send people because I had no way of tracking the analytics just because like this is not something that I'm care I care more about just getting the content out there and sharing knowledge versus like trying to like monetize and like track and analyze and all that stuff. So this stuff is sort of coming like four years later because you know the number one thing for me is the education aspect and making sure that we're all continuing our education together. So let's wrap this thing up with some shameless promos. I know some of you have some some fun things to promote so let's kick it off maybe Eric do you want everything you want to shamelessly promote.

Eric: [00:53:38] Yes I can shamelessly promote the new Web site of the Web Accessibility Initiative were I worked on the group with the Education and Outreach working group. So if you're interested in WCAG 2.1 guidance and you know techniques and stuff like that. Go to a w3.org/WAI and we got a lot of stuff there. For example we got the accessibility fundamental section which has the accessibility principles outlined in a very nice way and really easy to understand, I hope. If you've got any feedback you can contribute on GitHub. So if you don't understand something, let us know. We want to the site that's really important. And yeah I'm really proud of the site and that we have all that guidance now in the format that you can actually find it, because that was very hard before.

Sammy: [00:54:36] For sure, for sure. Glenda, do you have anything that you want to promote, aka Goodwitch, right.

Glenda: [00:54:40] I did. I did. So one of the questions we didn't get to is how can people go about using automation to do accessibility testing. And I want to tell everybody about a tool called Axe: a x e. It is the accessibility engine. And if they just just Google A X E and accessibility, you're gonna hit it. It's an open source tool that you can download an extension into using your browser. Or if you're really [?] you can actually pull the core engine in and run it during when your programmers are testing at that code stage, not just the browser stage. So that's that's the big plug that I wanted to make. And for anybody wanting to learn a little bit more about accessibility check out Deque University.

Sammy: [00:55:36] Excellent. What about you, Nic. Do you have anything you would promote?

Nic: [00:55:40] Oh so many things but I'll limit myself to just one. Check out the accessibility rules podcast a-one-one-y-r-u-l-e-s dot com. There is a long form podcast. There's also a series of five to 10 minute segments the sound bites where people with disabilities that tell us in their own words what bears they encounter on the Web. And I even now have series started long form in French. So here you go.

Sammy: [00:56:13] Very cool. What about you, Sandra, anything you want to promote?

Sandra: [00:56:17] Now I can't say I have. I haven't prepared anything, so I'm going to check out the other tips I got here so it's going to be really interesting to see the at least the AXE accessibility thing. I don't normally I don't normally use any automatic tools, so it's going to be interesting.

Sammy: [00:56:41] Oh yeah, sounds good. Like you Tobias, do you have anything you want to promote.

Tobias: [00:56:46] Think I want to shamelessly promote myself, I’m doing some workshops iin the next few months. In Croatia web summer camp and then Symphony Live, Berlin. So if you want to learn some more coding with me, I think there are still some tickets left to Croatia.

Sammy: [00:57:08] Very cool, awesome. Well our next episode will be one that we've tried to schedule for probably a year now and has never been able to nail down a date and time. Sometimes it's really hard to nail down a date and time when working with for 5 different people's schedules. So that one is concurrency generators in core routines, oh my. We're finally going to be talking about this episode. It's been sitting on the docket for so long. It's happening July 26 at 11:00a.m. EDT that's Eastern Daylight Savings Time. So if you have been waiting for that episode it's finally going to get here. We're going to have another one a couple of other upsets coming down the pipe. Docblocks, annotations and the like, which should be an interesting episode. And then the GDPR for PHP devs. It's a little bit late to the party on GDPR stuff, but hey it still affects us so why not talk about it and then all things Drupal is also slated. There's a bunch of other episodes coming down the pipe. If you have something that you'd like to share on the PHP Roundtable, maybe a topic that you'd like to hear something that you'd like to join the panel for. Just hit me up on Twitter. I'm Sammy Kaye or you can ping the peace Roundtable on Twitter. There's also a form on the PHPRoundtable.com that you can fill out be like. I want to talk abouit this or I want to hear about this. Oh my goodness this has been a great panel. I'd like to thank, who do we have here: Eric, Glenda, Nicholas, Sandra and Tobias for joining us in this episode and we'll see you folks in the next episode.

Nic: [00:58:23] Thank you Sammy.

Eric: [00:58:25] Thank you.

Sandra: [00:58:25] Yeah, Thanks.

Glenda: [00:58:25] To Accessibility!

Nicolas Steenhout




Glenda Sims


Sandra Eriksson


Show Notes Credit

Thank you Eric Eggert for authoring the show notes for this episode!

If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!