Mike and Matt are joined by renowned web accessibility expert Marcy Sutton, along with Lullabot's own Helena McCabe to explore various web accessibility topics.
Episode Guests
Marcy Sutton
Senior web developer & accessibility advocate at Deque Systems, Marcy is also an Axe-Core team member.
Helena McCabe
Helena is Lullabot's friendly Technical Account Executive. She's based out of Orlando, Florida. She loves dogs, web accessibility, and unusual flavors of ice cream.
More about HelenaMentioned in this Episode
Transcript
Transcript
- Matt Kleve:
- For October 5th 2017, it's the Lullabot Podcast!
- Robot:
- Lullabot Podcast. Duh-nah nuh-nuh. Duh-nah nuh-nuh. Duh-nah nuh-nuh. Duh-nah nuh-nuh. Bah-na nana-na-nanah bah-na nana-na-nanah. Bah-na nana-na-nanah bah-na nana-na-nanah.
- Matt Kleve:
- Hey Everybody! It's the Lullabot Podcast: Episode 218. I'm Matt Kleve, Senior Developer at Lullabot. With me as always, co-host the show, Senior Front-end Developer Mike Herchel. Hey Mike!
- Mike Herchel:
- Hey! How are you doing?
- Matt Kleve:
- Super! How are you Mike?
- Mike Herchel:
- I am fantastic. I'm excited.
- Matt Kleve:
- I am, too. You know, a couple of episodes ago we actually touched on this topic, but we're going to come back again.
- Mike Herchel:
- It's an important topic, right?
- Matt Kleve:
- Yeah. We're going to be back on the train, talking web accessibility. Since we're going to spend all this time in the front-end and in the back-end working on these web sites, we need to make sure they're usable for everybody, right?
- Mike Herchel:
- Absolutely! And this week we have a super awesome guest.
- Matt Kleve:
- We have a Senior Front-end Engineer at Deque Systems. I'm told she's a rehabilitated Flash developer. She's the creator of the well-known Accessibility Wins blog. She won an O'Reilly web platform award for her work on accessibility. She works remotely from Bellingham, Washington, which is outside of Seattle. I'm told almost Canada. Hi, it's Marcy Sutton! Hello.
- Marcy Sutton:
- Hello! Thanks so much for having me.
- Matt Kleve:
- Thanks for coming on.
- Mike Herchel:
- And we also have one of Lullabot's resident accessibility experts in front of us, a Front-end Developer here at Lullabot. She speaks about accessibility and related topics around the Drupal-sphere and is an enthusiast of dinosaurs and dinosaur paraphernalia - from tropical and muggy Orlando Florida: Welcome Helena McCabe!
- Helena McCabe:
- Thank you very much.
- Mike Herchel:
- Hi, welcome back. It seems like we just talked to you.
- Helena McCabe:
- I know you can't get rid of me.
- Mike Herchel:
- One of these days...
- Matt Kleve:
- Maybe you could you can just explain for a second: You know you're the one who jumped back, and was excited about this topic and decided to say, "Matt and Mike, we need to do this again."
- Helena McCabe:
- Well yeah, I mean as my Twitter profile says, I never shut up about accessibility. So if I ever have an opportunity to move that ball forward and get people talking about it, I think it's good to keep in the conversation as much as we can.
- Matt Kleve:
- Marcy if you don't mind just kind of introducing yourself and how you kind of fell into the web accessibility world and how that works today.
- Marcy Sutton:
- Yeah. So I now I work on accessibility full time on tools for developers to try and help make accessibility easier to achieve. But when I started I worked at an agency I didn't know anything about accessibility. I remember being like an english. What are those. And it turns out that's a pretty common path for a lot of developers. You kind of just stumble into it. Maybe you didn't learn about him on markup as much as he should have. And then all of a sudden I had to do client work or for Target and they had legal action brought against them. At one point that every It basically meant that any time an agency partner you created a web experience for them it had to be accessible. So it was actually a really great series of events that led me to getting to know accessibility and once I learned about it and I met people with disabilities it was such a game changer. And now I can't turn that part of my brain off. So pretty happy with the way it turned out.
- Mike Herchel:
- That's a good part of your brain to turn on.
- Mike Herchel:
- So how is the state of accessibility on the web and how has it changed since you began your accessibility journey?
- Marcy Sutton:
- Well the tools are definitely better. I remember learning about ARIA and it just seemed like there was kind of this hidden layer in terms of what was exposed the screen readers that I just didn't understand and there wasn't a lot of visibility to go debug that kind of stuff. And since then now there's you know inspectors like Chrome the developer tools they have an experiment for debugging accessibility that I like a lot. The Edge browser has a pretty cool tool as well and I work on tools so I think that it's definitely more modern. The education and awareness part is what I'm constantly hammering away at trying to get more people into the conversation and get more people up to speed. Even just knowing that it's something they need to do. I think a lot of people kind of fall into sites without learning about accessibility. So I think it's a bit of a struggle at times but I try to stay optimistic and just open one person's eyes at a time to the amazingness of accessibility.
- Mike Herchel:
- Yeah exactly. I kind of followed along a similar trajectory, although obviously not quite as far into accessibility when I you know I'm mostly self-taught. And so when I started of course your list if you're learning about having and lists you just don't think about screen readers and tabbing around in that type of stuff. And honestly it was a lot of how it works. Helena and I worked on a Syfy.com together and some of her work there that I like really kind of opened my eyes which was which is pretty cool.
- Helena McCabe:
- I mean I think awareness of the issue and attention to it are really steadily increasing and that is really really encouraging. The problem is it still isn't uniformly making it all the way through the development process from devah awareness to end user it seems like there's like a lot of cracks for it to slip through from there. But I do see a lot of improvement because years ago you know I like to speak about testability and people would be like oh what's that? And now people are like Oh cool I love accessibility and it's nice seeing it catch on.
- Mike Herchel:
- And honestly if you don't love accessibility like what type of monster are you? Right. Exactly.
- Matt Kleve:
- Oftentimes the argument you hear against it is budget. And another thing might be sacrifices you might have to make in your design. So what would you say to designers who say that accessibility requires sacrifices be made to their wonderful perfect designs.
- Marcy Sutton:
- I would say embrace inclusive design like learn how to make it so that it can work for more than one group of people because it really does start with UX and design like I think it would be a total misjudgment of skills to leave that behind because it can be so beautiful and it's really baked in from the start. I mean you think about even just like in a physical space trying to add a wheelchair ramp when it wasn't designed into the building's architecture so similarly on the digital side it really you can make something that's more inclusive and sort of holistic if you're considering it all the way. So I try to empower designers to recognize how how powerful that is and how you can make something that works for all different kinds of people. I think the caveat to that sometimes is that they have to let go a little bit like you aren't going to get pixel perfection across every single browser on every single device.
- Marcy Sutton:
- And I think if we're embracing responsive design and mobile it might be a little easier to imagine somebody navigating your site by voice or using a screen reader or really just recognizing that you can't control exactly what the end user is going experience. So I think there is there's a lot of opportunity there for design I would like to see more of it for sure. Because it's a shame as a developer when you kind of get set up to fail and sure we can try and fix this but it's really the problem originated in the design.
- Matt Kleve:
- My ignorance is showing you mention navigating by voice that's a thing. How does that work?
- Marcy Sutton:
- Yes if you were using something like Dragon Naturally Speaking which is sort of the same technology and that you can use voice commands to navigate the web and it really depends on how well structured markup and text labels that are not I don't know text on the screen that you can identify and then use as a command to get it to navigate somewhere. For example like if you had just a plain English link and it said 'click here' and then the screen reader or text off screen was like to read more about this specific article that would be a kind of hard to use from a dictation standpoint because you wouldn't get that in context of which link you're trying to get to. So that's a pretty big topic that I just walked right into. I think my point was really that there's other inputs that we have to consider. Voices of the sort of the next big frontier. I think that I'd like to see more of. And it's really making interfaces that can work in multiple ways. Have you experience of all Helena? I'm curious to hear your take on the on the voice interfaces.
- Helena McCabe:
- Voice not so much, I haven't worked with. I know I've spoken to people who use a mouth stick and you know they were like please don't make me click nine thousand times with a mouth stick to get where I'm going. You know the more clicks the better for me. So that's kind of what I've heard as far as feedback goes.
- Marcy Sutton:
- Yeah totally. That's another. Another type of an interface like if you're in a wheelchair and you have like one one stick that you would use with your mouth or maybe it's something called the sip and puff where you're using what's available to you with your body to actually navigate the Web.
- And I'd really love to see more companies do user testing with people who are navigating in other ways because it's so... it's almost shocking to see someone use your your website in a completely different way than you imagined evidently.
- Helena McCabe:
- I mean as able bodied people, we can we can test as best we can for accessibility. But even if I spend my entire life educating myself on accessibility, I will never be able to browse as a blind person. I'm not blind. There's a level of skill involved in actually living in that body that you can't really get to as as a sighted person or you know as a person with full use of their limbs or fingers or what have you.
- Matt Kleve:
- I think this is kind of demonstrating just very quickly here already how broad this topic actually is. So we've talked you know several different ways already and I'm sure we're just kind of scratching the surface.
- Marcy Sutton:
- Definitely. Yeah. And I think I mean what I try to do there's so much possibility and I my mind opens up and I kind of start rambling about all possibilities but that sort of forgets that there's these basics that get left behind things like form controls needing to be labeled and icon buttons missing text for screen readers and keyword support. So I really tried to start with the basics that people are often forgetting, so that we don't get overwhelmed because that's really what I want to see on the broader web is people getting those basics right. And then we can start moving on to these more advanced concepts. But often that's left behind. So that's been my approach lately has been try and get like bring people along to just get started and get those things going and don't make them feel bad that they didn't do it before now.
- Matt Kleve:
- What's on your hot list of basics? I know that a lot of people have been trained for alt text now but that's just the beginning.
- Marcy Sutton:
- Yeah alt text is good - if it's decorative you can sort of leave the old attribute blank. My number one testing tool is the keyboard because often you'll see demo sites and codepens and things where they've made something interactive that only works with a pointer device like a mouse. And if you're using a keyboard to navigate that would not be usable to you at all so I usually recommend that the first thing you do try and navigate your web pages without a mouse or trackpad and see if you can reach everything and operate everything.
- Helena McCabe:
- Aww Mike, remember me doing that to you?
- Marcy Sutton:
- I think that should be like number one requirement to make sure it's active.
- Mike Herchel:
- I was thinking and this is just me kind of off the cuff here. It would be so cool to have like some type of conference like booth, where we take front end developers and we give them.
- All right. Well here's a screenwriter. We're going to put you know a pillowcase over the screen, and now get this information, and just see how they work with it or you know give them a web page and say hey this is it. We only have a keyboard here. There's no mouse. And just to kind of get those gears turning. I think something like would be neat. But maybe a little bit of work.
- Marcy Sutton:
- I think Facebook has a thing like that and looking it up right now it's called the Empathy Lab. Its in their main engineering building and I think it had multiple purposes but something like that where you could have experts there available I don't know. But I think there's many permutations of how you can do this. But I love this idea.
- Mike Herchel:
- I think Helena and I are going to do this for Florida Drupalcamp. I'm calling it now - Florida Drupalcamp 2018.
- Helena McCabe:
- I'm totally on board and we don't need a pillow case. A lot of time to check to check for low vision users, what I do is I just turn the contrast on my screen all the way down or the brightness might just hit that button till the screen is black and then I see what I can do.
- Marcy Sutton:
- I have a life hack for you related to this when I fly on airplanes and for some reason if I need to type in my credit card information, I will use a screen reader and turn my screen all the way down and then know I can see over my shoulder.
- Helena McCabe:
- Clever do not get your credit card stolen on an airplane like I did.
- Marcy Sutton:
- Did that happen.
- Helena McCabe:
- It did happen.
- Marcy Sutton:
- Yeah.
- Helena McCabe:
- Real pain.
- Mike Herchel:
- Well now that's going to be the last time that ever happened.
- Helena McCabe:
- Yes I've learned my lesson.
- Mike Herchel:
- Lets switch the subject a little bit to modern frameworks like React, Angular, Ember and just these super heavy JavaScript sites where they're just writing everything out and just one big bundle. Can that be accessible? Can itwork well with screen readers? And are there any like tips and tricks to that?
- Matt Kleve:
- I think Mike's also assuming that it's also something that can cause lots of problems too right?
- Mike Herchel:
- Yeah. Are there any big gotchas right?
- Marcy Sutton:
- Well the first question. Yes. They can be accessible. I think a lot of times the gotchas are just based on the framework they're using might not have the best documentation for accessibility or if you're reaching for a component framework and that doesn't have good accessibility but it's totally possible to make a single page app accessible. So some of the things you would want to consider are the keyboard support I mentioned, so that if you are using some components that keyboard users and screen reader users can navigate them.
- Marcy Sutton:
- Focus management is really big so in a client rendered application like an angular app or react app you want to navigate the user's focus around, so that their never just kind of left hanging. Like take for example if you have a sort of a list and you could delete an item out of the list. Get going onto a button maybe like a little X delete button and then it removes that item from the DOM. If you didn't handle the user's focus maybe to send it to the first item in the list or some other element, they would just be dropped and it wouldn't be handled gracefully. So, focus management, especially if you have new views appearing like an modal dialogs or layers, we want to make sure we're handling the user's focus in a way that they'll be in the right area of the application to start navigating. And that they know that there's new content on screen.
- Mike Herchel:
- Are there any libraries out there that help along to help out with? Or is that something that needs to be done by the developer manually?
- Marcy Sutton:
- For Focus management, it's really hard to write a library that would handle that just because it is so hard. There are so many ways to build an app that there's no one size fits all solution for that. But I usually try to advocate for a test driven approach so that you have test coverage for these things thats in your app so you can make sure that you know say you work really hard on your modal dialogue, make sure focus the sense into it when it opens. You'd want to capture that in a software test, so that your teammate wouldn't unknowingly break it. So that's what I try to recommend for stuff like that is, build it in near your actual application and get test coverage on it. So that's one way to approach that. I did ask Ryan Florence, who's pretty prominent in the React world, At one point if he had written anything for that and his answer was pretty much the same like I don't I don't know what you know a developer would be trying to script for focus ahead of time, so it's sort of hard to write tools for that. But it's helpful to look for accessible patterns that handle it. And I know I can send you some links for the show notes but there's a couple of good examples that we can look to for inspiration.
- Helena McCabe:
- It's actually a gotcha in Drupal with that that usually we have to fix in the sites that we built. When you have a view of content and then there's that load more button that Ajax's in the next chunk of content. The focus will actually just start over at the top of the page if you don't manually set it after that fires.
- Mike Herchel:
- You know who is a maintainer of that module?
- Helena McCabe:
- I do not.
- Mike Herchel:
- Matt Olivera, who is one of our coworkers, so I think you should ping him on Slack.
- Helena McCabe:
- Ahah I will ping him.
- Marcy Sutton:
- Helena, as you probably know but for anyone else who wouldn't know in that scenario your focus would be some backups of the top and then you'd have to navigate through all the content you already read and think to get back to where you were. That should be a super huge pain, like nobody would want to use your site if that was the case.
- Matt Kleve:
- That something like that would be a core bug with triples Ajax system. That's tricky.
- Mike Herchel:
- So I mean all it does is it basically just reaches out to like the end point takes an all of you know that it's HTML that's underneath that the one DOM element and just kind of writes it directly into the DOM as it's not terribly complicated. You know I think if there were some javascript to kind of just remember what that last DOM element was and reset the focus there. Something like that would be probably pretty straightforward .
- Helena McCabe:
- Well I post the snippet for the fix on drupal.org replying to someone's question when they mentioned the same problem. So the code floating around there somewhere.
- Mike Herchel:
- Yeah I guess we're kind of getting I'm on the side here.
- Marcy Sutton:
- Now it's interesting. I want to buy a super geeking out on like what's happening there. Like is the whole page being re rendered and it like dropping focus. Or I wrote a focus manager at one point that because the page was being rendered we could look for an identical element and then send it if that was the last thing that was focused and then focus right back to that identical element. But if that element changed we needed some hook to know where to send focus back in. And so we used the data attribute to be like oh this is the element that was supposed to be focus next time and I can dig up an example of what that looked like but it is nice to build up a utility like that to reuse for a project that I don't know depending on what framework you're using. There isn't one like solution for all frameworks but something to be aware of for sure. Focus management.
- Helena McCabe:
- Well speaking of testing that you had mentioned, do you know like any good accessibility linters?
- Marcy Sutton:
- Yes. There's one for JSX using ESLint. It's by a guy from Twitter. I'm blanking on his name right now, but I think it's called ESLint JSX A11y plugin or something like that. And that is a nice tool because it will warn you in your development environment if you've forgotten a form label or something like that. The caveat with linters is that they are only - its like static checking in your IDE that may or may not have styles applied or javascript applied. So it's nice to catch some really low hanging fruit things.
- But like the tools I work on, we really aim for the page being rendered and all the CSS applied because I can change it quite a bit. And then you may have thought you fix something but it's like, there are labels going to display:none. I mean there are so many scenarios. We test the page like after it's fully rendered.
- Mike Herchel:
- So you gave a talk at this year's Fluent Conf on accessibility with the continuous integration. When I look at your Github repo you had some type of tool that you were using to do this. Can you talk about that?
- Marcy Sutton:
- Yes. Well so did the big tool that I work on is the javascript library called Axecore. And that is a set of accessibility rules that we maintain and the engine that powers - we use in browser extensions and web driver API and things. But there's a CLI called Axe CLI and I think I may have showed that for CI. But the thing with accessibility testing in CI is it's just going to run whatever your test suite is so you could build that however you want. You could have unit test that it runs, or it's a whole suite of unit and integration tests which I usually advocate having a mix - for something like focus management that can be easier to do in an integration test. Whereas you might have some component that you want some like quick unit tests. You know make sure it's functioning correctly and especially important for UI frameworks where you have lots of configuration options and you want to make sure if the user supplies text for a label that it ends up in the right place and all that kind of stuff. So the idea really is just the big catch is like you just need some accessibility tests and then it'll run them automatically - which is pretty cool. But I think the tool you were wondering about is probably AXE CLI.
- Mike Herchel:
- Yeah. Yeah that's what I was looking for.
- Marcy Sutton:
- So what that does is it's a command line tool where you install it globally with npm install -g axe-cli and then you can supply it one or multiple URLs to hit and it will go out hit that site run the accessibility rules in Axe core and then return you a set of results in JSON and you can either save those results and pipe them into another system. I think the free tool is intended to be sort of a developer convenience tool where you can just have it go and give you some results and try and fix them. So it really depends on what your workflow is like. What tool is going to be the best fit. But having a consistent set of accessibility rules across your whole team can really make it so you're all solving the same problems and not like "oh this person uses this accessibility tool and this person uses this other one and we're like not meeting in the middle".
- Mike Herchel:
- So besides tests, do you have any favorite accessibility tools? I know you mentioned some Chrome developer tools stuff I know that there's a new accessibility audit in the audit's pane of chrome developer tools. I've heard of pa11y dashboard. Anything else that you want to talk about that's awesome?
- Marcy Sutton:
- Yeah. I mean that's what's so great and different then when I got started is that there are so many tools. I'm pretty partial to XAxe Core because I work on it now even before that I went to work on it because I used it every day. And so the Chrome extension I think is probably, I mean beyond, like my first pass would always be test with the keyboard. My second pass would be use the Axe Chrome extension because it'll float up really low hanging fruit to you like you forgot a label, or you're got aria wrong or something that's like really error prone because we're human and that can be really useful. The chrome audit thing that you mentioned actually uses Axe Core so the ruleset that they're using in in the chrome. It's actually run by Lighthouse. Lighthouse is using Axe core. And I think we're seeing a lot of adoption by big companies who like the stability of our rules. I like Pa11y dashboard. I'd like to see us add something like that. I think we've got a more solid rule set, which depending on like if you're working on a big team and I don't know for a lot of companies the actual rules that they run are really important. And so that's why we've put more of a focus on that. Let's see what our second tools? Yeah the WAVE tool is awesome.
- I know there's so much brainpower that's gone into tools like this like even like Axe, I think, is the third generation of it of our company and the folks at Web AIM have written there's. There's another tool called tennent. And so it's cool that like some of these techniques have been tested out and we're sort of landing on the ones that are the most reliable. There's also an effort in the W3C to standardize some of that stuff so we're not just reinventing the wheel over and over again. Those groups are the auto WCAG group and the accessibility conformance testing task force I think. So that's pretty cool to see. So we're all kind of like solving the same problem so we might as well standardize them.
- Mike Herchel:
- Yeah.
- Helena McCabe:
- And it's not just tools for devs either. For instance, Color Oracle is a really cool tool for designers and I believe there's a Sketch plug in as well, so you can see what your design looks like with different types of color blindness, and make sure that you know everything is going to show up and it's not going to end up looking really weird if someone's red green colorblind or something like that.
- Marcy Sutton:
- Yes
- Matt Kleve:
- We're talking web accessibility. Marcy Sutton's laying down some knowledge along with Helena McCabe on the Lullabot podcast right after this. We're going to get in and talk a little bit more about what developers can do to make sure they're doing the best possible job as far as accessibility is concerned. Also we want to talk about how accessibility works within content management systems and open-source coming up right after this.
- Matt Kleve:
- It's a little about senior developer and host of the behind the screens podcast Chris Albrecht. You know Mike Herchel pinged me the other day and he said, "Hey Matt you know who should do the podcast promo this week?" He said, "We should bring Chris on he can talk about behind the screens.
- Chris Albrecht:
- Wow. Hey what a great idea. I have a podcast too.
- Matt Kleve:
- I said, "Just like last time right?" And he said, "Really? We did that last time?" We did. But we want to hear about it. So Chris you've got a few episodes out Behind the Screens is kind of coming into its own.
- Yeah, it's it's really starting to evolve into more than I thought it was going to at first I'm enjoying doing these interviews and I've learned a lot about the people I've interviewed so far. So, I'm just trying to figure out how to keep them short enough now there's so many funny questions to ask.
- Matt Kleve:
- So how long do you actually want these podcasts to be?
- Chris Albrecht:
- So the original goal was to try and keep them sort of within the realm of what the original podcast was, which was like five to six minutes. I thought I'd make them a little bit longer maybe get up to 10. But lately they've been... it's been hard to trim them down to that short of a time. So I've been going about 12 to 15 minutes for each one - which I think is still it's still pretty good. You're getting into the what's going on in the community with the people and getting into the people themselves a little bit, but it's still quick enough you can get to it on your commute or just pop it in when you're making breakfast. It doesn't absorb a lot of your time or you have to pause it and started again later.
- Matt Kleve:
- So the Behind the Screens podcast - you can find it anywhere great podcasts are found.
- Chris Albrecht:
- Yes! Lullabot.com, iTunes, feed burner, stitcher. All of those things.
- Matt Kleve:
- Anything more you want to say about it Chris?
- Chris Albrecht:
- I will be a badcamp doing interviews live - so they won't be produced live. They'll be recorded and then put out later. But I will talk to you live in person at Badcamp if you've got something cool to say. I'm also looking for people who are putting on camps in conferences if you would like to say something about the trainings or sessions or how you organize your camp or conference.
- Matt Kleve:
- Thanks Chris.
- Chris Albrecht:
- Thanks. Matt.
- Mike Herchel:
- Welcome back we're talking web accessibility with Marcy Sutton and we're talking a little bit of everything with web accessibility.
- Matt Kleve:
- That's weird Mike because we're usually talking Drupal things aren't we?
- Mike Herchel:
- Yeah. Yeah. We are usually talking Drupal.
- Matt Kleve:
- This is one of those topics that kind of goes beyond just you know Drupal, though right, it's kind of a web development thing in general.
- Mike Herchel:
- You know I saw this tweet on your timeline, Marcy, and it said, "Accessibility is a civil right." And I thought that was like really cool - I might be kind of paraphrasing that right there - but from my point of view like access to the internet like that is my personal livelihood. If I didn't have internet here I would not be making money. And to deny people that livelihood based on you know your lack of accessible Web sites seems seems like a real problem. So it's really cool to be here talking about it.
- Helena McCabe:
- I'm glad you touched on that because it's not just the civil right of people being able to use Web sites but like you said you know we have our career on being developers and there are a lot of developers who you know are visually impaired or blind or have various disabilities as well. So we're not just looking at this from the angle of the end user but accessibility in the tools that we use to do our jobs so that people with disabilities can also do the same jobs we do.
- Mike Herchel:
- Yeah absolutely. This lets us developers - there's more and more people that do remote work as all of us do.
- Let's talk about different content management systems and accessibility. You know Drupal puts a lot of work into our accessibility. But do you have any experience with anything else and maybe how you compares and how it stacks up. Maybe if there's anywhere where it's lacking?
- Marcy Sutton:
- I think Drupal and Wordpress are the two content management systems that really stand out in my mind, that is putting a lot of effort into accessibility, and I think I hold them both in very high regard. Just based on how much effort they have put in and how much community outreach there is as well, so making strides in an open source project as large as those are - it has to happen, but it's it's really nice to see. I don't think there's any other content management systems that are on my radar as being accessible at all - which is a shame. But, that's kind of the way it is. So I would like to see more of those. I mean it would be nice to have more choice. You know when you are trying to choose CMS, but being able to solve problems in the core of a system like Drupal is such a great way to fix something once and then have it trickle down to every consumer of that CMS. So I think Drupal and Wordpress are both doing a really good job.
- Mike Herchel:
- Yeah, I remember when Drupal 7 was first released - this was 2011 and I saw this I saw the skip link, and I didn't know that was. I was like what is this link you know and of course I googled it and it was just the fact that it was there kind of opened my eyes a little bit.
- Matt Kleve:
- Wait you didn't just delete it?
- Helena McCabe:
- What's this weird blue outline on stuff? Get rid of that!
- Marcy Sutton:
- I've heard all of this before. And we laugh, but that is a thing. People will be like, oh I don't know what this is for. And I've had I've seen it time and time again where a developer won't understand the purpose behind that. And so they do just delete it or you'll add a ... We were going to talk about CSS resets. And this is a big sort of hot button topic about focus styles because historically CSS resets would remove the focus style for every interactive element and that's a problem! You can't reset that. I mean no pun intended but like once it's been reset, you can't reset it again. So yeah this kind of all comes together where we're using these tools you know be it CMS or even just a pre-made CSS reset file and if you know you're just trying to get your job done and don't understand what everything is doing you're sort of set up to fail. So that's where it's nice to have tools that float up these problems too to make it easy to identify that there is an accessibility issue. And on the CMS side I know there was... in the CKEditor, I believe, there was like an accessibility checker for content people which would be nice because you might not be technical at all, but if you're reading content in a CMS, you know it could be university content, or I mean just social media content or marketing - whatever and you may be just pumping infographics in there and I have no clue that you need alt text and stuff.
- So having tools like you know a checker in your WYSIWYG editor would be so nice because it makes it a lot easier for people to get it right.
- Mike Herchel:
- Yeah yeah I agree with you. Absolutely.
- Marcy Sutton:
- Some more of those if there's a plugin that you can add to your WYSIWYG editor for content owners to utilize, install it and then show them how to use it.
- Helena McCabe:
- Because content editors do tend to have a harder time I think because a lot of content editors are not developers, so they don't... they're one step removed away from what's happening on the code what's happening with screen readers. So it is really important when you pass a site off you know as an agency to leave the content editors with that knowledge before you go away.
- Marcy Sutton:
- Totally. And you can't expect someone to go view source and go craft HTML like I do that without thinking. And I remember being in a client meeting where we were trying to win an account, and we were trying to win a project where we were going to be building a CMS for this client, and the sort of internal client that we were up against was like, oh yeah you'll just like write HTML. And like the people who were going to be hiring us were like, We aren't developers, and we ended up winning the project because we were going to give them structured data where they could just type raw text and then we would you know populate it in the correct markup and everything, and I remember that being such a deal breaker for them that their own team just didn't get it. They were like nah you just learn HTML. We're like no. That's such a unrealistic expectation for a content writer.
- Mike Herchel:
- I remember in really there was this one website a long time ago, and I don't even know why this is coming to mind. But they have like some beginning HTML tag, like it might have been like a large tag, or something like that, back when that was a thing. And they never ended it. And so they would put this at the beginning of every single paragraph tag or something like that.
- By the time you scrolled down the web site... and it became a thing you know I mean.
- Marcy Sutton:
- I remember... it was like a sewing or quilting website or something!
- Mike Herchel:
- I to scroll down into like the T would be like larger than your monitor and stuff like that.
- Marcy Sutton:
- Yeah it was like it was like nested did open H1 tags or something that that. I remember that. I got fixed. I was really sad. I tried to go find it as an example to teach people about HTML and they'd fixed it. And I was really sad.
- Mike Herchel:
- Maybe we can recreate it some time!
- Marcy Sutton:
- So yeah there's definitely a disconnect, and depending on what sort of experience you're making... where you might need to set your CMS up so that you know content writers will be set up for success, and they are expected to learn HTML. That's kind of the beauty of CMS, we don't always have that option, depending on the platform that we're building for. But that is one nice thing about make actually customizing a CMS and I know that's easier with some CMS's than others.
- Helena McCabe:
- Even just like conceptual knowledge is important to leave them with as well because even if you give them a WYSIWYG with just buttons for adding types... if you don't educate them on, OK will you need to use these in order, and you need to use these appropriately. What you'll find is that people start using heading types decoratively. So it's really important to at least try to get them to absorb a quick foundational knowledge, like here's the basics of what these do and why it's important not to use these like crayons.
- Marcy Sutton:
- Yeah I'm a big fan of checklists. I know sometimes those don't go far enough, but often I mean even when I'm like deploying software I will go and look at the checklist. OK let me make sure I didn't print anything, and having a set of steps tailored to your task, be it writing content, you know publishing an NPM module, or just coding an interface. Like if you had something you can refer to, I find that those really helped me to make sure I don't forget anything. So for our content, that would be a really helpful deliverable to give somebody. Like hey here's a quick accessible content primer that you can refer to when you publish stuff.
- Mike Herchel:
- Well we're working with computers. You know if we write some type of modular or some type of plugin that when they hit the save but it does like almost like a continuous integration check on the actual content, and it passes or fails... and depending on the various different rules it might go to someone else who then has the ability to kind of override it and approve it or something. I'm just kind of thinking.
- Helena McCabe:
- You're on a good track there... maybe have a small electrical current where it zaps you in your chair!
- Mike Herchel:
- Think it's a genius idea.
- Matt Kleve:
- When you mentioned a checklist, and the basic knowledge of HTML. Something I thought of, was forms and a lot of times forms end up not being very accessible. What can someone do to make sure that they do a good job with their HTML forms?
- Marcy Sutton:
- Well fortunately that's a pretty easy one to automate. So in a lot of accessibility tools like Axe, and I'm sure WAVE had some stuff for this as well. You can just run a checker to make sure that you didn't forget a form label. I mean ideally you can get to a point where you just remember those. But the important thing to about forms is that if you don't label something, a screen reader user might have no idea what a particular control is for, and they might be opting into spam email without realizing it. Which is pretty horrible. Yes super not great. I mean anytime you're collecting user input there's just... I can't believe how often this gets forgotten because... I mean it's like who are we building stuff for? And this is... I guess it's it's why it's so frustrating, but it's also an opportunity at the same time it's because these are pretty easy parts to get right. So just label things, like make sure that every control it's exposing what that thing is for, like are you collecting your first name, or your middle name, or your email? Make sure that it's connected to the form control. And if you're not sure how that should work, you can use an automated tool. And if you got it wrong it will tell you, like oh you need to go fix it on this element and here are some suggestions on how to do it. So that's why in our tools we try to give you remediation steps... like ways to fix it and then links to go learn more about it. Forms are such a foundational thing if you're building user interfaces.
- Helena McCabe:
- And having a label is good. I mean it's definitely great to point that out and that's step one. But it's also important to remember to be specific with your labels. Like I've been told from users that can't see, that one of the biggest things we do wrong with labels is when it's a form element for a number, like a phone number, or a social security number. Sometimes it'll be like three boxes - like one for area code or you know one for the first three digits, then the next two digits, than the last four digits, or you know an area code box, and then the rest of the number. So if they're split up or if they're all together, it's really good to specify that in your labels so that people don't know can tell. Oh my putting three numbers in here for seven or what am I doing here?
- Matt Kleve:
- But that doesn't look pretty. No seriously that doesn't look pretty. I mean you might design it tell me I can do that. Is there a way to make that available to people who would be using a screen reader or other technology, and not be seen?
- Helena McCabe:
- Well yeah, you can hide that span by clipping it. So then the screen reader will hear it but no one will see it.
- Matt Kleve:
- Is that the right thing to do?
- Marcy Sutton:
- It starts getting into where you're changing it for different users, and it's harder to maintain. I'd also... I would really try to just get one field for a number, because especially if it's international the format of the number might be different. Just the one field and make it easier on everyone. I guess, another thing that you might want to consider is if there is a format that someone needs to follow you can make that part of a placeholder, or some sort of description text that... so maybe get an input field and the label is phone number, and then maybe you've got an aria described by attribute point to a paragraph or a spanner or something that has the format in it. So then when a screen reader user they land on this field they hear a phone number and then they hear the format. It's like it exposes both of those pieces of data to them so they can successfully type in the right format number. And also it helps just as a user in general to be a bit more forgiving of your format. Like sometimes, you know, you go all the way through a form and like they're just being really picky about the format like you have to use dots instead of hyphens, or you know you can't use hyphens in just so many combinations that are like pretty easy to get around with javascript so make it easier on your users.
- Mike Herchel:
- And you know you can have all of us a server side...
- Marcy Sutton:
- Client side and server side.
- Matt Kleve:
- What about custom form elements? Something like a color picker or you know whatever somebody imagined.
- Marcy Sutton:
- Oh yes, that can be challenging. I guess the first thing is if you're going to make... Well first, you should see if there's a native element version... there isn't really a color picker. Definitely not crossplatform... I know a date picker, like the input type of date, that one's been really slow to make its way into browsers. But if you are going to make something custom, make sure you can operate it from the keyboard and a screen reader. Colors definitely need to... I guess like labeled color somehow, so that someone who is colorblind can be like, oh this is the color. For something like that, that's sort of a new frontier. I would definitely want to get it in front of real users and test it as soon as possible because it's really test the thing. Yeah that one that's a particularly challenging component to build, because I mean if you're just using like an entire color wheel, it's like how many how do you operate that with a keyboard? Is it like every single pixel is an arrow key move or...?
- Mike Herchel:
- I mean we're kind of getting off right here, but there's a color input type, input type color thats in Chrome and I'm looking at Can-I-Use right now. And its supported on everything, except for IE and Safari, and iOS Safari and stuff like that. So I mean like obviously like native controls... Yeah yeah. I'll shoot over to you. Yeah it's obviously so let's not use too much but it's pretty neat.
- Marcy Sutton:
- It is. Yeah and I guess what's nice. So this is the native input type. It will use what's available on the operating system. And then the accessibility of that really depends on the operating system. Apple does a pretty good job of making things accessible, I know Windows does as well. So if you can use the native thing first, do, because you will avoid a huge can of worms of things that you didn't think about it. I know we're going to build a color picker into Axe but it has a limited number of colors. So that's a little bit easier to make a custom thing because you only have to choose from so many colors. So yeah that one's pretty challenging... I think a date picker is a little more common, but also pretty challenging. So you definitely... I think there's multiple ways you can design those so there's no one right answer, but definitely get it in front of real users tested. Better to learn that it doesn't work sooner than later.
- Mike Herchel:
- So let's talk about mobile devices accessibility on mobile devices. How do screen readers work on say like an iPad iPhone or Android device? Are there are there any type of ways for people that might not have motor skills to to navigate around that stuff?
- Marcy Sutton:
- Yes absolutely! So if you have an Android phone or an iPhone or an iPad, you already have a screen reader that you can test with. On iOS and OSX, it's called voice over. On Android, they have a screen reader called TALKBACK, and they work in similar ways in that when you turn the screen reader on, you have a mobile tab order basically so you can swipe left, swipe right, and it'll take you through every focusable thing on a page - sort of like a keyboard. And there's other ways of navigating. So in IOS, you have what's called a rudder, and you could navigate by headings by form controls. It's really similar to a desktop screen reader is just the mechanics of how you get into these things is slightly different. But it can be totally freeing for someone to be able to use this device - say you're blind person out using Google Maps or whatever, and it's like telling you where to go. So it can be really freeing for someone to have this technology in their pocket. And for someone with limited mobility, they can use a switched device which is essentially like a pared down keyboard with just a handful of keys. And then they can navigate using switch access, which is really cool. I guess for supporting that, you want to have structured markup.
- You want to group things, so that if your... the way that a switch access interface works... I guess there's a couple of different ways or a couple of different modes, but the general idea is that you have a scanning mode, where like scanned the screen and then whenever the visual scanner goes over an item that you want to get to, you tap, and then you kind of like go more and more.... you drill down into the element to select it. And so for something like... this what Helena was alluding to earlier... that you want to limit the number of clicks it takes someone to complete a task, so often it's about simplifying your interfaces and your user flows so that there's just less steps to do things. I'd say the biggest thing on mobile is to make the touch targets big enough that human hands operate them.
- Mike Herchel:
- That's one of my personal peeves right there.
- Marcy Sutton:
- These buttons just keep getting smaller and smaller! And yeah, it's you know.
- Helena McCabe:
- People with disabilities that give them a low motor skills or you know not super fine motor skills, to be able to hit that, you know even if you've got a tremor, or something like that is important.
- Marcy Sutton:
- So yeah I'd say the biggest thing I mean for everyone would be to use bigger touch targets. I mean at least if you're using a mobile screen reader you can kind of like swipe through everything that's focusable on the mobile mobile site. And so you have sort of an easier affordance to get from item to item. Because if you're just trying to navigate by touch, it can be really difficult.
- Matt Kleve:
- Do you have a rule of thumb How big is big enough?
- Marcy Sutton:
- I've heard 48 by 48 as a pixel dimension. I think those sort of generally agreed upon guideline. I think it depends on the resolution. I've heard 24 by 24, so it's somewhere in there. But it's not just I don't know it's really like the space around things like giving them more padding. Just yesterday, I was on a desktop site and there was like a big blue button... but it wasn't a button it was a link... and it didn't have padding in it, so it might look like a button, but the actionable part was just the text in the middle of it! I'm like, what does this have a buttons style? So weird. Similarly on a mobile device, you want to actually give it padding so that you can hit it anywhere and let the bounding box.
- Helena McCabe:
- Yeah but that's the funny thing you know. You ask, is mobile accessible? But as far as like the people with disabilities that I've spoken with, a lot of them prefer mobile to a desktop computer because it's actually more accessible for them.
- Marcy Sutton:
- Generally yeah, it's simpler, and the streamlined interface there's just less things on a page, so it's harder to get distracted. On native stuff, there's frameworks especially in iOS that make it a lot easier to get it right. Sometimes the APIs, they're just they're not changing as rapidly as web technologies. And I know some of the test, or some of the accessibility APIs are frequently used in testing. So I do think that in native mobile, there's just less variables. It's like pretty much you need to label things... that's like the biggest need on the web. You know we can do whatever we want. Talk about being a recovering flash developer, I remember interfaces just being so all over the place and we can do that again now with javascript.
- Mike Herchel:
- Another one of my pet peeves is when I see loaders on web sites now and I think to myself, what is this 2005? Come on!
- Matt Kleve:
- Creating freeloaders that were flash... That's was like the first code I ever wrote it was great. That was it was copied for an Apple TV you know from a magazine to make a program. I don't think that really counts, but as a recovering Flash developer, I'm thinking about Flash and accessibility, at least in the early days, and it was the screen reader read, you need to install Flash.
- Marcy Sutton:
- Yeah it was horrible. I remember I looked it up multiple times, and ironically I did work at Adobe for a little while. But there was this claim floating around out there that you could make Flash accessible, but nobody was able to do it, because it's just one big image. I think maybe if that technology had stayed around the API would have been improved on. But I don't think anyone was able to be successful at that. So yeah I'm pretty glad that we're more solid on web technologies because, as much as it does feel like the Wild Wild West, I think we have stable interfaces to use with HTML and I think for javascript developers really understanding that foundation is important.
- Helena McCabe:
- Be nice to your users I mean with javascript it's... to quote Spider man, "with great power comes great responsibility" Because you know if you're changing you know the DOM order around you need to make sure that it's actually going to still read in the right order and you're not shoving things around.
- Mike Herchel:
- How does flexbox work when I changed order stuff? Does screenwriter's still read in the source order, or does it read and the order does specify within the CSS order property?
- Marcy Sutton:
- I think it depends on the browser. So that's great. There are some people who have done research on this but I believe that Firefox does the right thing but other browsers don't. There's some discussion about trying to make it more consistent.
- Mike Herchel:
- What does the right thing?
- Marcy Sutton:
- I would expect if you reorder it, for the new order to be announced. So that you don't have this mismatch between the way it looked at that one viewpoint, or breakpoint, and then if you like change everything around and the screen reader is still... don't know if the if the order of the DOM is still... like I don't.
- Helena McCabe:
- Users should experience information in the same order no matter no matter how they're perceiving it.
- Mike Herchel:
- Well that's an interesting topic. If I'm interested in accessibility and I want I want to really get in there, where do I go to learn about this? Who do I follow on Twitter? How can I educate myself on this?
- Matt Kleve:
- And on top of that, Marcy,how do you keep up to date, because things are changing?
- Marcy Sutton:
- It's difficult sometimes, but I get a lot of information from Twitter. I do have to sort through what's going on in the world, which can be a little sad, but there are so many experts that are sharing what they know... especially on Twitter, that I think that's a great resource. If you go to the hashtag A11Y which is a numeronym for accessibility. There's often people celebrating wins or just talking about new tools and things. The most helpful thing I could recommend would be the web accessibility Slack channel, which is funded by Slack, and I can send you a link to that. But what's nice about that group is no matter what time zone you're in, there are experts there like super stoked to answer accessibility questions at all hours. And it's such a great resource. So that's a great thing to do. I have a course on egghead.io that has some development videos on how to make accessible user interfaces. There is also a longer course on Udacity from some of my friends at Google, if you're wanting to do like a longer free accessibility course. There's is really awesome.
- I guess one more would be a site that we have at work called Deque University, and that has like a bunch of training and free stuff It's free to people with disabilities... our paid content is free. So that's pretty cool.
- Helena McCabe:
- Oh that's super cool.
- Marcy Sutton:
- Yeah if you know someone with a disability they can go get free training on accessibility.
- Helena McCabe:
- And if you want more of the human element instead of just straight talk on Twitter, Axe chat happens pretty frequently. And that is definitely worth tuning into. It's you know people with disabilities and people in the disability community chatting about you know what's frustrating, what's not, and what some solutions are.
- Helena McCabe:
- So that was actually Axe chat?
- Marcy Sutton:
- I think it's AXS.
- Marcy Sutton:
- You know you might be right.
- Marcy Sutton:
- I only know because I participated once, and I see it every week like they do talk about things they're really passionate about, and sometimes it's really good to hear from the people who need it. Like we kind of get off on our you know altruistic so good happy time, and it's not a happy time for people with disabilities in the real world. So it's sort of good to ground yourself in the real problem that people have to gain some of that empathy. And I find that really energizes me to solve things in ways that people can actually use them. Like it's not about me feeling good about this. It's about making it more usable to someone with a disability.
- Matt Kleve:
- All right. I'm going to ask this silly question. Is that like a live Twitter? Like how does that work? I'm not familiar with that.
- Marcy Sutton:
- Oh the access chat Yeah. Yeah I like that. It is a hash tag. It's a weekly chat I think on Tuesday afternoons. I guess depending on what time and what time zone you're in. But it's some folks from the UK that have this weekly chat about accessibility.
- Helena McCabe:
- It's like an open conversation... there'll be five to 10 different topics and they'll say, OK topic one and ask a question and then people weigh in using that hash tag and the number.
- Matt Kleve:
- Yep I gotcha. I thought maybe Twitter had invented some sort of other interface that I was not familiar with for like live communication real time type things.
- Marcy Sutton:
- It's kind of like... there's other groups that do similar things like the dev.to folks do it and the code newbie podcast does it where they'll say, question one. Just like Helena said, that where you can go and answer and go look back on when other people are talking about. There's usually one overarching topic and guest every week but it's a great resource on the Twitterverse.
- Helena McCabe:
- That's funny though that I nerd quirked that like all these years I read it as axe chat. That's funny.
- Marcy Sutton:
- Access chat.
- Mike Herchel:
- All right. Well is there anything else that you want to mention before we wrap up, Marcy?
- Marcy Sutton:
- I don't think so. I well I guess just thanks for taking the time to talk about accessibility. I think every little bit that we contribute to it helps and.. It's a learning experience for me every day too. And that's what I like about it. So go forth with accessibility.
- Mike Herchel:
- Yeah absolutely. And thank you Helena for coming on and sharing your knowledge.
- Helena McCabe:
- Oh I'm always around! Whenever you want me, i'm here.
- Mike Herchel:
- And sometimes when we don't :)...
- Helena McCabe:
- Often when you don't, here I am in the peer reviews.
- Matt Kleve:
- Well thanks for listening! You can get in touch with us by tweeting at @lullabot. Go ahead and write us on iTunes or wherever you find us. That's how people can find us, if you rate us and let other people know how you enjoy this.