Podcast appearances and mentions of marcy sutton

Marcy told us about her photojournalism studies and how they led her to web development. We soon bifurcated into accessibility and remained there until the end. We discussed what it means to create accessible websites, the no-brainers and low-hanging fruits, why investing in accessibility early on in our projects are essential, and where to learn more about it.Here are the links from the show:https://www.twitter.com/marcysuttonhttp://marcysutton.com/https://www.linkedin.com/in/marcysuttonMarcy's course: https://testingaccessibility.com/Axe DevTools: https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbddhttps://accessibilityinsights.io/CreditsCover Heliotrope by Blue Dot Sessions is licensed CC BY-NC-ND 4.0.Your host is Timothée (Tim) Bourguignon, more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeDev InterruptedWhat the smartest minds in engineering are thinking about, working on and investing in.Listen on: Apple Podcasts SpotifySupport the show

In this episode, I spoke with Marcy Sutton. Owner and Lead Engineer of Modern Sole Design LLC, teacher, speaker, biking and outdoor enthusiast, and Queen of Pies. We talked a lot about Accessibility, aspects of accessibility, internal tools, hiking, pies, self-care, and community. Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Transcripts can be found at: https://toddl.dev/podcast/transcripts/sutton/ Show Notes: https://marcysutton.com/ - Marcy's Personal Site https://testingaccessibility.com/ - Marcy's Online Accessibility Workshops https://twitter.com/marcysutton - Marcy on Twitter https://www.instagram.com/marcysutton/ - Marcy on Instagram https://www.linkedin.com/in/marcysutton/ - Marcy on LinkedIn https://github.com/marcysutton/ - Marcy on GitHub https://codepen.io/marcysutton/ - Marcy on CodePen https://www.456bereastreet.com/ - 456 Bearea Street https://artofthepie.com/ - Art of the Pie https://2021.cascadiajs.com/ - CascadiaJS Conf https://www.csun.edu/cod/conference/ - CSUN Conference --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

In this episode, I spoke with Chris DeMars. Developer Advocate and Front End Developer at Rocket Mortgage, Accessibility Advocate, speaker, Host of Tales From The Script Podcast. We talked a lot about Developer Relations, Accessibility, and a lot of different aspects of accessibility as well as some other chatter, in between subjects. Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Transcripts can be found at: https://toddl.dev/podcast/transcripts/demars Show Notes: http://chrisdemars.com/ - Chris's Personal Site https://twitter.com/saltnburnem - Chris on Twitter https://www.talesftscript.com/ - Tales From The Script https://2021.connect.tech/ - Connect.Tech https://momentumdevcon.com/ - Momentum Developer Conference https://getwitit.org/columbus-witcon-2021-2/ - WITCON https://twitter.com/marcysutton - Marcy Sutton on Twitter https://www.twitch.tv/rocketdevrel - Front End Fun Zone & Rocket DevRel on Twitch --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

In this episode, we talk about accessibility with Crystal Preston-Watson, quality and accessibility engineer at Salesforce, and Marcy Sutton, web developer and accessibility specialist, who we have consulted with at Forem. Show Notes DevNews (sponsor) CodeNewbie (sponsor) DataStax (sponsor) New Relic (sponsor) Educative (sponsor) Ambassador Labs (sponsor) Modern Sole Design LLC salesforce.org Accessibility Screen Reader Serenade How to code without typing Tommy MacWilliamMatt Wiethoff Repetitive strain injury Hitman W3C Web Accessibility Initiative HTML CSS JavaScript ARIA :focus-visible

News!Marcy's doing a workshop!Don't miss Front-End Accessibility Masterclass November 6th with Smashing.DiscordJoin the discussion Discord

(January 8 , 2020) In this episode of the State of the Web, Rick Viscomi talks with Marcy Sutton (Head of Learning at Gatsby Inc) about web accessibility. Learn about what accessibility means, the impact of the Domino's ruling, and more in this episode. For more info about everything discussed in this video, check out the original video → https://goo.gle/2B37mPY

We're talking about Gatsby. What is it and how does it fit into your web development stack? Drew McLellan talks to expert Marcy Sutton to find out.

In this episode of the Modern Web podcast, join our hosts, Rob Ocel (@robocell) & Jake Dohm (@JakeDohm), as they sit down with special guests, Marcy Sutton, Aisha Blake, and Laurie Barth!    Guests: Marcy Sutton (@marcysutton) - Head of Learning, GatsbyJS Aisha Blake (@AishaBlake) - Sr. Software Engineer, GatsbyJS Laurie Barth (@laurieontech) - Software Engineer, GatsbyJS   This episode is sponsored by This Dot Labs.

Brittany is a software engineer for Formidable Labs. She’s a team lead for some client work and likes to poke around in their open-source stuff in her free time. Last year she gave a talk at ReactConf called ‘Accessibility is a Marathon, Not a Sprint’. She talks about her background and how she came to specialize in accessibility. Brittany believes there are a lot of small things you can do to make your website more accessible, and that following best practices in accessibility makes the website easier to navigate for the able-bodied as well. She emphasizes that having accessibility in mind from the get-go will make your website more organized overall and that making things more accessible is as easy as starting with semantic HTML. Brittany and Charles discuss the moral responsibility for businesses to make their website accessible and whose responsibility it is to enforce accessibility. Brittany feels that accessibility really isn’t that hard, but people just don’t know what it looks like or where to get started. Brittany shares some methods to improve accessibility that take very little extra effort. One of the best things you can do is use semantic HTML. To learn things like what is a header, footer, article tag, etc. is, she advises listeners to consult the documents. She talks about the importance of a good pull request and even enlisting coworkers to help you to remember to use these accessibility-friendly methods. Charles and Brittany talk about using heading outline extensions to help you see what content is getting scraped off your site. Once semantic HTML is in place, they suggest testing to see if your site works with accessibility tools like screen readers, or if you can navigate with just a keyboard. They talk about different extensions that mimic visual impairments to ensure your pages are readable. The show concludes with Brittany talking about how this all ties into React.  Panelist Charles Max Wood Guest Brittany Feenstra Sponsors NxPlaybook.com - Use code ‘NXDEVCHAT’ for 50% off the official https://nx.dev/React Advanced Workspaces course!  Sentry | Use the code “devchat” for $100 credit ____________________________ > "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Formidable Labs Accessibility is a Marathon, not a Sprint Deaf man sues Pornhub over lack of captions HTML elements reference Eslint-plugin-jsx-a11y-npm headingsMap for Chrome headingsMap for Firefox Marcy Sutton noCoffee Color contrast analyzer Writing Automated Tests for Accessibility Lighthouse Axe by Deque JSJ 344: Inclusive Components with Heydon Pickering Picks Brittany Feenstra Follow Brittany on Twitter Inclusive Components by Hendon Pickering Becoming by Michelle Obama Charles Max Wood The Name of the Wind Group coaching course for finding jobs and staying current devchat.tv/workshops

Brittany is a software engineer for Formidable Labs. She’s a team lead for some client work and likes to poke around in their open-source stuff in her free time. Last year she gave a talk at ReactConf called ‘Accessibility is a Marathon, Not a Sprint’. She talks about her background and how she came to specialize in accessibility. Brittany believes there are a lot of small things you can do to make your website more accessible, and that following best practices in accessibility makes the website easier to navigate for the able-bodied as well. She emphasizes that having accessibility in mind from the get-go will make your website more organized overall and that making things more accessible is as easy as starting with semantic HTML. Brittany and Charles discuss the moral responsibility for businesses to make their website accessible and whose responsibility it is to enforce accessibility. Brittany feels that accessibility really isn’t that hard, but people just don’t know what it looks like or where to get started. Brittany shares some methods to improve accessibility that take very little extra effort. One of the best things you can do is use semantic HTML. To learn things like what is a header, footer, article tag, etc. is, she advises listeners to consult the documents. She talks about the importance of a good pull request and even enlisting coworkers to help you to remember to use these accessibility-friendly methods. Charles and Brittany talk about using heading outline extensions to help you see what content is getting scraped off your site. Once semantic HTML is in place, they suggest testing to see if your site works with accessibility tools like screen readers, or if you can navigate with just a keyboard. They talk about different extensions that mimic visual impairments to ensure your pages are readable. The show concludes with Brittany talking about how this all ties into React.  Panelist Charles Max Wood Guest Brittany Feenstra Sponsors NxPlaybook.com - Use code ‘NXDEVCHAT’ for 50% off the official https://nx.dev/React Advanced Workspaces course!  Sentry | Use the code “devchat” for $100 credit ____________________________ > "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Formidable Labs Accessibility is a Marathon, not a Sprint Deaf man sues Pornhub over lack of captions HTML elements reference Eslint-plugin-jsx-a11y-npm headingsMap for Chrome headingsMap for Firefox Marcy Sutton noCoffee Color contrast analyzer Writing Automated Tests for Accessibility Lighthouse Axe by Deque JSJ 344: Inclusive Components with Heydon Pickering Picks Brittany Feenstra Follow Brittany on Twitter Inclusive Components by Hendon Pickering Becoming by Michelle Obama Charles Max Wood The Name of the Wind Group coaching course for finding jobs and staying current devchat.tv/workshops

Quick show notes Our Guest: Aisha Blake What she'd like for you to see: Gatsby Days - Feb. 3, 2020 Who got Aisha into the JAMstack: Working as a volunteer, creating websites in Jekyll Her JAMstack Jams: The way it makes teaching easier Her musical Jam: Dear Evan Hansen Soundtrack Other things mentioned Gatsby Title of Conf self.conference Transcript Bryan Robinson 0:03 Hello and welcome to another episode of That's My JAMstack the podcast asked the age old question, what's your jam in the JAMstack? On today's episode, we've got the amazing Aisha Blake. Aisha is a member of the Gatsby learning team, as well as being a teacher, speaker and conference organizer. Bryan Robinson 0:20 Now this episode is jam packed with JAMstack goodness. But before we get into that, I wanted to welcome back our wonderful sponsor TakeShape. Stick around after the episode to hear more about their content platform or go ahead and head over while you're listening to TakeShape.io/thatsmyjamstack for more information. Bryan Robinson 0:40 Hi Aisha, how's it going today? Thanks for being on the show. Aisha Blake 0:42 Everything is great. Thank you for having me. Bryan Robinson 0:44 All right. So So obviously, you're on the show to talk about the JAMstack stuff, but go ahead and give us a little introduction for who you are, what you do for work, what do you do for fun and that sort of thing? Aisha Blake 0:52 Absolutely. So I am a brand new senior software engineer on Gatsby's learning team. I am -- I do a lot of things. I do a whole lot of things. I am an organizer for two conferences in Detroit. One is called self conference is half tech talks, half people focus talks. It has really, really great community and one is new. I am also organizing a conference called after one of my favorite musicals, which is going to be a musical tech conference. Bryan Robinson 1:33 What?! Aisha Blake 1:33 Oh, yes. Yes. So all of the performances, they'll be performances are going to be musical and/or theatrical, similar topics to any other tech conference. So the idea is that we're teaching people through performance art. I'm really excited about it. Bryan Robinson 1:56 I'm now like, run through like, how would I do that? Like, because I speak at a few different conferences, how would I artistically render CSS talks Aisha Blake 2:05 It was largely inspired by TailCall Optimization: The Musical, which was a brilliant, brilliant Disney parody. So three different Disney songs, teaching you about tail call optimization. At !!con last year. And I have been surprised like I this is like the intersection of everything I love. And I've been surprised how many people were already doing this kind of thing. Like, it's, it's really cool. Bryan Robinson 2:41 Very nice. And when's that coming up? Aisha Blake 2:43 That's going to be May 7 in Detroit, and self.conference is actually the following two days. So anybody who is interested in attending either one, you will have a little bit of a discount on the second ticket. Bryan Robinson 2:58 Nice, very cool. Alright, so So obviously, we're not gonna be doing a musical here today because no one wants to hear me sing. That's for sure. So let's go ahead and talk about the JAMstack a little bit. So what was kind of your entry point into this idea of the jam stack or static sites? That sort of thing? Aisha Blake 3:13 Yeah. So as far as static sites go, and it goes back to when I was learning to be a web developer, I was a volunteer, a Jesuit volunteer here in Detroit. That's how I actually came to the city. And I knew that I wanted to be a web developer, but I didn't really have I didn't really know how to connect to the skills that I had. So I have an Information Science degree. But I really didn't know how to take the computer science concepts that I had learned and apply them to something that was practical in my immediate life. Aisha Blake 3:57 So during my year of service, I got started. started doing like small freelance jobs. And one of the one of the things that was really helpful was working with Jekyll at that time, and so I did a handful of static sites for people that I found either through word of mouth or through fivrr. It was, it was interesting. Aisha Blake 4:22 So getting introduced to like, the more modern, what you think of is the JAMstack, though, was actually Jason Lengstorf. Jason has been like one of the guiding lights of my career in that he was the one that got me started speaking conferences. But he also actually turned me on to Gatsby. Like, before he even he was working at the company. He was like, hey, yeah, I've been you know, working on this project. The people working out seemed really cool. They're been really helpful. And, you know, then he was working at it. Gatsby for a while. And that was what got me interested in Gatsby as a tool and as a company to begin with. Bryan Robinson 5:08 So, it's a very similar pattern that I've seen a few different times. Hey, I got started in static sites long time ago, it was Jekyll. That's pretty typical. And then, oh, let's figure out what's new. And what's what's really happening. And Gatsby tends to be about 50/50 what I'm hearing from people. So so you, you kind of did you dive in the Gatsby a long time before you obviously got hired very recently by Gatsby. What was your kind of your career pre employment from Gatsby with Gatsby, Aisha Blake 5:38 So I had no professional Gatsby experience before being hired to get speaking. I was working on a react project. Part of the project was in React. It was a really large metrics app that I was working on full stack, our full stack anyway. And so I had react. experience and then sort of on my own, I was like, well, I need a new blog. Well, my conference needs a website. And like, just sort of getting bits and pieces, and really enjoying the developer experience. And so when I saw that there was an opening on the learning team at Gatsby, and it's really this combination, much like title of calm. It's a combination, like all of the things that I love to do in a job. It was, I knew that I would regret not not applying. Aisha Blake 6:30 And on top of that, Marcy Sutton is my manager. Yeah, she's so I have from my entire career been really heavily interested in and, and passionate about web accessibility. And so Marcy Sutton is continues to be now that she's my manager. Bryan Robinson 6:59 Well, and the cool thing It's like you learn all sorts of stuff from someone like Marcy too. like I follow her on Twitter. I didn't even know there's accessibility about hashtags on Twitter until I followed her. Aisha Blake 7:08 Yeah. So it's been really incredible to be able to learn from her. And I can only imagine what's going to happen past my first three weeks on the job. Bryan Robinson 7:19 Sure, yeah. And the amazing thing to me is watching Gatsby specifically hiring people who care about this sort of thing and and there's perhaps a misguided stigma around react that react sometimes isn't always like JavaScript isn't always the most accessbile unless you really know what you're doing. And so I love that probably the premier company that's using react and the JAMstack is focusing so heavily on that. Aisha Blake 7:44 Yeah, and there's definitely a long way to go. To be clear. But the but we do have Marcy, as well as Madeline working really hard to get us to a point where we can say yes, like by default Gatsby is going to be a really great choice for somebody building an accessible application. Bryan Robinson 8:07 So what's a little bit of your of your history with accessibility? Cuz I know that you you have talked about it and worked on it in the past. Aisha Blake 8:14 Yeah. So I got started with web accessibility through. I'm actually wearing the sweatshirt right now a goalball, sweatshirt. goalball is a sport for blind and visually impaired athletes. Okay. And I was for a really long time, a volunteer for the New York goldball team. And before that point, I really didn't know anybody, personally, who needed assistive technology to access the web. And when the guys on the team asked me about potentially making a website for them, which I never wound up doing. I was like, Okay, I could do that, but I'm not sure You're I can't I don't know whether or not that website is going to be usable for you. Because I'm used to building websites from the perspective of a sighted person. And so that was kind of where I started delving into like what it means to build an accessible website and or web application. Aisha Blake 9:25 And so I've started watching watching Marcy Sutton videos, I start reading Hayden Pickering book, and just sort of picking up bits and pieces as I go along. And of course, talking to my friends on the goldball team, like Hey, does this work for you? And it was a really, it was eye opening in a couple of ways. One, I was just learning a lot but also the realization that Lot of actual web developers because at this point I'm, I'm aspiring a lot of, you know, actual employed, web developers are not doing these things. And I was sort of like, Well, okay, well, I guess I know, kind of what I can do what I can bring to the table from the beginning. Bryan Robinson 10:23 The interesting thing to me also is that it's not always even just a employed web developers. It's also web designers like knowing, knowing what to do is a design task as well. And I've managed a team of designers in the past and pretty things aren't always accessible things. Yeah. So yeah, having to think through all that is a is a task, but it's an important one. Aisha Blake 10:43 Yeah, absolutely. Bryan Robinson 10:44 Cool. So so let's let's get back into the jam stack a little bit. Obviously, you're going to be using the jam stack pretty heavily in your job at Gatsby. I assume you're going to be continuing in the jam stack for for your side. projects for your conferences up in up in Detroit. But what's going to keep you obviously other than employment in the jam stack? And what's kind of your passion in the jam stack right now? Aisha Blake 11:10 I think for me, it it's been partly about the fact that it makes my work as a teacher easier. That has really made it easier for me to kind of bring people into the fold who are interested in beginning to their like web developer journey or even just getting into tech in some form. I've found that in teaching and teaching the jam sack specifically, it gives people a more complete way to build a site so you have a working site that you could launch and also that gives me a jumping off point then to teach you about react to teach you about JavaScript. But you still get those quick wins, that you're able to get when you begin teaching, using methods that are not necessarily teaching people how to build production ready, application. Bryan Robinson 12:22 Yeah, the thing I really like is that you can just you can upload HTML and you have a website and then you can add the next thing and the next thing to the to the learning process. Absolutely. So where are you teaching and how are you? Are you mentoring what what sort of teaching are you doing? Aisha Blake 12:37 Yeah, so right now I am teaching part time at a coding boot camp called grand circus here in Detroit. And that was actually my first job was at Grand circus on the instructional stuff. And I was out for I was gone for three years, came back part time, teach at night, did not anticipate how difficult those two jobs when I happens to get the get the job at gaspee Around the same time, which was certainly not my intention. But it's been really, really challenging, but also really wonderful to be back in a classroom for that length of time again, because in between, you know, I'm teaching workshops, and I teaching online, and all those things, and those are wonderful, but to have a class have a course, where you're interacting in person with people. It there's something there's something special and important about that, in my opinion, Bryan Robinson 13:44 and so nice to actually like get next to somebody and be like, Oh, no, that you forgot the semi colon or capitalization matters or, you know, stuff like that. Yeah, Aisha Blake 13:52 I joke that I'm a professional rubber duck Bryan Robinson 13:56 Yep. I taught a an HTML and CSS class and I walk over to the students computer and like two seconds later to be like, you should have like an aura around you that makes it work like Well, no, but Sure, I like to think that maybe sometimes. So are you actually teaching jam stack there? Or is it more full stack or front end? Aisha Blake 14:14 So the so the course is a front end course. And it's actually focused on Angular. But a lot of folks are interested not necessarily in getting entirely new jobs specifically with Angular. It's more about kind of becoming programmers. And so it's been really cool to see them go from. I just don't know what I'm doing at all. I don't know what any of these words mean, to getting getting used to the idea of a JavaScript framework, any JavaScript framework, and then being able to translate that. So while I'm teaching them while the curriculum is an Angular curriculum, they are now branching Now into all these other things are they're getting interested in react? They're getting interested in Gatsby. And those are and those especially using Gatsby, those are accessible now. Because they've got that T's, they can now go off and start building these side projects, even though they've only just begun to learn kind of what a framework is. Bryan Robinson 15:27 They've got the taste for side projects, though. Exactly. It's pretty easy to get that taste as a developer. Cool. So uh, what sort of technologies are you really into in the jam stack? I mean, obviously, Gatsby, and we could talk forever about Gatsby or anything else Aisha Blake 15:43 like that. And so that's really my kind of pet battle right now. That is like, I'm very focused on learning as much as I can to be the most effective learning team member. So really, it's Combining, combining Gatsby in different ways, so really using that content much to the fullest. So, and I and I have so many ideas for things that guess really lends itself to. So we're kind of starting, we're starting at the ground level. So building more intro projects in service of learning materials. So you know, we have plenty of like building build your first blog with Gatsby, but also getting into and you can also use Gatsby as an application. So I'm focused right now on ecommerce with Gatsby. So all of the various ecommerce tools, bringing them in and making sure that we're presenting an experience that makes it makes it straightforward makes it a little easier for people to to get going and potentially then make money. themselves off of the side fresh chicks. Wouldn't that be nice Bryan Robinson 17:03 is nice when that happens. Cool. So while kind of keep keep our episode length in check a little bit. So let's go ahead and talk about what your actual jam is right now. What's your musical jam? What were you listening to? Aisha Blake 17:17 So, you may have already guessed based on my title of information earlier, but I am very much a theater person. And so most of what I listened to is show tunes right now. I am listening to Dear Evan Hansen. It's coming to it's coming to Detroit soon. And while the story is pretty twisted, obviously, the music is beautiful. And I'm really excited about seeing the show. And it's also given me a lot of inspiration for my own parodies, which is I'm unlike it's not my thing I don't I don't write a lot of musical parodies. But it's been really fun to to do that for the conference. And it has given rise to yet another side project that I'm using gets before. Perfect. Bryan Robinson 18:15 Awesome. Cool. So so let me put you on the spot then. So you're big in the in the theater. What is the best musical in your opinion of all time? Aisha Blake 18:24 Oh, my God. Aisha Blake 18:25 Okay. Aisha Blake 18:27 I think Aisha Blake 18:31 that's that's a tough question. I don't know that I've ever been able to answer that question. I will say, my dream role. And one certainly one of my favorite musicals is would be Aida, Bryan Robinson 18:46 that's aspirations right there. Right? Aisha Blake 18:49 For sure. Bryan Robinson 18:51 So So let's talk about is there anything that you'd like to promote to go to the jam stack community at large? Aisha Blake 18:56 Yeah, absolutely. So we do. I'm not sure when Air. We do have Gatsby days coming up at the beginning of February. And that's going to be a really great way to connect with the whole team. We're going to be, we're going to be in LA. And we are going to be presenting two workshops. So one is going to be an intro to Gatsby, and another is going to be building accessible applications. Matt will be with Marcy. So it's a really, really awesome opportunity to come hang out, learn more about Gatsby and what's coming next. And connect with the community. Bryan Robinson 19:42 Amazing. All right. Well, I appreciate you taking the time to talk with us today. And I hope that you keep doing amazing stuff, both the Gatsby and just I. I'm hoping that at some point, I can see title of cop because that sounds amazing. Yes. Aisha Blake 19:56 Thanks very much. Awesome. Thank you. Bryan Robinson 20:00 And of course, a big thank you to the JAMstack community for listening, subscribing and sharing. This podcast is an absolute blast to host and produce. And it's because of the amazing community that we're all part of. Bryan Robinson 20:11 With that it's time to talk about our sponsor this week, TakeShape.io. They're a content platform for the web, with a developer, and user friendly, headless CMS, which isn't always easy to do a GraphQL API and a powerful static site generator all built in all kind of one piece that you can use on your project. Now, if that sounds like exactly what you need, head on over to TakeShape.io/thatsmyjamstack and find out more. Bryan Robinson 20:39 That's it for this week's episode. So until next time, keep doing amazing things and keep things jamy.Transcribed by https://otter.aiIntro/outtro music by bensound.comSupport That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

Emma Wedekind MC’d a live show at ReactJS Girls with a panel of 3 amazing women — Eve Porcello, Marcy Sutton, and Kate Beard. It was a great discussion covering the biggest challenges they’ve faced, how no matter who you are imposter syndrome occurs and never really goes away, ways to support and encourage under-represented groups and people to get into tech, and how to choose a topic when writing a talk.

Emma Wedekind MC’d a live show at ReactJS Girls with a panel of 3 amazing women — Eve Porcello, Marcy Sutton, and Kate Beard. It was a great discussion covering the biggest challenges they’ve faced, how no matter who you are imposter syndrome occurs and never really goes away, ways to support and encourage under-represented groups and people to get into tech, and how to choose a topic when writing a talk.

Marcy Sutton is the Head of Learning at GatsbyJS, but what does that mean? One of Gatsby's core focuses is the community, and a part of that is making the experience with Gatsby as friendly as possible. A large part of making Gatsby friendly is having excellent documentation, so that learning and debugging experiences would be smooth. So the learning experience is smooth but what is Gatsby's potential on the web? Marcy talks about how Gatsby has the potential to make a huge impact. Currently WordPress is powering about a third of the web, that's huge, but it has its issues. WordPress is centered around the authoring experience but the front-end experience is not good. Gatsby is looking more towards the future, it doesn't use a database, it can build out static HTML, it's accessible, and it's also democratizing the experience with a themes ecosystem. This brings up the point that JavaScript is eating the web and it's making it more difficult for folks who've had a different intro to webdev. This is a real challenge and people are having their careers impacted, what can we do to reconcile this? The decisions made by tech teams aren't considering this when the pick the technologies that they use, they're picking tech that's going to deliver a high preformance application, where does HTML and CSS fit into this? Marcy discusses how we can bridge the gap and find ways to include people with different skill sets. Marcy also discusses the inclusive community that she has helped build, NW Tech Women, a small group out of Bellingham WA that hosts social events, but also volunteers and pairs with non-profits to make a community impact. Transcript"Heading Gatsby's Learning Experience and Bridging Gaps - with Marcy Sutton" TranscriptResources:NW Tech Women TwitterBlack Girls CodeGatsbyJSMarcy Sutton:TwitterWebsiteGitHubJoel HooksTwitterWebsite

Marcy tells us that her greatest frustration is that for all of the energy that we put into this all the time it feels like we’re stagnant in terms of accessibility actually getting done. And that it’s hard not to get derailed by that. Transcript Nic:    Welcome to the Accessibility Rules Podcast. This is episode… Continue Reading E65 – Interview with Marcy Sutton – Part 2

Marcy tells us that it’s important for folks in the accessibility community to listen to developers’ needs. She also states that we ought to be more positive, and to stop making people feel bad about accessibility! Transcript Nic:    Welcome to the Accessibility Rules Podcast. This is episode 64. I’m Nic Steenhout and I talk with… Continue Reading E64 – Interview with Marcy Sutton – Part 1

In this episode, Robert, Charles, and Wil talk about the whys and hows of accessibility, as well as what makes single page applications special, why they are they harder for accessibility, and frameworks that can do this for you. Resources: #SkyQ app on #iOS from a #VoiceOver user's Perspective Rob's Routing Doc Wil's PR Single Page Apps routers are broken Greater Than Code Episode #92: A11y Ally with Rob DeLuca This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: ROBERT: Hello everyone. Welcome to The Frontside Podcast. This is Episode 111. I'm Robert DeLuca, a software developer here at the Frontside and I'll be your episode host. Today, we're going to be discussing accessibility in single page apps. With me as co-hosts are Charles Lowell. Hey, Charles. CHARLES: What is up Robert? ROBERT: And Wil Wilsman. Hey, Wil. WIL: Yo, yo, yo, yo. ROBERT: Sounds like we're ready to drop a disc track. We're not going to be dissing anybody here. We're going to be talking about helpful things with accessibility in single page apps. Before we get into the nitty-gritty of accessibility in single page apps because we're getting into some deep stuff, I think I want to cover a lot of 'how' because I know accessibility things are usually about why you should be doing it and then they touch on things like, "You should be using alt attributes for your images," but for single page apps, I think we need to go further. CHARLES: It always ends up like, "Then draw the rest of the accessibility owl." ROBERT: Yeah, here's your two circles and the alt-tags are your circles and then the rest of the freaking owl is focus management and everything else that comes with it. Before we get there, what is accessibility? I guess, if we trim the giant umbrella down a little bit from everything that is accessibility that can be physical space things, like wheelchair accessible ramps or things like that, what about just technology? WIL: People need assistive tech to interact with technology such as switches or keyboards and obviously screen reader is a big one but when it comes to the software itself, you could even talk about colors and people who are color blind, so red might not be red to everybody. ROBERT: Speaking from experience there? WIL: Yeah. I'm colorblind. Red is brown to me. CHARLES: Things like hearing and all of it, right? It really is like just designing it in such a way that it can be used by as many people as possible. ROBERT: Right. WIL: And that includes your mom who may not be the best with technology but she still needs to pay your bills online or something. ROBERT: Exactly, yeah and in for context to listeners that might not know, my mom is 100% blind, so it's kind of where it comes from. CHARLES: But my mom is not but she has all kinds of problems. WIL: Yeah, same with my mom. CHARLES: That also falls under the category of accessibility, right? ROBERT: Absolutely. CHARLES: Right, accounting for age and culture. ROBERT: We're blending into the why of accessibility, which is perfect. One of the things that it's such a good segue because what people are starting to realize and I think why accessibility is really starting to catch wind and get some traction is because a lot of people that grew up in the technology age were open in using technology a lot. Our parents probably did not use technology heavily. That's definitely the case for my dad. He still has a flip phone and he says, he's a low tech man living in a high tech world and just refuses to pick up technology but those are the people that just didn't use technology. But now we have a lot of people that grew up with technology and use a lot and they're aging into more disabilities and they're going to need that accessibility, which I think is really interesting to think about because that's a lot of buying power if you're just going to start moving in that needs in accessibility, right? CHARLES: That's true. I know I may need glasses pretty soon, so colors and fonts were going to be heck a lot more to me in the next five years than they have over the last 20. ROBERT: Yup, exactly and that's going to be huge for that and that's one piece of the why, so what are the other reasons that you'd pick up accessibility other than people saying that it's morally correct. I don't like starting off conversations for accessibility because it's the thing that you should be doing. WIL: I think it goes even to my user experience like power users that don't like using the mice or mouse. That's me. I really prefer to just use my keyboard for everything. When the new Firefox browser came out and I couldn't navigate through the menus the way I was used to, I went back to Chrome. ROBERT: That's interesting. CHARLES: I still have not found a good workflow for navigating tabs with the keyboard without just kind of twisting my wrist all out of shape. You have to share that with me but again, that's another thing. That's an impediment that sits between me and the application, that actually -- ROBERT: Which is really interesting, you're getting into a keyboard navigation and focus management, which is really the crux of accessibility for screen reader users and switch users. CHARLES: What I'm hearing is that in this case, including good keyboard and focus management in your application, e.g. making it accessible to screen readers, you at the same time, enabling your power users. I think a great point is that by introducing these very low friction workflows, you're actually going to be enabling other parts of your customer base and not just catering to one, that there are ripple effects throughout your system. ROBERT: It may set it for everyone. WIL: Yeah, not only people who need it but people who don't know they need it. ROBERT: Yes, exactly. Think about the WCAG spec as user experience guidelines. They're not telling you how to implement a thing specifically for a screen reader. They're telling you how to implement it in a way that works for everyone, regardless of what ailment they have. It could be a temporary ailment. It could be a permanent ailment, where they have to use a screen reader or any kind of ailment that you can think of. They're not considering just one use case. It's a broad thing that shows how you can make your application better for everyone. I think that's a better way to look at the WCAG spec than I need to read through this and make sure that this auto complete works for a screen reader. If you look at the guidelines, they're not telling you just first screen reader. They're telling you how to make it work for a switch, someone who is colorblind or who is using a dictation software. I kind of tend to look at that as UX guideline, which really helps me build a better app overall because when you nail down that user flow, everyone benefits from it because it's pretty well thought out at that point. CHARLES: I like that too and I think that thinking of it as user experience and making sure that you have a complete user experience is a good way to think about it because it kind of separates the concerns of, "I've got HTML but is my application really HTML or is it a set of workflows and the data over which those workflows operate?" It really forces you to think my application is not a set of React opponents or web components or Ember components or what have you but really, there's a deep structure to it and it makes you kind of shine a light on that deep structure and try to map its surface. Then, if you really, really know it and you capture it, then you can represent it in any medium. I think it's just a win not just for one niche group of users but also for all of our users and then also for your future users that you don't have because your application is designed better and is going to work. Who knows? Maybe there's some new interface or some new medium, some new device that comes out that hasn't even been invented yet. But if you really have a strong internal representation of what your application is, you're going to be able to be the first to move to that market. ROBERT: Right and like I said earlier, people are starting to aid in the needing accessibility thing. If you need a dollar to justify it, that's going to be a big reason coming up. As a part of the new WCAG 2.1 spec, there is a zoom. I forget what this access criteria number is but the new criteria says your app basically needs to be responsive. That kind of maps directly to what you said earlier, Charles which is like you're going to need glasses soon and fonts and being able to zoom. It's going to be really important. We see that just pop up everywhere. To give a counter example of not just for accessibility like you need it for glasses but the other side of that could be like when we give demos on low resolution projectors or screencast or anything, when we zoom the screen, the apps just still be usable and you should still be able to demo it and that's just something that you have both sides to that, where accessibility kind of works out for everybody. People on the call probably don't need glasses but to see that tiny screen that's being shared, you should be able to assume that. CHARLES: Right. I'm just kind of restating what you said but I want to make sure to call it out explicitly because it was a definitely an aha moment for me, that you basically if you build yourself an accessible website, you build it so that it works on projectors and mobile devices too, so you kind of killed two birds with one stone and you don't have to make a special effort because zooming in the screen is tantamount to viewing it on a phone or viewing it on a tablet. WIL: Yeah, we mentioned it earlier about accessibility and physical space and one of those things is being able to access something from anywhere no matter the device that person is using. ROBERT: Yes. That's a lot of the 'why' of accessibility and I think we did a pretty good job of staying away from the more argument because morally we don't know if it's the right thing to do but a lot of the times it's not in front of you, it's hard to do and I want to make sure that you don't feel bad if you're not building accessibility in your apps. It's not easy. I don't sort of like people get up and say that, "Accessibility is easy. Just do this," because it's not -- WIL: If it was easy, everybody would do it. ROBERT: Exactly. I always come back to accessibility being just like UX -- user experience -- because if it were easy, everybody would have a really great user experience too. It's a hard thing to boil down and to simplify it, right? CHARLES: Right and like every other aspect, the kind of nonfunctional requirement, I say nonfunctional requirement that's a little bit of a contradiction terms but it becomes very hard if you haven't done it from the beginning. But if you didn't start with an accessible app, you weren't thinking about that or you inherited the app or it just wasn't on your radar for whatever reason. If you got a codebase that's two years old, going back and trying to make it accessible, it was extremely hard. It's expensive, expensive, expense. WIL: Yeah, it's going to cost more in terms of money and time to added it after the fact. ROBERT: Exactly. I spent a year on helping on Visa Checkout and there were some accessibility considered in the designs but a lot of the time my feedback wasn't just like, "Yeah, sprinkle some ARIA attributes on there and you're good." It was like, "Do we really need a carousel here to represent your list of carts because it's really hard to navigate around that?" A lot of the times, it ends up boiling up to is this the best way we can represent this data? Is this the best way we can navigate and build this user flow? A lot of times -- CHARLES: And if the answer is no, it's so painful, right? ROBERT: Yeah, exactly, so all that work that was put into building that carousel and all the components that built that carousel together is thrown out because it's just not a pattern that should be used there. Doing after the fact is really hard and really expensive and usually ends up in refactoring anyways. CHARLES: I just want to point that out because a lot of people find themselves in that situation, where they're staring down at a pretty big cost. Now, the reasons why your app may not be accessible or many and good and you shouldn't feel bad, if you're finally in that situation. ROBERT: I gave a talk at Nodevember a couple of years ago called Accessibility Debt and it's just like any technical debt. Your apps going to have it. It's okay. Don't get beat up about it, especially if anybody is trying to beat you up over it, don't listen to them. It really is just like any other kind of technical form of technical debt. It's something that you'll have to deal with and it is just something you have to work through. It's not world ending. It's just another problem to work through. What are some things like everybody usually talks about like the things you can do, the basics for making your app more accessible like using all its attributes and instead of doing a div with an on-click handler, just use a button or don't overuse ARIA attributes. Are there any other things that I missed there like the basics of accessibility? WIL: The biggest is the HTML structure. Screen readers and other assistive tech were built with the standards in mind, so if you're doing nonstandard things like putting divs in H1 and adding ARIA attributes within there, you're not going to have a great time. ROBERT: Right or splattering ARIA roles all over the place, probably not a good idea. That will be harder to debug. Also fun fact, ARIA roles, while you can implement directly to the spec, you may still have bugs across the different screen reader combinations or assistive tech combinations, so that's fine. CHARLES: Keep it super simple is what I'm hearing, like use semantic markup. If you're going to introduce a custom button, still make sure that it's a button. ROBERT: Use the platform. CHARLES: Yeah, use the platform. Don't fight the platform. Probably the best example of that is people implementing their own select boxes. That's the classic example. ROBERT: Wil and I, our lives has centered around that for a little while. It's so true. Usually, it's the first thing people go to grab to reimplement because selects are just ugly. I think Firefox has the ability for you to style select options now like you can change the color and the font but you can't style that. The pop up that comes, usually that's the system dialogue, which a lot of designers don't really like. That's usually the first thing that people go to implement and that's usually actually the first thing that stop somebody from signing up. A lot of sign up forms that I see, if your date of birth is in a select format, that probably will hinder somebody that uses assistive tech from signing up. CHARLES: Yeah. You just basically bounced that entire person. The thing is people don't appreciate the cost. This gets into the whole concept of accessibility that is how much money would that person or those group of people have actually brought into your site versus the cost that you spent redoing that select box. You might be thinking, "It only took this developer actually two weeks," but when you actually look at the actual cost over the course of your application, you're not factoring that into the decision to go with custom select box. Just in our experience, it's just the truly low cost option per quality of experience, that tradeoff there is almost invariably going with platforms select, right? ROBERT: Yeah. Your secret sauce and the best UX that you're going to provide is not going to be nicely styled select box and seriously, a battle that I had to fight a lot was if you really want to implement a custom widget, decide if this is what you want to spend your time on because custom widgets aren't just quick and easy things you implement. You're not going to implement the select that's fully accessible across all the AT combos in a couple of days. CHARLES: It's a lot of work. ROBERT: Yeah. You're going to fall down on a huge rabbit hole. CHARLES: Yeah. It is just you're committing to that work over the lifetime of your application. ROBERT: Exactly, if you can maintain that now. If you implement custom check boxes and custom radios and custom input that of content edible for some reason, I think -- WIL: I think what I see is like custom date pickers -- ROBERT: Oh, I just had a rant about that. CHARLES: Date pickers are hard and there's not really a good option. You just have to open your eyes to the true cost. ROBERT: Right, exactly. That's what I always try to explain, just like you have ownership over this now and you now have to maintain this and you can't regress. CHARLES: Right and if you do regress, it's your neck that gets choked. ROBERT: Yes. A good way to put it. We've talked a lot about things that are just general accessibility but nothing specific to single page apps. I do want to say like a lot of other things that people recommend is like if you're using React, use like the JSX ES1 plugin to help you analyze if you're writing any JSX that might not be accessible or use like HTML_CodeSniffer or aXe to statically analyze the DOM that you have. Those tools are great. I'd see a lot of people [inaudible] those things as like, "Look, this automated checkers says I'm inaccessible so I'm inaccessible," and that's not the case, especially in a single page apps. You can have 100% passing automated checkers but your app also could be 100% broken and why is that? WIL: I don't know. ROBERT: I'm wobbling the router question here. WIL: Yes. I guess that would just be due to routing. In single page applications, they handle their own routing, whereas static web sites and whatnot, the routing is handled despite URLs and the browser and reloading pages. ROBERT: Right. There are probably other major differences between single page apps but the biggest thing is the routing is managed by the client, the JavaScript and on a server-rendered page, you click a link, it's going to rerender the entire page for that next page and the screen reader and the browser know exactly what to do with that, to put the focus back to the top of the page and start working through the page for you. But with single page apps, you're just replacing a piece of the DOM and the screen reader has no idea of what's going on. An automated checker cannot check for this. They cannot tell you if your routes are accessible. The reason I'm bringing this up is because this has never talked about. I don't see in accessibility talks and this is the thing that actually is most broken and makes your app pretty much unusable to anybody that's using assistive tech. There's ways that people if they're savvy can navigate around it but if they don't know what's going on, they're going to think, "All right, I pressed this button and nothing happened, so I'm just going to leave now because it's not working." CHARLES: There's a great video that you point to me, I believe a guy from the UK who has recorded a bunch of his experiences using websites and apps -- ROBERT: Yes, I want to dig it up and put it in the show notes. CHARLES: Yeah. Those are great to watch because you'll really get it. ROBERT: Yeah and that's a really unique case because he's really savvy. I believe, I could be wrong but I think he might have said that he definitely work in tech somehow -- CHARLES: Right. He knows the workarounds and he knows these things but in some of the cases it's like, "If I didn't work in tech, there's no way that I would be able to use this website." ROBERT: Yeah. This is kind of the crux of like if you ever listen to anybody that is an accessibility consultant, they'll say, "You will never ever be able to automate accessibility," and this why I tie accessibility so much to user experience, would you ever have a user experience test that can tell you in a binary fashion? Yes or no, that your app has a great user experience? No, because it's pretty subjective. CHARLES: Of how does your users feel? right? ROBERT: Yeah. CHARLES: You can rate, "My users feel great." ROBERT: Accessibility is like that because there's a lot of context that you have to carry around. It's all about context. When I transition from this page, the next thing does the user have enough context of where they're coming from to where they're going to be able to operate on that page. Is there enough information to achieve the task they want? That is pretty much the crux of why there is no binary yes or no for that because it's contextual. It varies from person to person but you do your best to make sure that that works and that you provide enough information to do something. That's kind of a single page app as a crux. This is why we have a philosophy of testing as a whole. We don't test components individually because again, you can make all of your components individually accessible there but as a whole, they might not work together because you're not providing enough context on an entire page. We did this in one of the apps that we work on, which is open source, so we can link to the PR that Wil wrote for this and I wrote an entire routing documentation around our philosophy and the different things that we tried. How did we manage the focus in that application? I'm kind of just going to lob it over to you Wil since you did the work. Do you want to give context of the holdings and how that all kind of came together? WIL: Yes. One of the features of the app is these panels. It's like this three panel system. When you click an item in a list, a third panel pops up and this goes back to the context thing where if you're using a keyboard, you can't see the screen. You click an item in a list, how do you know that third panel popped up? The solution isn't for a component. The component can't be responsible for this. The list can't focus the item. It opens or vice versa, so this is definitely an application concern, where we needed to check against the route and see whether or not, the pane is opening or was already open or wasn't open before and when this pane opens for the first time, it will just focus it and that gives a lot of the context that the user needs when they click it, like they click an item in the list, it focuses this third pane and they're on a third pane. ROBERT: Right. We didn't even just focus on the entire div. We focused on the heading of the thing that you selected. WIL: Yeah because focusing the div, it might read something off but not all the time. The main thing we're focusing on that third pane opens is the heading to let them know that the item you click, you are now on that page and reading that heading. This is the same thing that would happen if you loaded up that page statically and the screen readers would usually just focus on that first heading. ROBERT: Right. That helped a lot. For a little bit more context, the middle pane is like kind of a master detail thing going on here and in the middle pane there that we have, it's an infinite scrolling list. You have different things there and one of them is like a package. If you select the package and without the focus management and focusing on that heading, you would have to go through every single package that's in that list which could be a thousand of them before you actually get over to the pane that you just opened because source order. You have to go through each one of those. WIL: And it's the same thing is true for power users, not just screen readers. It's like if they want to use tab once that pane open, they have to tab through the entire list. ROBERT: Exactly. It wasn't keyboard accessible and it made it really hard to navigate around with a keyboard because the focus just wasn't being managed. There was a lot of work that we did there. I want to focus on the routing situation there because if you can't navigate around with a keyboard in your single page app, like you click a link and it's not selecting the next thing that should be focused and you provide the right amount of context, your app probably won't be usable without a lot of trial and error to a user, which depending on what your product is, they may not have a lot of patience for trial and error, right? WIL: Yeah. ROBERT: It's really important to try and nail down the routing situation and there are some frameworks and things out there that can do it. In the app that we're talking about, it's React app and we use React router but we don't actually really hook into the router to handle that and that's because React router doesn't provide very much information. WIL: Yeah. You can think of React router as more of an outlet system, where your routes can render anything, anywhere on the page. That's kind of dangers of accessibility and that's kind of the reason that React router can't handle accessible things very well because at any point, the route can just change the button on the page to look like something else. CHARLES: Yeah. It just pop in and pop out. There's no deeper model, right? There's not -- WIL: Yeah, there's no tree. CHARLES: Right, there's the internal state -- WIL: Like a component tree, yeah. CHARLES: The internal state of what is happening is completely opaque. You can only analyze the second and third order effects of the React tree. ROBERT: Right and especially if you have nested route components, it's really hard to determine. One of the things that I've seen people do is focus on mount, which is a very naive approach because what if you have three nested routes, they're all going to focus on mount and the last one that mounts wins and that's a focus for which nobody wins. CHARLES: You all tried that, right? ROBERT: Yes. That's part of the document that I wrote up. We tried three different approaches and we ended up landing on something because we were using React router that was more of like an application state thing, so we were checking props because we knew what the user flow was. We knew what the user, when they come to this page is trying to accomplish, so we're able to kind of figure out from where they came from or where they're going through props and focus the right things for them. WIL: One of the examples, like we talked about the third pane opening and focusing the heading inside but what you know what happens when you close that third pane, you kind of lose contexts again, so we have to focus the previous list item that was active because if you focus back at the top of the list, they've essentially lost their place and the list of results. In that case, we couldn't use on mount. That list item is already mounted. We have to listen to props and we have to look at the route through these props to determine if that third pane was open. If it just closed and if an item in the list is active, it should have focus. It's a lot of logic going on. You have to really understand your app in order to make it a very good accessible app. You can't just sprinkle in ARIA attributes and focus on mount everywhere and think it'll work fine because you're accessible. You have to really know the flow. CHARLES: Right. All those signposts point towards having a deeper application state, a deeper understanding of your application than just the render tree. At that point, it's too late and so by that, I'm definitely lobbying a Reach/Ember router. WIL: Yes. We talked a lot about the React router and we can't really be too accessible with it but to create a React router to go out and there is now Reach router. Robert, have you heard any good things about that? You're the accessibility expert here. ROBERT: I haven't played with it myself, so [audio glitch] things that were lost from the React router three to four transition, I think and also, it's actually accessible routing which is nice because it comes out of the box and you know how to implement it. I haven't played with it. I know Gatsby has implemented that for their V2, that's their default router now, which makes me really happy because a lot of static sites that were being built with Gatsby were very inaccessible and broken which made me sad but now, they're not with V2. I haven't played with Reach router but one of the things that I think it provides which was missing from React router was transition hooks. It has a concept of like where you're going from and to for your routes, which really helps figure out what you need to focus. The one thing I will say about Reach router and I'm sure it's got to be configurable somewhere but I haven't really looked and the demos that I saw, they were just focusing the div of the content that's being rendered, like it kind of just wraps with a generic div or the tabindex="-1" and then focuses it. If you have a lot of content that's inside of that div, it probably will be confusing but at least, it manages the focus somewhere. If you're now off in a no man's land, you have no idea what's going on, at least it focuses that. But if you want to really nail the experience to be better, I would recommend trying to figure out what you should focus inside of that route that you just transition to, what is the best thing. That's for React. There are other things out there for other frameworks, like I am on Ember accessibility team that's out there and we have Ember A11y, which just provide you a focusing outlet for you to be able to just drop in your app and then when the route changes, it does the same thing. It focuses the wrapping div of that outlet that was just rendered. I want to emphasize more in talking about e-holdings work that we did that we were focusing the heading because that told you exactly where you're at and what package you're on or what thing you're on. You know the name of it and now you know how you can go and navigate through that. CHARLES: But it's conceivable, so how would you do that with the Ember router? Would you just introduce some way to delegate down to a particular component? Like when I'm rendered into an outlet, it focus on this component? ROBERT: That would be interesting. I actually don't know. It's been a long time since I've messed around with the Ember router and Ember accessibility. It's definitely a great first step and that's where it kind of came from. I think there needs probably some work done to help implement on what you want to focus. That's kind of where I was going with when we were first exploring the React router stuff and e-holdings was I wanted to have this like high order component that knew of your routing tree and it knew where you're coming from or where you're going. Then from there, it would just tell you, this is the route that we're going to and there's need to be focus management done, like if this prop exists, then you can pick inside of that component that what you want to focus. It leaves it up to the implementor of what they need to focus but it could be probably just like a fallback to the general div because that's not bad. It's a good first step. There needs to be a little bit of work there to get that done probably. CHARLES: Yeah. But it is worth pointing out that by starting from a position of having an externalized application state via the route structure, in an Ember application, you're starting 95% of the way there. An Ember application, at any point, you know where you are and during your transition, you know where you're starting and where you're going to end up and you know when you leave and you know when you got there. ROBERT: Yeah. Having an Ember route pivot handler there, like where you're pivoting from and to is just so nice and it kind of made it click together a lot easier. CHARLES: Right. Reach router looks interesting but as I understand, it's still couched in React components and it feels to me like this is a problem that ought to be solved, that ought to be framework agnostic. Because if I use something like Reach or I use some other routing library for another framework, some other tool might come out that I want to use and I shouldn't be locked in -- ROBERT: Right like what if I really like Redux little router, then I have to make a choice between Redux state that I like or accessibility. CHARLES: Exactly and that feels like a false dichotomy to me. What I would want to be looking for is a platform independent or a framework independent routing library that really just helps you represent your application state and the concrete state in which your application is in at any moment and then, also be able to represent the transitions between those states fully and completely. Then if you have that, you could embed that into any framework. ROBERT: Right. That would be really nice to have. Just like pull it off the shelf and help you out there. CHARLES: If anybody is listening who wants something to do for the next 18 months, no one will thank you for 18 months but you had to get on that. We'll give you lots of thanks then. ROBERT: [inaudible] compare with you. That would be awesome. CHARLES: I would love to be part of that. ROBERT: Yeah, that would be awesome. To kind of tie back to other things, I don't know too much about Angular but I'm sure there are solutions out there to help with Angular. I know Marcy Sutton used to do a lot of work in the Angular world, so I'm sure there's something out there that helps with that. I just don't know off the top of my head right now. I wrote a Medium 'think piece'... No, I wrote a little medium blog post about how all of single page out for routers are broken. I was pleasantly surprised by Vue. Vue brings its own router and their router has a concept of before each, so before each route transition you can run some code and that really helped with implementing the live, the announcer pattern where you use ARIA live to announce something but even beyond there, if you wanted to dig in there, you could probably figure out where you're transitioning from and to and give that next route some kind of attribute that says, "This needs to be focused. Figure out what you need to focus there and inside that route, you can focus wherever you want." I thought that was a really awesome. That's kind of the crux of what I was missing from React router. I wanted the concept of knowing where I'm coming from or where I'm going and I would help with everything but unfortunately, that kind of doesn't exists because they're just components. For better or for worse, they're just components. CHARLES: The world is so much more than just components. ROBERT: Yeah, a little bit off topic, I think it's kind of funny how React kind of just shoved everything into the Vue layer, just to make it all a component. CHARLES: Yeah, it's very easy. ROBERT: Yeah, until it's not. CHARLES: Yeah, exactly. It's easy but it's not simple. ROBERT: That's a lot of talking about how routes need to be done and what you can kind of do to manage focus. It's really about managing the context and how you can provide the most contexts. For somebody to operate on that information, can they complete this thing? What can you do to make sure that you've done this properly? What steps can you take to make sure that you actually are accessible and that your routes work? WIL: Manually testing those screen reader is probably the biggest thing, you know? CHARLES: Yeah. I think the biggest thing is really watching someone who uses assistive tech on a regular basis use your application and then trying to use it yourself. WIL: Yeah. ROBERT: Right. Yeah, I'll definitely -- CHARLES: If you can get a little bit of this yourself but then it's kind of like someone who is never used a mouse before and trying to learn something new. What really helps is seeing someone who's good at it and see how their expectations are either being met or not being met. ROBERT: Yeah, it's definitely the best way. If you can find somebody that actually relies on assistive tech, there's nothing that beats that kind of feedback. If they get to your app and they're really confused, I see some people that just dismiss it because they just don't understand. That is the best feedback you can actually get. If they don't understand what's going on, you have -- CHARLES: That's on you. ROBERT: Yeah, that is going to be what happens for everybody that uses that. Well, maybe not everybody because everybody has different experiences but it's probably going to be a thing that pops up everywhere. But if you don't have access to people that are actually using assistive tech regularly and are pros at it, WebAIM provides really great tutorials for how to use a screen reader. If you're using a Mac, you have a screen reader built in and you can use that called VoiceOver. If you ever want to turn it on or turn it off, its command F5. WIL: You might have to have that shortcut enabled, though. ROBERT: Really? I'm pretty sure it's quite default. WIL: I thought I had to enable mine but I could be wrong. ROBERT: It's interesting. CHARLES: Yeah. They got great tutorial too. It's like it notices the first time you turn it on, so it tries to help you navigate bullet lists and select boxes and input fields and check boxes and all kinds of good stuff. ROBERT: Yeah. It gives you a little bit of a boot camp but WebAIM also helps with specific to website and stuff because one of the things that we ran into while working on the e-holdings project is they're transitioning from a native app to a web app and there were just things that you can do on a native app that you cannot do on a web app. Just keep that in mind also when you're testing, there's just things that will behave differently. Like you're not going to have a lot of crazy key shortcut commands like you're not going to press command F to get to the search box if your app has a prominent search box because that is going to clobber a bunch of other assistive tech key commands. WebAIM is really a good help with giving you the tutorial of how to test a web app and many different screen readers, so they have it for JAWS, they have it for NVDA, they have it for VoiceOver iOS, they have it for TalkBack, which is the Android screen reader. There's a lot of really good resources there for you to start using as screen reader and test with your app. I highly recommend using it with a screen off. You gain a lot of context by looking ahead of your cursor and -- CHARLES: Yeah. It's true. ROBERT: -- The example that I usually give to people is like, "I worked on Visa Checkout. I went through that checkout flow pretty much every day for a year and eight months in, even then turning off the screen, I was still lost." Even though I knew what each screen was and what each component was there, I would find myself confused of like, what just happened and it's because sometimes, you'll get into something like you have a dropdown that sets the focus inside the dropdown and then the dropdown disappears from the DOM and your focuses in nowhere. You're like, "What is going? what am I doing. I don't even know where I'm at," and I turn the screen back on and I'm like, "Oh, now, I know what's going on." CHARLES: Right. It really is a lot like interacting with your application as though you were interacting with Siri or Alexa but with a keyboard instead, instead of voice commands. That's an excellent point. We would understand if where would Amazon be if Alexa couldn't successfully navigate those situations. The counterpoint or even the flip side of that is if you model your web application in such a way that it can handle that type of serial interaction, instead of the highly parallel environment to being able to perceive huge amounts of information concurrently, like you can on a screen, if that were effectively serialized, that means you could represent your application through nothing but voice commands. ROBERT: Yeah. Did you provide enough context for me to build this mental map is really what I'm going on to? CHARLES: Yup. ROBERT: Which I always thought was really interesting because I always wanted to know how my mom visualizes what a website looks like because it's wildly different than any of us. She's never been able to see what a website looks like. Does it look like a bunch of nodes and graphs and webs connecting to each other and how things pieced together? It's just a different way. But it's not only about screen readers, right? You can use a keyboard to navigate and that's definitely what we did with e-holdings is like can we tab through this [audio glitch] list, hit enter and go into the detail record, edit it, close it and go back and edit another one. Is that something that we can do with just a keyboard, not even a screen reader? WIL: And with the keyboard, we're not talking about shortcuts to hit edit. We're talking about like tabbing over and hitting enter like people with accessibility issues would have to do. ROBERT: Right and that's kind of a good segue into creating use cases. If you want to know if your app actually works, if your screen reader users or if your keyword users or if your dictation users are going to be able to navigate this app, create use cases. Things like actual user flows like how would somebody actually going to use this app? What task are they going want to complete? In that case, e-holding was like an electronic holdings management system for libraries. They probably want to get in there, add a couple of books or whatever you might have to their library and get out. A use case could be like, "Can I search for this thing? I'm going to search for something specific. I'm going to go through the list, find the thing that I want. I'm going to add it, close the pane, go back and then remove one thing and can they complete that flow successfully without running into any issues or any blockers or any showstoppers." I can tell you before we did the routing management stuff, you would hit search and that was it. There was nothing else that you could do. CHARLES: Yeah. They wouldn't even announce that anything can happen. ROBERT: Exactly. WIL: Yeah, and with these librarians, it's not necessarily a matter of they can't see the screen. It's just that they don't use the mouse because they're power users. ROBERT: Right. They don't have any disabilities but that was essential to the workflow. CHARLES: Yeah, exactly. Do that change. You just lowered the activation energy of that workflow by... What? three orders of magnitude? WIL: Yeah, at least. ROBERT: Let me click here right now. I can tab, now I can tab. Right now, let me click here and now I can tab, I can tab, I can tab. It's not as nice as just being able to completely do it through a keyboard. Through us making it super keyboard accessible, that also became super screen reader accessible and the people who use dictation were able to work through and get through the app and use it now, which was really cool. It really helps when you go for those things and create use cases to really figure out how a user is actually going to work through this app. That's the best way. Just get right through it. With Visa Checkout, we're like, "Can somebody buy something?" or if they don't have an account, can they sign up and buy? those were some of the use cases that we had because it turns out, those are actually pretty important to the business. That all have been said, you also can test your components for accessibility individually because even at a smaller level, some of your components might have to manage focus. The best one I can think of is models. When you open a model, you should trap the focus inside of that model and you should be able to hit escape to close the model and when you close the model, it should go back to what triggered the model to be opened. These are all things that are individual that can be tested also. But just because your components are individually accessible, it does not mean your application as a whole was accessible either. I don't want to paint the picture like, you don't have to care about your components accessibility individually because you do. It really does help but I think a lot of people miss the whole of the application, rather than individual with components. CHARLES: Right. The components are the individual stitches but you have to follow the thread throughout the entire garment. ROBERT: Right, exactly. CHARLES: Man, what I really want to do is I want to find out how your mom visualizes website navigation and use that as a visualization technique. ROBERT: That might be a fun webcast or something. CHARLES: Yeah and then see like could we actually use it as a tool because I have to imagine, it's probably pretty simple. It's much simpler than what we think of when we think of a website because it has to be really condensed down to its essence. ROBERT: Right. Yeah and [inaudible] users, they're not dumb. They have different ways. They know the gotchas. They know things that happen. They know there are different ways of getting trolled like my mom knows about focus jumping and she gets irritated what happens but she knows generally of what to do and it depends on her patience level. Like if it's focused jumping, she's like, "I don't need to use this thing. See you," and it's just not worth the frustration but there's different ways to navigate around like if you're a real power user, you might be able to recognize like the routing is inaccessible and you can navigate by headings or by regions or different landmarks. There's many different ways for users to navigate but to use those different navigation methods, you need to have a real strong coherent document structure. Your H1s have to actually be H1s and you have to have some things that they can navigate around to kind of work around those things. It's interesting and basically, do everything you can to help those situations. If you can provide semantic markup and give it a proper structure. If you can do the focus management, it's going to help everybody. It really will. I did see when we went through the use cases and defining those things, we actually learned a little bit more about our product because we had to put ourselves in a different seat and think about it because you get real close to it. You go through that same flow nine million times and you pick up real power user things that you can do like, "I'll work on that. I got this. I'll click this button. All right, we're good." Somebody that's going through it for the first time and you put yourself in that seat, it kind of opens your eyes a little bit and makes the experience better for everyone. I think that's kind of the underlying tone there. That's the message. WIL: Yeah, accessibility makes things better for everybody. ROBERT: That was a lot of content thrown at you there. We covered what is accessibility and why you'd want to do that and then kind of like more the basics things and how automated tools are really helpful and they can help you pick out things like using improper roles and nested things but they're not going to be able to tell you if your application is truly accessible or not and never will, unless we get something like a headless screen reader, where you can write automated tests for in that fashion but you're not to get something that will just run over you app and go, "Yup, you're good." CHARLES: Even so, it's a matter of user experience and that's not something you can get a thumbs up or a thumbs down to. When you as a user, it comes with application, you know when you see it but I would say until we have androids that accurately simulate human beings, I don't think we're going to actually have automated testing. ROBERT: Yeah. There's a joke for accessibility consultants. It's like if you put four accessibility consultants in a room and tell them to give you an alt attribute for an image, you'll get four different alts. We talked about the automated checkers, right? They'll not going to get everything for you and we talked about single page apps specifically in the routing and how we handled the routing in a React app and then how you can probably do it in an Angular app and how you can do it in an Ember app and Vue and different methods of how you can kind of attack that. We're definitely giving the link to the document that I wrote and the PR so you kind of see the real 'how' of how we did it because that would probably be helpful. I think there was a lot of good information there, so I would like to thank both Charles and Wil for being awesome co-host on this and -- WIL: Thanks for being an awesome host. CHARLES: Yeah, thanks for being an awesome host. I should say, you're welcome. ROBERT: I tried, I tried. We are The Frontside. We do accessibility consulting and training. If that's anything that your team needs help with, we're more than happy to jump on a call with you to kind of figure out what your needs are and what you need to do. If you need a WCAG support statement, if you need to audit, if you just need to figure out what's the next steps for you to even do, we're more than happy to help you sort through that. To reach out for that, you can contact us at Contact@Frontside.io or Sales@Frontside.io or Info@Frontside.io. You can contact us at any different ways and we'll be more than happy to help you. As always, thank you Mandy for producing the podcast. You're awesome and the next episode, what we're going to have is also still accessibility related and I'm really excited about this. It's about writing a proposal to the Unicode Committee and getting it accepted so basically, writing a proposal to get an emoji added and that's with Amberley and Amanda. They wrote three or four Unicode specs and actually got them accepted for, I believe it was sign language and deafness. That's really cool and I'm super excited for that because they'd be the first people that I've ever talked to that have actually created an emoji and gotten it accepted. WIL: Yeah, it's pretty cool. CHARLES: Yeah, that must feel great. ROBERT: Yeah, it's going to be awesome. That's our next episode. If you have any ideas or comments or anything, you can tweet us at @TheFrontside on Twitter or you can contact us through any of the emails that I talked about earlier. We're always open to hearing feedback. Thanks for listening. Take it easy, everyone.

A recording from Script'18 (https://scriptconf.org) Radically Accessible Internet Applications

In this episode, we are joined by Shirley Wu and Brian Holt to talk with us about the various experiences we’ve had with startups, large companies, agencies, and freelance work. Guests: Shirley Wu - @sxywu Brian Holt - @holtbt Panelists: Ryan Burgess - @burgessdryan Augustus Yuan - @augburto Jem Young - @JemYoung Mars Jullian - @marsjosephine Stacy London - @stacylondoner Picks: Shirley Wu - Team Lab Brian Holt - Kubernetes Ryan Burgess - Evil Genius Augustus Yuan - Model Zoo Augustus Yuan - Human Benchark Jem Young - Google Doubleclick Mozilla Jem Young - The Strong Web Mars Jullian - Hiya Mars Jullian - Explained on Netflix Stacy London - CSS Conf - Laura Schneck algorithms of CSS talk Stacy London - JS Conf EU - Beaker browser by Tara Vancil Stacy London - JS Conf EU - Empathy driven development by Marcy Sutton

This Frontsider panel episode explores what virtues go into making quality software, such as having tests, making sure software is performant and accessible, and why you should try to avoid technical debt. Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 98. My name is Charles Lowell, developer here at The Frontside and your podcast host-in-training. With me today, we're going to have a round table, a Frontside round table. With me today is Elrick. ELRICK: Hey. CHARLES: Joe. JOE: How you doing? CHARLES: And of course, Will. WIL: Hello, hello. CHARLES: Welcome, y'all. We're going to be talking today about some of the things that we do around here, aside from trimming the shrubs and making coffee and snacking on Altoids. Like, way too many of them. Yeah. I was thinking we could talk a little bit about software qualities of relative things, like this software has these qualities. And I think that that kind of lofty goal of software quality is comprised of having a bunch of little qualities. The quality of having fewer bugs or the quality of having these things. And so, talking about all these things that we do and kind of what we do to make sure that we continue to do them. Or the ways that we can ensure that our software has these things. So yeah, we can just start really anywhere. WIL: Yeah. So, one core thing is obviously tests. CHARLES: That kind of falls under we want to have – really, there's two qualities there that we want, right? Is we want to have… WIL: Maintainable software. CHARLES: We want it to be maintainable. We want it to be resilient to change. And we want it to work properly, right? Yeah, so we put tests in place to make sure that that happens. JOE: Tests also inform design in a really positive way. A lot of the time, anyway. WIL: Another thing that we like to include in our apps is responsiveness. CHARLES: Yeah. And just making sure that you have – that it works on a multiplicity of devices, right? WIL: Yeah. And not just the devices, but browsers as well. CHARLES: Yeah. And it turns out it's actually really hard to do that after the fact. WIL: Right. JOE: Yeah. CHARLES: Making sure that lots of browsers, lots of devices. Because yeah, sometimes you have some weird screen width that is on some weird device, and making sure that that works. I guess there's some overlap with testing there, too, isn't it, right? Like you want to be running your tests on those devices at those resolutions to make sure that they're going to work. This is something that we aspire to but I don't think we're quite there yet. It was making sure that our applications are accessible. WIL: Yeah. JOE: I'm very excited to learn more about this as we get into this, yeah. CHARLES: Right, right. And asking the question, how is it that we actually can ensure our applications are accessible? We have very paved roads for making sure that our applications are resilient to change and that they have low bug rates and that they're well-designed via testing. But what is the analog of testing for accessibility? What's the way that you can put those guardrails in for accessibility? I have no idea. And that's an ongoing conversation here at Frontside. JOE: So, I guess I'm curious as to what technologies are actually involved in accessing a web application in – would it be reasonable to say a non-traditional way? I know there's such things as screen readers, but is that all we're talking about? Or what is the ecosystem that we have to consider supporting? CHARLES: I'm certainly not an expert on this. We'd have to get Rob in here to chew our ears off this. JOE: Yes. CHARLES: But from what I've picked up from him and from our conventions with Marcy Sutton and some other folks that we've had on the podcast, it's a big umbrella. So, it's anyone using an application in a non-traditional way. So, whether that can have to do with limited vision, hearing, movement, range of movement, cognitive ability, it's a gigantic whale of a domain. WIL: Yeah. The topic of accessibility can definitely be several podcasts on its own. CHARLES: Yeah. One thing that we've talked about is it would be great if you could drive your test suite through a screen reader or something like that. What would that even look like? There are a couple of open source ones out there, but they're Windows-only. I think it was NVDA was the big one. And then you have a screen reader that then drives the applications in your operating system, so it's going to vary per operating system. So, making sure that it's accessible on Windows, at least as I understand it, is very different from making sure that it's accessible on a Mac. JOE: Yeah, it's like a whole other layer. And it's like BrowserStack outside of the browser. CHARLES: Right. WIL: There are things that you can do from the beginning that will make it easier when you get to that point. It's just like using semantic HTML, knowing when and how to use proper aria labels. All these things, if you do it from the beginning, it's not as big of a task as bolting it on afterwards. CHARLES: Right. And I think we do have a leg up when it comes to web applications. It's within our power to change. There are cross-platform of those technologies. But as you said, it's important to put them in from the beginning. Because as we've seen, for each one of those categories, you're accumulating debt if you don't address it. So, there's technical debt. But I think that technical debt can [inaudible] into a bunch of different areas. So, there's technical debt in terms of the internal quality of your architecture, the way your software components talk to each other. And I think that that's what people mostly think of when they talk about technical debt. But I think in terms of responsiveness debt, there's a slice of the technical debt pie that has to do with making your application responsive. And so, if you don't address making your application responsive, you're accumulating debt and you might not know it. And if you're not making your application accessible, then from the beginning you're accumulating debt. So that if you have to go and try and figure out your accessibility story six months, a year, two years, you might actually uncover and say, “Whoops. I've been swiping the accessibility credit card. And holy crap, with all this. All my fines and penalties and compounded interest. Now I'm accessibility bankrupt.” And that can be scary, right? WIL: Yeah. And a lot of people don't realize with all this debt after the fact is they think they're going in and adding things like responsiveness and accessibility and tests. But really, you're also taking away previous work that's already there, things that need to be refactored. If you put these things off, you're not just adding a few hours of time. You're inflating your time exponentially. CHARLES: Right. Right, exactly. It can be intimidating but I think it's also empowering, because technical debt is like a scary subject. But if you're like, “Oh, we can actually slice our technical debt into a bunch of different categories and address them individually,” just knowing that this is an area where debt can accumulate, that's half the battle. Because the worst thing is debt you don't even see. ELRICK: Yeah. WIL: I mean, [inaudible] is big. That's a big part of accessibility, that, is most people don't think of accessibility. So, that is a huge debt that a lot of companies don't see. JOE: What about something like internationalization where I feel like I've never been in an application where that wasn't punted on to some degree. That's kind of a well-known problem, but it still takes a back burner. Do you think that if accessibility had more exposure as a concern, would it actually get the attention it deserves or is it kind of destined to, “Oh, we'll get to those yaml files later. We'll send those off for translation later,” that type of thing. ELRICK: I don't know. Sometimes I feel as though people feel as though they're trading speed away when they're building applications when they go to implement these things. Like, “Okay, well we're not really going to touch on these right now because that's going to slow us down from pushing out features.” Which is not really true. Because if you don't settle on these things early, you're not really building a solid foundation for your application in the long haul. So, I think people are like, “Oh, we'll just do it later.” CHARLES: Right. ELRICK: And, “We'll just ship features now.” CHARLES: Right. I think that's exactly right. It has this kind of secondary effect where not only do you develop the debt but you develop a culture of accumulating debt, right? Like when it comes to people getting a hold of their finances, the first thing that they have to change is they have to change their spending habits. And that can be the hardest thing. It's not just balancing the equation. It's like saying, “I need to readjust my thinking about this.” ELRICK: Yup. CHARLES: So that I'm not consistently put in this situation again. JOE: So, there's an operative word there, right, in personal finance in that usually if a company is addressing technical debt especially down the road, something that they've punted on for a while, it's far from personal. There's a board of directors or there's a special interest group involved. There's people who want features that are putting money into it. There's a lot of pressure as the company grows and more people are involved. Priorities are more likely to be lost, I guess. CHARLES: Are you saying it can be hard when your culture is spread over that many people, it can be hard to shift? JOE: Absolutely, yeah. And I guess to keep with the dash-first thing, ideally were we starting a company, we would want to start a culture for this company. A culture that recognizes the vulnerability that we all have to technical debt as applications grow. We want that upfront. But the reality is, you know, startups are eager to get things out. Companies that have been around for a long time have high-paying clients that they depend on that want certain things. And yeah, I guess I'm just saying that it has to come in from the beginning. CHARLES: Yeah. And I think that – I don't want to completely disparage technical debt entirely, because technical debt like actual debt, like financial debt, is a powerful tool that you can wield. But it's also, it's like a table saw. You can also easily slice your finger off. It doesn't mean that it's not a useful tool, right? If anyone's bought a house, it's really great that you can borrow money to buy a house. It's great that businesses can borrow money and get small business loans to get bootstrapped. And that benefits us all to have that community. I don't think that – yeah, startups definitely, they need to have technical debt as a tool that's available to them. But they just need to understand the consequences of it and be able to get a hold on it. JOE: That's a super interesting take. I never considered it that way before. CHARLES: Yeah. It's definitely not my take. I actually think the person who coined the term ‘technical debt', that was the original idea. But then people realized that technical debt can also get way out of hand. WIL: It's just like real debt. If you're not paying down a certain amount every so often, it's going to keep growing. CHARLES: Yup. You're going to have to declare bankruptcy at some point and throw out the piece of software if you don't pay a down. And that's going to be more expensive. ELRICK: Yup. That's definitely true. So, I have a question. And we see this all the time repeating itself at various companies, whether it's a startup, a large company, where they put off testing and mobile-first, user-first, accessibility-first. Like all the firsts, they just toss it to the side. Why do you all think that that happens so frequently? CHARLES: I think it comes into people not understanding that if you don't address it from the start, it won't happen naturally. There is a prime motivator that has to happen. If you don't imbue something with those qualities when it's tiny, when it's a tiny seed, a tiny crystal, you're going to have to drill through layers and layers and layers of core to put it at the crystal to begin with. I like to think of software as kind of like a tree. And we eat the fruit of the tree, and that's the features that users use. And we can tell that a fruit is delicious merely by placing it in our mouths. And we can tell what fruit is bad. But we can't really look at the fruit itself to say what caused this fruit to be good, what caused this fruit to be bad. We have to look at the tree. And I think that that's what people miss when they're developing software, is that what you really want to do is you want to build a tree that builds good fruit. You can't just take the fruit off the vine and say like, “Hey, I've got this peach but it doesn't have enough sweetness. So, I'm going to take a syringe and I'm going to inject glucose around it and make it less tart.” You say, “I want a sweet fruit,” right? ELRICK: Yeah. JOE: You could probably actually do that. CHARLES: You could. And that might be a strategy. And we see a lot of software that has those qualities of, “Oh, we're going to make this accessible,” or, “We're going to try and make this beautiful.” I happen to think that pigs are adorable animals and look great in lipstick. But that [laughs]… you could put lipstick on a pig but people can tell. And you can say, “Oh, this peach needs to have softer fruit,” and you can whack it with a mallet to actually make the meat more tender. But people are going to be able to tell. So, what you really need to do is you need to care for the peach tree rather than worry so much about the fruit. Because if you have a healthy tree, then you will have healthy fruit, right? ELRICK: Yeah. So, you want to plant good seeds. JOE: Yeah. WIL: Back to you question, Elrick, about what motivates startups and other companies to put off these things. I think the biggest thing is just time and money. They have this misconception where they're saving a little time and saving a little money now just to add it back later. But in reality, it's going to cost them tenfold time and money for adding it later, versus just spending that little bit of time and money and all that to begin with. CHARLES: That's true. JOE: It could also boil down, as far as just personal intimidation. Not so much like a business side of a thing but maybe just, think of all of the things that you listed, Elrick. It was almost a dozen dash-firsts in there. If you're sitting down at a startup that you started with three friends and just approaching these things for the first time, that's a lot to tack on right upfront. It's intimidating. CHARLES: It is intimidating. I think my message to those people is I've felt intimidated by that. I think my message to those people is like, the nice thing about it is if you attack those, if you tack all of those things from the get go, the features will take care of themselves and feel more effortless as you go on. You say like, “Oh, well actually, I don't worry about a high rate of bugs.” I want to say recidivism, but that's not the right word. A high rate of return, not on money but on – or high rate of bouncing your users. You don't want that. And if you bake that in from the beginning, parts of the software development cycle that were stressful before just aren't stressful anymore. So, if we say, “We want to have a system that is easily maintainable, well let's put that in from the very beginning.” We say that a lot. We deploy to production on day one. But what that means is, we say we have this value that we want the system to be easily maintainable. And so, we're going to do it from day one. That means that we actually – it's not something that we worry about so much on down the road. Whereas that used to be very stressful. I don't know. I remember when I started my career, there were these long release cycles where every six months, you'd release software. And the last month was just absolutely terrible as you try to stand this thing up and get it into production and then realize it's not monitored. There's no one checking the health of this thing. So, it's pissing off users at one in the morning. And… WIL: Beepers. CHARLES: What's that? WIL: Beepers. CHARLES: That's actually a great – there's a story there. The one time I got a beeper, I went canoeing in the canals of London and I tipped over my canoe and I dropped both my cellphone and the beeper that they've given me. ELRICK: What? CHARLES: I never got put on pager duty again. [Laughter] JOE: I'm going to use that next time [inaudible] with an on-call position. That's a good move. CHARLES: I remember, I definitely remember how sour my manager's face was when I turned [inaudible] the cellphone that was like, dripping with water. JOE: He was eating bad fruit, probably. CHARLES: Yeah. [Laughs] So, the other thing is we like to build beautiful applications, right? So, you have to – that match the user experience. You have to spend that time on design and beauty upfront. You will not have a beautiful application after the fact. You just need to bake it in. ELRICK: And accessible design. CHARLES: Exactly. ELRICK: Don't forget that one. CHARLES: Don't forget that, right? A responsive design. WIL: Yeah, accessibility-first in design. Yeah, responsive and all that starts in design phase, yeah. CHARLES: Yeah, all that, right? So, you want a great experience. You want an accessible experience. You want a responsive experience. You want a quality experience. You want a performant experience. That's another quality that you say. Like, “We're going to make sure that this is performant.” If you want that – and that's something that we're not always great about, right? We don't actually put in benchmarks for our software from the get go. But maybe we should. But there's perhaps a hidden cost there that we might be actually accumulating performance debt that we don't even know about. JOE: That's true. ELRICK: Interesting. JOE: So, things that pop up that are new. Like, accessibility wasn't probably always a thing in computing. Internationalization probably wasn't always a concern. Beautiful certainly wasn't a concern if you look on Wayback machine. You will see that to be true, right? [Laughter] JOE: So, all code is tech debt, I would argue. Or at least has the potential to be. And yeah, as the ecosystem as a whole evolves, being responsive to that, having plasticity in that respect, sort of like meta-first. CHARLES: Right. JOE: That could be the real challenge. WIL: Yeah, Charles is mentioning all these experience things. And so, I was thinking X-first is simply experience-first. You want you users to experience a certain quality of your app. That experience needs to start in the conception phase. CHARLES: Yeah. ELRICK: That's true. And even your developers coming in, developer experience. JOE: Yeah. CHARLES: Right. And I think the core of that X-first, that experience-first, is you need to pick which experiences. Because you can't have everything. JOE: Right, yeah. CHARLES: One, there is going to be too much. You have to say, “I'm going to sacrifice on knowing that this is a performance thing. I'm not going to include that in the core DNA of my application.” And there's just going to be things that you don't know about yet that are just unsolvable problems or that don't necessarily work. And you can say, “You know what? Hypothetically, I'm not going to make this an accessible – I'm not going to focus on accessibility.” But then you need to own that. And you need to know that you're accumulating a huge amount of debt around that. And then I think that is a particularly bad trade-off because someone's always going to come along and you're going to have to know that your application is accessible. I think once we clamp down on that, that's going to be something that we have a strategy for and we include at the beginning on every single application, right? ELRICK: Yeah. CHARLES: But I think you need to have, almost like holding the cards in your hand, say, “These are the cards. These are the X's that I'm going to have in my hand. And they are going to be core to my app.” And they're going to be part of the DNA of that tree. So that I know that the fruit is then going to have those qualities. JOE: And then you as an engineer, that goes through an iterative process as well. Just starting out, you have no idea what that DNA should look like. And short of learning from people who are wiser than you who are around you, and reading blog posts and whatnot, really the only way to know the pain of strong-arming internationalization for instance into a 15-year-old Perl application, is to go through it. And then, you know, future trees will not have this DNA. CHARLES: Right. Right. And that's the other thing. Is if you are going to include, if you are going to try and splice something into the DNA, there's a lot of work. And you just need to go for it. You acknowledge that it's going to be a lot of work. And you need to, you just need to own it and go for it. And pay that expense of actually getting it deep, deep, deep into your application's core values. So that then, you don't have to worry about it anymore. Otherwise, you're going to be paying – you're just basically signing up for a lifetime of debt. Right? WIL: Yeah. And then to make the debt analogy even more, it's like people don't understand the total debt. The end debt. People get a $30,000 loan with a 4% interest and they think they're paying back that $30,000 loan. But really, they're paying back $36,400 after all the amortization of their interest. The debt is higher than you can see, always. CHARLES: Right. WIL: And it's true in tech debt, too. React is the new hot thing now, but in 10 years we're going to be on React debt that we're migrating away from. JOE: I hope so. [Laughter] CHARLES: Maybe less, I think less than 10. WIL: Yeah. The debt is always there. And people don't realize how much they have to pay on top of what's visible. JOE: Yeah. It's an invisible vig. CHARLES: What's a vig? JOE: It's interest, in the mafia. CHARLES: Oh. JOE: Sorry. Yeah. CHARLES: I forgot you're Italian. JOE: Yeah. ELRICK: So, for people that are listening, they might be in a situation where they need to advocate to the powers that may be these X-first values. What do you all think that some of the approaches that they should take to say to whomever it is that, “We need to do this first”? Because there's times where you might say, “Hey, we need to do this first,” and people just look and say, “Oh, maybe not.” Then you need to push back on that. CHARLES: In my experience, I find that the tech debt argument is a good one. Because I think it can be, it's both limiting and empowering. Because sometimes it really is the right call to pull out your credit card and put something on it. If you need to buy water and you need to buy food and you don't have any other means, man, put it on the credit card. Right? Seriously. Even if you have no idea how you're going to pay it back. Like, whip that sucker out and stick the chip in. And it doesn't matter how much it costs. And so, sometimes that is the right call. But I think draining it of a moral or a value as a human person thing, and approaching it from a business decision and saying, really trying to attach a cost to it. Because then I think if you can drain out the emotion of it, because people really want something. They're striving to go get it and trying, give them tools to think about it rationally. That I think is a good strategy, to just say, let them know that there is a debt that's being paid here or that's being accumulated here. And it's really large. And maybe even say, “Look, if we were to put this off by six months, this might cost not twice as much. It might cost ten or even a hundred times as much.” So, by saving $5,000 now, you might actually be accumulating $50,000 worth of debt. It's [bigger] than you think. But I do like – so, I think that's one important tool. But I think then also the other important tool is to say, “If we are going to attack this, let's drive it home. Let's put it at the core. Let's make this a value that we hold so that the tree can take care of the fruit itself.” So, if we say that we're going to put in accessibility – because not all projects are greenfields. JOE: Absolutely not. CHARLES: So, what's the message to them? Sorry. You're just SOL. I think if you're a year into a project, two years into a project, and you realize, “Oh no. We need to do internationalization,” recognize that that might be something that's – that's a pillar of your architecture. Or, “We're going to make this application accessible,” don't half-ass it. WIL: Weave it in. CHARLES: Say, “We're going to transform this. We're not going to add accessibility. We're going to transform what we have into an accessible application.” Or, “We're going to transform what we have into a beautiful application.” Otherwise… WIL: Yeah [inaudible]. CHARLES: I would say leave it ugly and focus your efforts elsewhere on things where you do have your values straight. Because you're never going to have everything in line. JOE: No. WIL: Treat software like immutably. You don't add something to it. When you want to add accessibility, you're creating a whole new accessible app. ELRICK: Ooh. That's deep. CHARLES: Yeah. JOE: So, having seen – I don't know. I think it was very apt, looking at it as a business decision. I've seen it go the other way. Because at least among engineers and people on the technical side of it, this can become a very strong moral issue that people feel very strongly about. CHARLES: Because we have to live with the consequences quite honestly, right? JOE: Exactly. And that's a hard thing to translate to say an executive board that may be three levels abstracted away from you and is making those decisions. I've seen people attack or approach this I guess with that emotion built in, with the, “This is the right way to do it. Everybody else is doing it wrong.” It gets nowhere, basically. What needs to happen I think, so you talk about having this beautiful tree. But that also requires beautiful gardeners. And so, where the moral thing or the interpersonal thing comes in is there needs to be kind of an inclusive and encouraging environment that is fostered among the people tending to the tree. And that's a totally separate thing than selling the business value of it. Those things should be completely divorced. CHARLES: Yeah. It's funny. It's always hard to reconcile those two things, right? Because on one you have, “You have to take care of the raw consumption of material and the output of product.” But then also trying to – so, there's some baseline math that has to happen but making sure that that goal, it doesn't slice people. And can enable them to be happy and feel like they're doing good work. And that the things that they're doing is having meaning. It's probably an insoluble problem that we're going to be dancing around for as long as people are around. If there's one thing that we've come to recognize around here, and we've stated it many different ways from a bunch of different angles through the course of this conversation, and I would say through the course of this podcast, but that is if you want to see something in your software, make sure that you attack it from the get go. ELRICK: Intertwine it in your DNA. CHARLES: Exactly. And then you can actually experience the fruit, rather than trying to always, always trying to jam it and change it and get it into the taste you want after the fact. So, I guess that's it. Thank you so much y'all, for this conversation. I really, really enjoyed it. For those of y'all listening, if you want to continue the conversation, you can get in touch with us we are @TheFrontside on Twitter. Or you can drop us an email. We're contact@frontside.io. So, thanks Elrick. Thanks, Joe. Thanks, Will. JOE: Thank you. WIL: Thank you. ELRICK: Yup. It was great. JOE: It was fruitful. [Chuckles] ELRICK: Frontside-first. CHARLES: And well, we'll see y'all around.

Reminder! Script'18 is happening. Check out the program at https://scriptconf.org and see speakers like Evan You, Marcy Sutton and Andre Staltz. I met with my buddy Daniel Khan (https://twitter.com/dkhan) for "Coffee", or a hoppy equivalent you have at around 5pm on a sunny afternoon. Daniel and I know each other for a long time, and somehow we ended up at the same company roughly the same month. Albeit in totally different teams, our paths keep crossing. Mostly because we share the same passion for Node.js. Daniel and I also share similar views in how we view our skills. And more importantly: The lack thereof. The Dunning-Kruger effect or the more friendly Socratic paradox helps us to lead a more humble and pragmatic way of doing things. We also chat about how we viewed the mysterious event loop wrong for way too long, and how understanding it helped us becoming a better Node.js developer (spoiler: it didn't). So enjoy our fun chat and check out Daniel's work: - Daniel's Node.js course on Lynda: https://www.lynda.com/Daniel-Khan/7382040-1.html - What you should know to really understand the Node.js event loop: https://medium.com/the-node-js-collection/what-you-should-know-to-really-understand-the-node-js-event-loop-and-its-metrics-c4907b19da4c - I've been a web developer for 17 years and this is what I learned: https://www.youtube.com/watch?v=6sYi_66qb-w - Script'18: https://scriptconf.org

On this episode, Marcy Sutton and I talk about the importance of storytelling and how it relates to the Web field as well as speaking at conferences.Transcript:Chris: What is up boils and ghouls, and welcome to another episode of Tales from the Script, a podcast focused on front end web development, accessibility, performance, end user experience, with a little bit of horror mixed in. I'm your host, the script keeper, Chris DeMars. Today I have an amazing guest with me, reigning from the mountains of Bellingham, Washington, my good friend Marcy Sutton. What's up Marcy?Marcy: Hello, what's happening?Chris: Oh you know, just trying to get through this fall-ish, summer-ish weather in Michigan, and it's killing my sinuses beyond belief. I'm literally dying over here.Marcy: Oh no. Chris: Yeah, it's not good.Marcy: Your own horror movie.Chris: Yeah, oh, that would be a horror movie that'd sell for sure. For those unfamiliar, Marcy's one of the top influential people in the world of accessibility. For those viewers who may not be familiar with you and your work, where do you work and what do you do?Marcy: I work at a company called Deque Systems on tools for web developers to help them make the web more accessible to people with disabilities. Browser extensions, APIs, and things to basically help point out to you if you mess something up for accessibility, how to fix it. Chris: Awesome, awesome, yeah.Marcy: That's what I do in a nutshell. Chris: Sweet, yeah. I love Deque, I love that they have an office here locally, right outside of Detroit and Ann Arbor. I'm a full supporter of everything you do as well as all your team mates. Any [inaudible 00:01:50] I give on accessibility I always plug Deque or have Deque stickers, so I'm right there rooting along with you. Cool.Marcy: Oh, thanks. Chris: Yeah, no problem. You know I got your back. Today's episode, we're going to switch it up a little bit and we're not going to talk about accessibility. We're going to talk about story telling and how it relates to what we do as a front end developer and as a UI developer, myself, and as well as how that plays along with conference speaking. Storytelling, what is it? The dictionary version, it says that it's the activity of telling or writing stories, so if our storytelling ... Right, exactly. Marcy: No way. Chris: Oh that's not what we do, we don't do that any day. We just there to write code, right? This is something we do pretty much every day, depending on what type of situation we're in or what type of work environment we're in. What does storytelling mean to you in our industry, Marcy?Marcy: Well for me it's about being able to articulate ideas in an entertaining way. My background is in journalism, visual journalism. Using visuals and photography to tell stories. Really the basis of storytelling to me is something that has a beginning, middle, and an end. This can come up in so many different ways in our jobs, either just presenting something to a client, or trying to figure out the discovery phase of a project, to doing a conference talk, to trying to delight your users with something you're building for them to put in front of them. It can come up in so many different ways. When I pivoted away from photojournalism because I wasn't really seeing any good job prospects, it didn't occur to me that those skills would really come in handy later in life. Yeah, that's what it means to me, is just trying to tell stories that are compelling, that they have a starting point and an ending point, and you take it along that story arc. It really comes up in so many different ways. Chris: Yeah, I totally agree with you on that front. I've been doing web design development for a long, long time and relating that to storytelling and having user stories or personas ... I know that personas

Marcy Sutton: @marcysutton | marcysutton.com | Deque Systems Show Notes: 01:07 - Deque Systems 01:54 - Accessibility Tool Integration and Testing 05:26 - Configuration and Success Criteria 07:04 - What is accessibility? WCAG 09:22 - Spurring Adoption of Accessibility 12:09 - The Accessibility Matrix 16:56 - Accessibility-First Development 18:12 - WCAG and ARIA Roles 24:57 - Test Automation vs Human Interaction 28:56 - Empathy Building 30:45 - Porting to the Web 35:57 - Accessibility in Single-page Apps and Focus Management Resources: axe-core aXe aXe Developer Tools WCAG (Web Content Accessibility Guidelines) Web Accessibility for Designers WAI-ARIA Authoring Practices 1.1 First rule of ARIA use Access Works: Usability and Accessibility Training Marcy Sutton: Notes On Client-Rendered Accessibility a11y on Slack Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 61. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Mr Robert De Luca, a developer at The Frontside and today we have with us, Marcy Sutton who is going to be talking with us a little bit about accessibility, both in the large and the small. Welcome, Marcy. MARCY: Good morning, everyone. Happy to be here. CHARLES: I know, I understand you're actually calling us from the parking lot of a ski area. MARCY: I am at the legendary Mount Baker ski area outside of Bellingham, Washington where we have the winter that is just going on and on and on and getting after it on the last few days of my birthday vacation. ROBERT: Oh, wait. Happy birthday. CHARLES: Yeah, happy birthday. ROBERT: Happy belated or happy birthday. MARCY: Yeah, it was Sunday so still on that shiny birthday week. CHARLES: Well, thank you for getting with us on your vacation and on your birthday but doing a little bit of work, you actually work at Deque Labs. What is it that you guys do over there and what's your particular area of interest and work there? MARCY: Deque is an accessibility company. We have people who work on products and services for accessibility. We help people avoid lawsuits and make their websites and mobile apps more accessible to people with disabilities. My slice of that work is on the product team, where I work on browser extensions, APIs for developers. Basically to make it so you don't have to write every single accessibility tool or test yourself. You can pull in these APIs and get some of that experience that Deque has built up for years and years and years, which was part of the reason I went to work there was to learn from them. We make tools that make it easy for you to make use of that knowledge in your applications. ROBERT: That's awesome. It's like a base JavaScript library that can be ported anywhere, like to browser extensions. I know we use it in Ember accessibility testing. That's really cool. That's where I've gone for the way I write JavaScript. It's in a base library so everybody can use it and it's even more awesome that it's testing and like wrapping tooling around accessibility because I know a lot of developer-minded people want to see like a failed built. CHARLES: Yes, what does that experience look like? I mean, coming from someone who's never even heard of these tools, how would I integrate them into my project and what would change about my workflow? What information would it surface? MARCY: The best place and the reason I work on these products is that I saw projects go out the door broken a lot of times, when working in agencies or maybe testing isn't part of your methodology. Personally in my career, I just knew there had to be a better way. I got into software testing and the more I learned about it, the more I thought that it was sustainable, you could pull in other APIs to help you write better tests. I went to work on axe-core, which is the JavaScript library that we've talked about a second ago. That really is bottling up all of these accessibility tests that you can automate some of the accessibility checks for things like if your HTML markup is in a good state and you're using attributes correctly. Basically, saving you from having to write all of those little microtests, some of which can be sort of complicated. It's all about getting test coverage for the automated things that we can actually test for. CHARLES: You described a pretty wide-ranging coverage. How do you go about actually implementing that into your CI process? Do you just install the axe-core? Do you have to load up your browser and then pointed it out? What does that look like? MARCY: Ideally, you would already have a test suite and you could just pull in the test harness. There's all different versions of aXe. There's versions in JavaScript and in Node. The core thing that you need to test is get your app running in a browser, whether it's a headless browser or could be a mounted browser but we need those actual DOM browser APIs to check things like color contrast. We need to be sort of coupled to the DOMs so that we can run our full set of tests, which is a distinction from, say some shallow rendering that you might be doing in React testing or something like that. For accessibility tests, we need an actual DOM so you could get axe-core on npm and then pull it into your project and then you basically either require or import it, depending on what your stack looks like in JavaScript. Then you have access to all of these tests. It's pretty useful since our ecosystem has evolved to cover things like npm. I've found that it works pretty well. ROBERT: That is pretty neat. You require it into your test and then you visit a page that's fully rendered and then you do aXe check, like you call a method that runs all these checks? MARCY: Exactly. You would call axe.run and then you configure it to run, either specific tests or just one test. One of the tricks that has been helpful to know is that if you disable the color contrast rule, you don't need quite as many of the DOM APIs so it will run faster in things like JSDOM, which doesn't implement the entire browser APIs. But you could call axe.run, either in your unit tests or more likely it would be in your integration tests because you'd already have a browser instance, either through Selenium-WebDriver or karma-chrome-launcher or something like that. Then you basically call axe.run, passing a callback function and then it will return to you at set of JSON results and then you can do things with those. ROBERT: When you call run, can you pass options of what you want to check? Can you filter out things that you know might -- because I imagine like if you put this into an existing app that's been going for a while, I imagine you're going to get a bunch of fails and it might be overwhelming. Is there a way to peel a back like an onion and start working at it that way? MARCY: Yes. You can get pretty specific with our API. The GitHub for axe-core has our entire API configuration. You can get pretty specific. You can filter by tags. I imagined we're going to talk a little bit more about what WCAG is but there's a set of standards that you can break accessibility down into things that you can actually assert that they are either accessible or not. There's all different kinds of what we call success criteria. All of our rules are mapped to these actual guidelines and standards because that means that our tests are helping you solve things that are actually helpful so you could filter by the different levels. Maybe you want to configure it with custom rules. We have some additional products for that. You can get pretty specific with what you want it to run. ROBERT: It's extensible too so you can add your own stuff. MARCY: You can and we do a lot of work with some of our clients to actually help them write custom roles so that's a service that we offer. But the API is pretty configurable on the JavaScript side so you can do quite a bit of configuring on your own as well, which is cool. ROBERT: That is pretty awesome. You alluded to WCAG, I guess now we know how you can integrate a testing library into your JavaScript apps, let's take a step back a little bit and what exactly is accessibility and then you can start explaining WCAG because WCAG is a very big document that tells you how to go and be accessible. CHARLES: I assume WCAG is some acronym? MARCY: It is. Peeling that back a little bit to what is accessibility. I'm more on the digital side. There is physical accessibility as well for spaces. But when we're talking about digital accessibility, we're talking about making apps and websites that work for people with a broad range of abilities. Say, you had color blindness or a low vision or you're fully blind, you would need to be able to zoom in, you need high-contrast colors, you might use a screen reader if you're blind. But then there's other categories. People might actually fall into more than one category including motor disabilities, where maybe you can't use a mouse and you have to use a keyboard only or a keyboard with one button, which is how we think about a switch control --that's another device. You might be deaf or hard of hearing and need transcripts or close captions so any audio or video content needs an alternative of some kind. Then there's cognitive disabilities where people have learning disabilities. Maybe the language used on a website is too vague or too marketing copy speak and we need to simplify, people with traumatic brain injury like Stephen Hawking has ALS. I discovered at some point in my career that I could actually make the web a better place by supporting all different kinds of people. That's really what it's about for me is doing good craftsmanship and making sure that you're actually making things as accessible as you can. The WCAG thing that we mentioned, it stands for Web Content Accessibility Guidelines. It's just that. It's a set of guidelines, sort of a map to help you get there. You have to actually interpret those guidelines and put in the work to do it. The guideline is just a guideline but it gives us a really good roadmap of how to implement all of these different areas of accessibility. CHARLES: I actually had a question and this is a little bit harkening back to the discussion about the axe-core but also kind of straddling. How do you spur adoption, both the technology and the value inside of your development team? You know, we definitely make our web apps as accessible as we can because we have Rob on the team. But for teams that don't have Rob, how do you spurred option? How do you pitch it to your team and to your management structure? Like testing. Testing used to be controversial. I think in some pockets, it still is but it was something that you had to pitch or agile methodologies was something that you had to pitch. Now it's kind of accepted. It's a core-value of development, I think. I hope. MARCY: Definitely more so. I agree. CHARLES: Do you see a future where making applications accessible is just a tenet of development in the modern era and how do we get to that point? How do we pitch our teams to adopt that value? MARCY: Part of what I'm trying to do is meet developers where they're at and make tools that make it really easy and free to integrate things so it doesn't cost you anything to npm install a library and pull it in your project or to use a free browser extension. What we're trying to do is really help developers get there by lowering the barriers, just kind of a funny way to put it because that's what we're doing with accessibility is removing barriers for people that get access to things. I'm pretty optimistic about it. We talked a lot in the accessibility world about education is really needed because often, it's just that people don't know about it. I've made it my mission to spread the word as much as possible by doing talks and blog posts and just trying to get as many people on board as possible, instead of making them feel bad about it like, "Oh, you don't know about this? You're terrible." ROBERT: Oh man, you're speaking to me. MARCY: "-- You can do this." I try to bring people along and make them feel welcome because it's not really a fun experience to be like, "Oh you're bad because you didn't do this. You don't think about this thing." That's what I try to do. ROBERT: One of my first experiences in accessibility was like somebody giving me that moral argument like, "You're ruining people's lives. They can't do things on their computer." I just remember the response I had and it wasn't that, "Oh, you're right. I should go make this accessible. It was more of like I had a flight or fight response. I start to justify the reasons I didn't do and that wasn't a good experience so the way you put it, like meet the developers where they're at, I love that because that's how I've been operating too. I think accessibility is just another engineering problem and it can be an engineering problem that would be fun to solve. The accessibility matrix gets really hard and hairy as you get into it like -- CHARLES: Oops! Jargon alert! What is the accessibility matrix? Does the accessibility matrix has Neo? ROBERT: The different AT combos and since my experience stems from screen readers -- MARCY: Assistive technologies? ROBERT: Yeah, assistive technologies -- I'm doing a poor job here -- Basically, you have three levels that you work with here. It's the operating system, the type of assistive technology and if we're talking about the web, it's the browser. You could have like the matrix, the beaten path is MacOS, VoiceOver and Safari. That's going to be your matrix. Then on Windows, it could be Windows JAWS and Internet Explorer or Windows NVDA, which is another screen reader on Windows. JAWS is also a screen reader. The browser for NVDA would be Firefox. Then it can just fork in any of those different combinations that you could possibly imagine that makes it hard to debug for. But that's why I think this is a cool programming problem is because we can build awesome tools to help us do this and test for it like aXe. MARCY: Yeah. I would also argue that it's almost even more of a design problem. It's part of the additional challenges that we have to get our design friends and colleagues on board as well because the more that they are thinking about it before they handed off to us, the less we're going to be caught in these situations where we have to make it work in one browser and assistive technology but then it's broken somewhere else because we're trying to use really experimental APIs or we're just trying to do things differently for the mouse versus the keyboard. I can tell you that could be really difficult. The more we're thinking about making things straightforward and intuitive from the design side, not to say the easier job is going to be but the more successful, I think we can be as a team because it's more than just developments responsibility. There's good resources for designers as well, like a web accessibility for designers. If you just Google that, there's a great checklist from WebAIM. I think it's helpful to make it inclusive to people that we work with, not just in the development side because we really want them to set us up for success or else were really just fixing problems that not at their core. You know what I mean? ROBERT: Yeah, as they come down the pipe, we're kind of dealing with them instead of getting ahead of it. CHARLES: That reminds me actually of an experience that I had, a pair programming with Rob, probably about a year ago as we were making an interaction model for a select box. This was for a custom client. We actually stripped it away and we're like, "Let's just focus on what is the state machine behind this thing," so we drew it out on the board and it turned out that we were really just capturing the interaction apart from any rendering so we had a very strong model. With each state's transition, we were able to basically radiate that information with a screen reader in this case. But it was actually very trivial to do because we've actually forgotten about the DOM, forgotten about the fact that we were actually chasing a visual interaction and like I said, what is the actual user interaction? What is the information coming in and coming out? It turned out once we kind of flush that out and have developed that, hanging the interface on that skeleton was very easy and we could do it in multiple media. It feels like a similar concept where if your designers are very upfront about really exploring the information architecture of an application then being able to represent that information architecture in multiple forms becomes much easier because the joints and beams are very, very clear and they aren't bound to a particular form of representation. MARCY: Yeah, I think it a way that's definitely true. One challenge I would issue for this part of prototyping would be to consider all of the user inputs. Make sure that you're considering a keyboard user hitting an escape key to close that select or maybe they're using a screen reader on a touch device and like the single finger swipe, it's already allocated when that screen reader is running so if you have an interface that was only swipe left or right and there were no other affordances like buttons that you could actually activate, that would be an unusable interface to a mobile screen reader user. What really helps to make that information architecture stand up or hold out when you're developing it, like stay true to your vision through the process is making sure that you're considering all of those user inputs. Sometimes, developers aren't thinking about keyboard user so they're not thinking about focus styles, really trying to activate it another way. I do think that's a helpful exercise. ROBERT: Yeah, and to be fair at Frontend developers, we already have a lot to think about. It's just a lot to juggle so I can understand that's why we have tools like aXe. But what Charles is talking about, I think is actually kind of neat is we were experimenting with accessibility-first development so the people do TDD -- test driven development -- and I was trying to see if we could build something. I wanted to see if what we're writing would yield better software if we did it with an accessibility in mind from the outset. I think that's true. It was a more accessible typeahead. It was better, more well-defined user experience around the typeahead and it was because we thought about accessibility and all of the different edge cases. We really boil it down to the core problem. CHARLES: Right. We were driving it first with keys and nonstandard interaction methods. It meant that we actually got more clear interaction model lying underneath. It was decoupled from the actions that drove it completely because we had to support too from the get go. ROBERT: I thought that was neat. CHARLES: Yeah that was a fun exercise. You know, we should have blog about that because I think that actually results in better software. ROBERT: Yeah, I had a conference talk brewing in there somewhere. Just never got around to it. Talking about the web accessibility guidelines. There's different levels to it. Now, you have an A, AA, and AAA. What do those mean and where does that play into ARIA roles and stuff? MARCY: There's WCAG 2.0 and actually 2.1 is an update that they're working on right now but WCAG 2.0 is -- ROBERT: Oh, yeah. I saw that. MARCY: Yeah, there's some new stuff coming out. It's mainly for low-vision users and mobile touch things. But the WCAG 2.0 is the blessed standard that we're working with right now and the levels are different conformance levels. There's different things that you can achieve with A, AA, or AAA. Most people go for AA. AAA is pretty restrictive in what you can do and if you make it support WCAG 2.0 AA, it doesn't necessarily mean it's going to be intuitive to use. You could make it technically conformant but it won't necessarily be that beautiful or accessible. There's a bit of a dance that we have to do around that to meet these guidelines but do them in an intentional way so that we're actually making something usable. I think that goes back to that idea of craftsmanship and caring about your user to know if this actually going to work for them. There's a number of success criteria in WCAG that are broken up into different categories. There's perceivable, operable, understandable and robust. Within each of those, there's all kinds of different checkpoints that you can look at to inform how do I make this keyboard accessible. There's all kinds of really helpful documentation. That's the WCAG guidelines and within each of those, there are a number of different ways that you can code something. As I'm sure you know, there are infinite ways to code the same thing, pretty much and part of what that cover is techniques for making things accessible. They'll tell you all about Native HTML and what tools you can use within that standard. Then there's this other standard called WAI-ARIA and that's the Web Accessibility Initiative – Accessible Rich Internet Applications. That was originally created back in the day when we didn't have as many browser APIs and we didn't have great ways to expose accessibility information to screen readers. They made this API in browsers that implemented that you can actually bolt on some of the same information that you get from HTML. It's helpful if you're writing as VG or XML, where you just don't have those built in semantics so we have things ARIA role states and properties. You may have seen things like 'role="button"' or 'role="main"' or 'role="search"'. You might see that somewhere and that is just exposing programmatically bolting on a role to any element. You could put on 'div role="button"' and there's a little more that goes into that to make it an accessible button. Anytime we mentioned -- ROBERT: The tab index. MARCY: Yeah, the tab index. You have to make sure you have a keyboard event but that would be a programmatic way to create a button element. You should always start with the native button element because you get all that stuff for free but ARIA gives us an API to actually implement accessibility information. You'll see those techniques come up a lot in WCAG of how you can accomplish the same thing multiple ways. Those are some of the things that we test for in our animated tests in aXe. We check to make sure that you've only use roles that are actual roles because there is a set standard of them. We check to make sure that all of the ARIA values that you might use are actually allowed for that. Sometimes, if you're using 'role="list"' for whatever reason, you can't use a real list. It is possible to create a list with ARIA but if you had the wrong child role or something, that's a pretty easy thing that we can flag with aXe so we're sort of saving you from yourself. It helps me sometimes when I get a role wrong because we're human and we do make mistakes. There's a lot of things to remember so that's pretty key technique that aXe will help you with. That's making sure that your ARIAs used correctly because it is pretty easy -- ROBERT: That's really nice. MARCY: -- to get it wrong, to be honest. ROBERT: Yes. I've definitely done that. Being through the spec document is not the most fun. Trying to read the standards language is a little bit complicated so having a tool like aXe is really helpful for me to pick my way through it like, "aXe will tell me that this is wrong," so it narrows the problem set down for me where I can go and look at the standard and kind of tunnel vision in on that one, rather than get overwhelmed looking at that whole standard documents like there's so much here. MARCY: Yes, there is. One thing that might help with the is the initiative that people are working on called the ARIA Practices Guide, the ARIA Authoring Practices and it sort of breaks down these techniques into what is the keyboard navigation model for that component or it will break it into known patterns. This is really helpful also for designers to know what are some known patterns and how can I implement accessibly. They can really help you jumpstart to using those patterns with this more easily digestible information to tell you how to do it correctly. That has come up in the last few years that I found really useful. ROBERT: That's awesome. I think I've seen this. Is it where they tell you like, "If you're going to reimplement a checkbox, here's how you would do with ARIA?" MARCY: Exactly. I've dropped a link in the chat so we'll expose that in the show notes, I'm sure. There's more resources out there now that are really helpful. There's another one called ARIA in HTML and that one is also from the W3C and it's a note on using ARIA and HTML. That one I found to be very useful as well because they tell you this first, second, third, fourth, and fifth rules of ARIA use. The first rule of ARIA use is if you can use a Native HTML element or attribute, you should absolutely use the built-in one first. That's a big -- ROBERT: Yeah, let's stop reinventing. MARCY: Yeah, you know it's tempting because you can create these custom elements and try to bolt on ARIA but the reality is that if you're trying to make it really backwards compatible, it's just so much easier to support the native things. There is an assisted technology called Dragon NaturallySpeaking, that's a dictation method and they didn't support ARIA until 2014 so you can easily imagine some of your user base with an older assistive technology. That might be completely broken for them so that's why we really push using the native things first just because of the better support on every platform. CHARLES: I have a question about the test automation. We've been talking a lot about aXe in the way that you can do this. Did I get it right? Are my roles correct? And all these things. What's an example of something that you just can't test for in an automated fashion? It just requires human interaction just to perceive it. I mean, this would be right now, kind of in the visual sphere, the state of automation for testing like did I break the layout still requires a human. What are examples of that in terms of accessible interface where you just do the things that you have to be on the lookout for that you can't cover with automation right now? MARCY: I think context and content are some of the most difficult like writing good all text. That can be really challenging just because what makes a good alt for an image and that supposed to be a text alternative to say, "This is something useful," and Facebook has solved that by using artificial intelligence to dynamically guess what's in an image. A blind colleague of mine that works there has written about and he said he always felt left out when he would read his news feed and someone would be talking about their first love or some kind of vague status update. With this new feature, it could say, "Oh, this image that they're talking about their love is a pepperoni pizza," or something where -- [Laughter] MARCY: It's really missing the context so they've started to do automatic all text. For us doing accessibility checks, we try to keep our solution as light weight as possible and without false positives. We can check whether you have an all attribute missing like you don't even have the alt attribute at all which means that the file name would be read in the screen reader which is often terrible, depending on what your filenames are so we can check if that's missing but we can't really tell you what would make a better alt attribute, if you already have one. That's one is a bit difficult. There's another one that we're working on right now with color contrast where we can't really tell if you have a background image that's behind some text. If it has multiple pixel color values in it, even if we could read those colors, it gets really hard for us to say whether text meets color contrast when it's over an image for multiple reasons. That one's a bit tricky. I think there are some other examples throughout WCAG that we can only automate. Depending on which rule set you're using, we estimate between 30% to 40% of issues, we can actually catch with automated tests so there is quite a bit that we still need humans for. But however, I think some of these really basic ones that we can check to help you do those easy wins so that you're not getting messed up by using the attribute Aria-role when it's just role. Those kind of things. It's like we're helping you so you can save that time for those more complex task that might require a human. There's definitely no substitute for trying to use the keyboard to make sure that your app is usable from the keyboard. Test it with a screen reader, you can find people in the web accessibility Slack that might be willing to help you test it, if you're extra nice or maybe you can give them a gift card or something. There is an organization called Knowbility and they have this thing called Access Works where if you need to find a user with a disability to deduce a user testing for you because that's a great thing to do. It's very important. They can help you, as a business think up with someone who can test your app. I would definitely check out Access Works. That's really what's the missing piece. As a developer, I'm okay using a screen reader after doing accessibility for a few years but it's not my primary way of navigating so it's really helpful to have real users to test your app and that's a good way to find someone to actually test it. That sort of makes up the rest so you can get that really valuable feedback. ROBERT: I'm a firm believer in testing but also, I really do think a lot of accessibility work is just kind of empathy building and the way you do that is just sit down and actually use this assistive tech that these people will be using. In that way, you can understand as you're building it, how somebody might move their screen or cursor over the top of this and you can start to think about what the screen will read off and stuff like that. I think using a screen reader as a developer is powerful. But I agree, it will never reach the level like my mom that has been using a screen reader for seven years now. I'll never be able to use it as well as she does. It actually putting in the hands of people that do this day-to-day and live this. A far better idea and that goes beyond accessibility too. You want to user test all your apps anyway. MARCY: Yeah, exactly. I think that should be a big thing that we demand just from our organizations like how you were saying it was kind of controversial. I feel like user testing is another flavor of that where we have a bit of emotional tide of these things that we create and we want them to be perfect in the way that we have envisioned but not everyone interacts with things the same and it's really humbling to watch someone use something that you made and have it completely not get it at all. I think that's a really valuable experience. I've watched my mom or my dad or people try to use something that we assume is really intuitive and it's just not. We look at the web all day -- day-in and day-out being professionals and it's really helpful to show it to people who maybe aren't as fluent, aren't digital natives like that. CHARLES: We talked about actual user testing. We talked about the checking where you render your application and you run a set of checks. Do you have any experience with actually -- this is kind of an idea that just occurred to me, although we did a little bit of it when we were doing native applications -- using the accessible interfaces to actually drive your acceptance tests? Is that anything that you have experience with? Because it seems like on the face of it, you've got this assistive technology that surfaces the key levers of your application so is it a good idea to grab those levers from within your test case? Within your acceptance test to manipulate your application and thereby kind of front load your accessibility because in order to verify it, you must have those levers in place. MARCY: Yeah, from understanding your question correctly, you're wanting to just run your tests using accessibility features? CHARLES: Yes. For example, when we write our acceptance tests in our application, what we do is as part of setting them up, say we want to click here and I want to enter this text into this text box and I want to move this over here and that implies actually dispatching mouse events, keyboard events and then also being able to find the elements in the DOM that I want to dispatch those events on so we're kind of doing it in, I think we use CSS selectors to find them and then we use the jQuery event interface to actually create the events and send them to those elements. But it seems that part of ARIA roles or something else is like identifying the role that this element has in your application and basically saying, "For my test cases, I'm going to use these roles and I'm going to use these things and I'm going to use different access methods, keyboard mouse or whatever to manipulate my interface." Does that makes sense? MARCY: Yeah. ROBERT: I think this makes sense in the native world where in order to get the label, I think you have to use the accessibility label. CHARLES: They do that when you're functionally testing iOS apps so why not -- ROBERT: Does it port to the web, basically. CHARLES: Yeah, does that port to the web? MARCY: It does -- CHARLES: It's really long, way of saying that, I guess. Sorry you all. [Laughter] MARCY: No, and I wanted to clarify because I was wondering if you're talking about driving it with actual assistive technology, which we can't quite yet. We don't have any tools for that. But yes, you should -- ROBERT: We should explore that in Ember. MARCY: Yeah, we just don't have the hooks for that. Maybe Python and NVDAs, since it's open source, maybe AppleScripts. CHARLES: What would that look like to drive it with assistive technologies? ROBERT: We talked to some people at Apple with Ember accessibility team and if I remember correctly, we could only drive VoiceOver on MacOS with AppleScripts but there was no way to do it in any other way so you only could do it with VoiceOver on MacOS and that was still kind of murky. MARCY: Yeah, exactly. The idea would be, rather than just testing the browser, we would actually be able to run a simulator programmatically, to know is the screen reader actually exposing this information. Because a lot of it is there are things that get lost in translation, sometimes where we're following best practices and standards because we have this agreement that people who implement browsers and screen readers are going to follow those standards. It's definitely is not always smooth sailing with that. But there's sort of this disconnect between the browser testing and then actually firing it up in the screen reader and make sure it worked. We take that on faith a lot of time, which is getting back to your original question, why it's so valuable to have tests that use these interaction methods. Absolutely, either in your unit tests or even in your integration test, they can live in either place to have tests that assert and closes with the escape key or it operates with the enter key or whatever the user interaction should be, that we have tests that assert that because that way, if you leave your team or heaven forbid, you got hit by a bus or something, you have a test coverage that makes a contract of how this component should work and you have accessibility support, actually built into your test infrastructure. That is super valuable. At least we know that that part of it is there. We know we can drive it from the keyboard, which is how a lot of screen readers work. They operate on top of the keyboard so we can get really far just by having basic keyboard support. Then, if you pull in an API like axe-core, you can have it tell you if you were using ARIA wrong or something. It's sort of a combination of both where those feature tests in your actual project where you're writing something that it works with the escape key, those are custom tests for your application. I find that they're really valuable just to have in there, especially if you work on a component library or something reusable so that everybody who is contributing knows how this thing is supposed to work. I think that is really valuable. ROBERT: Absolutely. I want to talk about accessibility in single-page apps. The problem with accessibility in single-page apps is while using a screen reader, you click a link and to the screen reader user, all it says is the link was pressed. They don't actually know that the content has changed. But in Ember, we kind of solve this by focusing the outlet that has changed but in other frameworks, in your experience everywhere else, how do you combat this? What are the best ways of attacking this? CHARLES: Yeah, what are the problems that you encounter in single-page applications? MARCY: I've done quite a bit of research and blogging and conference talks on this. I'm working on the Angular team for a while. The issue with the single-page app is the page isn't being refreshed when you make a raving change or something happens dynamically. The user's focus is never refresh to the top of the page so they don't hear a title change or things like that. There's different techniques that you can employ to make that experience more accessible. The first and foremost tool to have in your toolbox is focus management so that you're programmatically sending the user's focus to this new content. Say, I have a sidebar with links in it and I click one of them, I can send focus to content wherever it loaded on the page. That way, they are both alerted to the new content because depending on where you send it. There's different techniques for this but often, we will send focus to the wrapping element so that everything will be read aloud and you can accomplish that by using tab index of -1 in your HTML. That will make this wrapper catch the focus, essentially but it won't add it to the tab order of the entire page. That's a technique that we used to shuffle focus around. I've also seen people use what's called an ARIA Live Region where you have this element somewhere on your page that's not visible. It has to be rendered so you can't use 'display: none' but you can basically pipe messages to these live regions to announce what's happening on the screen. I've just saw a React example where they put an ARIA Live attribute just on that wrapping element, instead of the focus management so anytime new content went into that element, it would just be announced. The challenge with that is that you can't always control everything on the page. That works if you control everything and you know that only this one element is getting updated at the time. But often, we work in this big ecosystem where there's a bunch of things happening. Depending on how complex your app is, you might need some sort of a focus manager, some sort of a utility that will keep track of what's focused and routed around at a correct place. That's the biggest tool for creating accessible single-page apps, that's focused management. I mean, not only for the reading content purpose but also to have their focus in the more accurate place so if they hit tab or they try to start interacting with something that they're in the right part of the page. A good example, if you think about like a modal window -- a modal window may open as a new layer over something -- that requires focus management on open so that your focus is sent into it, either to the first focusable element or to the wrapper. Then when you hit escape or close the modal, it just send your focus back. ROBERT: To the previously focused element, right? MARCY: Exactly, so that if you are using a keyboard and you can't actually use a trackpad or a mouse to get back then you're in the right place or if you're screen reader user and you can't even see the screen, then you're always in the right spot. That's actually, I think really cool. Something that's become more common place with dynamic JavaScript apps is that we can do these really cool focus management techniques. I think they're really cool, they can be challenging but that is something that we definitely need to think about as developers of single-page apps. ROBERT: Absolutely, especially since none of the single-page app frameworks out there were libraries. Actually maybe with the exception of your work on Angular, they don't come with a router focused-library built in so this is something that you have to actually think about and then pull in and do yourself. Does Angular have it, by default? MARCY: No, we never added a focus manager utility. There were some things to try and clean up that HTML, which ended up being, honestly worse than the original problem. But I've written a blog post about focus management techniques. I just dropped that in the chat. There's a smashing magazine article I wrote and it really is framework-agnostic so it sort of covers all of the things that you need to think about if you're writing a client-rendered application using Ember, React or Angular. It is something that we have to think about as developers because from the framework level, it's impossible to know what the right situation would be in your app in a given moment so we can only get so far with magic at the framework level. It's something I would like to see more of. Maybe if there is some sort of a layer manager, I think that is a tool that someone could write that would be super useful -- to make sort of an intelligent layer managing system for focus management. I've heard the Facebook team talked about how they do it internally but it's not open source so I have yet to see an open source solution for this. We have to tackle it in our own apps but once you know that that's the thing, you can really make sure that you're covering it. If you have someone with a visual disability or impairment that try and use your app, they'll probably uncover that problem pretty quickly. That's the value of user testing in case you forget. Maybe there's a few views -- ROBERT: Need to sell it. MARCY: Yeah, or maybe with your application, if you don't have visible focus styles turned on, you might not see that the focus isn't being sent. That is one trick, I will tell you in development. If you're working with focus management, turn the focus outlines on and then if you were trying to send focus before it got fully rendered or something because it has to actually be rendered to catch the focus. That is good debug flag, if you can all agree on the focus styles, for all users. I found that to be really useful in our app. You just to have those turned on so you can debug it. ROBERT: And make it really loud like this is a giant red outline. MARCY: Yeah, then you'll know, if you forgot to add tab index of -1, to make it catch the focus or like I said, maybe there's a rendering thing where you need to wait a tick by using a set time out or something. That is a good technique that I've used recently. ROBERT: Awesome. Basically, what it boils down to in single-page apps is manage your focus and enhance your focus, some might say. MARCY: Yeah, let's think about keyboard ergonomics, like if you are doing things dynamically on the screen and then you want to start typing, I think the most common example I see is autofocus. The developers, even if they aren't thinking about accessibility, they'll ask for autofocus. That in a way is focus management. The difference with autofocus is that you can only use it once and it will send your focus there automatically. But in a similar way, that's the idea of what we want is to get the user's focus point into the right spot so that they can do the right activity on the screen and they know what content they're looking at. ROBERT: Right. Sometimes, it's like navigating around a website with your keyboard, that's like power users who have Vim or Emacs or anybody that's a power user of computer that doesn't like to leave the home row, you can make your application awesome for you to use and also lay the groundwork for accessibility, if you can navigate your website with just a keyboard. MARCY: Exactly. ROBERT: Let's try to pitch it to people in that way. It's still a developer problem. CHARLES: I like that because it really highlights the fact that there is this kind of deep interaction model. The user actually is focused on one thing at a time in the application and if you track that, then it's going to be a benefit for all of your users. If you are deliberate about thinking like this is the subject of interest at this moment. You're just going to reap a lot of benefit for everybody. ROBERT: Keep coming back to it, building accessible applications yields a better application for everybody. MARCY: Absolutely. It might enable you to support some futuristic device that you haven't even thought of yet. If you have your actions decoupled from the actual input and you can do everything declaratively, that really makes it easier to try and support of use cases you haven't thought of like we need to borrow up that other keyboard combination or some touch device. It just really helps to not have everything buried in a jQuery event. ROBERT: Yes. [Laughter] MARCY: Like, "Oh, man I need to call that same functionality for multiple events. Crap." You need to decouple that real quick. ROBERT: "Let's obstruct this." CHARLES: Right. I think we're about the time. I know you've got a hard stop. You got some skiing to do. MARCY: I do. CHARLES: So we will let you get up on the mountain but thank you so much for coming by. This is been a great conversation. ROBERT: Yes, thank you for dropping all the knowledge. CHARLES: Yeah, I'm feeling lots of knowledge right on top of my head -- MARCY: Awesome. CHARLES: -- That I got to go and process. But for everybody else out there, I would say go experiment with aXe. The idea is going to be easy for developers. I know I'm going to experiment with it and then you said, there was a browser extension as well to help you out and probably call out every website that you ever use, right? MARCY: I'm dropping some links for you, just now. CHARLES: There's some links to go along with the knowledge so go check them out and you are @MarcySutton on Twitter? MARCY: That is correct. CHARLES: All right. Fantastic. Thank you so much for coming by. MARCY: Yeah, no problem. Thanks so much for having me.

On today's episode we sit down with Marcy Sutton—a senior front end engineer at Deque Systems, where she works on accessibility. We talk about the intersection and differentiations in performance and accessibility. Marcy explains that there's a huge audience that's being missed by not making your website accessible. Unfortunately, if it's not something you have a personal connection to, it may not occur to you to think about. We talk about how most companies become interested in accessibility after they suffer a lawsuit, and how Marcy's teaching us ways we can be proactive instead of reactive. We look at tools on how to make our sites more accessible and who to make them accessible for. We also talk about the metrics to use to measure success and usability. Show Links: Marcy Sutton Deque Systems Web Components and the Three Unsexy Pillars WCAG What forces layout/reflow Knowbility #A11Y Accessibility Wins AXE Air Carrier Access Act Section 508 Section 504 Lainey Fieingold Structured Negotiations CSUN MarcySutton.com Accessibility and Performance Start Building Accessible Web Applications Today

In this podcast, we interviewed digital accessibility pro Jennison Asuncion. He provided amazing tips on making your digital projects accessible. Listen to the podcast and tweet @grommetux if you have any questions. Podcast Timeline: 0:00 - 3:45 Grommet updates from Chris Carlozzi 4:00: Interview with Jennison starts with Grommet contributor Alan Souza 4:30: Who are you and what do you do 4:53: Tell us more about CSUN conference 5:30: What are the main issues with navigating the web as a blind user? 8:00: Twitter just released a new feature for accessibility access - alternative access. 9:00: Tell us about your background in digital accessibility. 10:16: What advice do you have for those getting into digital accessibility? 12:00: How have you educated others on accessibility 12:28: Global Accessibility Awareness Day - May 19 16:30: What tools do you recommend to test websites are accessible? 21:03: Why is it important for enterprise apps to be accessible? 24:00: Blogs talking about accessibility to follow 24:50: Where do you see accessibility in 5 to 10 years? Twitter Handles Mentioned During the Podcast: Jennison Asuncion @jennison Jesse Beach @jessebeach Alice Boxhall @sundress Accessibility Jobs Twitter Account @a11yjobs Joe Devon @joedevon Marco Zehe @marcoinenglish Leonie Watson @leoniewatson Sam Ogami @sogami Links Mentioned in the Podcast: Bay Area Accessibility and Inclusive Design Meetup http://www.meetup.com/a11ybay Global Accessibility Awareness Day http://www.globalaccessibilityawarenessday.org Accessibility Camp Bay Area http://www.accessibilitycampbay.org WebAIM http://www.webaim.org Apps For All: Coding Accessible Web Applications by Heydon Pickering @heydonworks https://shop.smashingmagazine.com/products/apps-for-all Practical ARIA Examples http://heydonworks.com/practical_aria_examples/ Accessibility Wins by Marcy Sutton @marcysutton https://a11ywins.tumblr.com/ The Before and After Demo from the W3C's Web Accessibility Initiative https://www.w3.org/WAI/demos/bad/ Web Axe blog and podcast http://www.webaxe.org/ Marco's Accessibility Blog – Helping to make accessibility accessible on the web and elsewhere https://www.marcozehe.de/ Tink - Léonie Watson – On technology, food & life in the digital age http://tink.uk/ The Paciello Group Blog https://www.paciellogroup.com/blog/ SSB BART Group blog http://www.ssbbartgroup.com/blog/ 31st International Technology and Persons with Disabilities Conference (CSUN Conference) www.csunconference.org The Great Big List (presentations, video and other material) from the 2016 CSUN International Technology & Persons with Disabilities Conference http://curbcut.net/events/csun16-disabilities-technology/ List of Accessibility and Inclusive Design Meetups https://www.lireo.com/accessibility-inclusive-design-in-person-groups/ NVDA NonVisual Desktop Access (free Windows screen reader) www.nvda-project.org Thanks to @sogami for the podcast intro and Bensound.com for the music.

By studying the limitations of browsers with assistive technologies and establishing developer best practices, we can we make faster, more accessible experiences for our users. We'll frame Web Performance with an Accessibility lens, looking at progressive enhancement in detail with server- and client-rendered apps built with Angular 2, React or Ember FastBoot; always remembering our friend, static HTML. More info at: https://fronteers.nl/congres/2016-spring/sessions/accessibility-and-performance-by-marcy-sutton

By studying the limitations of browsers with assistive technologies and establishing developer best practices, we can we make faster, more accessible experiences for our users. We'll frame Web Performance with an Accessibility lens, looking at progressive enhancement in detail with server- and client-rendered apps built with Angular 2, React or Ember FastBoot; always remembering our friend, static HTML. More info at: https://fronteers.nl/congres/2016-spring/sessions/accessibility-and-performance-by-marcy-sutton

Interactive panel discussion with Marcy Sutton, Karl Groves and Estelle Weyl on accessible performance. More info at: https://fronteers.nl/congres/2016-spring/sessions/interactive-panel-discussion-accessible-performance

Interactive panel discussion with Marcy Sutton, Karl Groves and Estelle Weyl on accessible performance. More info at: https://fronteers.nl/congres/2016-spring/sessions/interactive-panel-discussion-accessible-performance

Angular Accessibility - Accessibility on the web is something that helps all users (whether they have disabilities or not). Marcy Sutton is passionate about accessibility and will join us to give some tips and tricks to making accessible web applications with Angular. Guests: Marcy Sutton Panelists: Aimee Knight and Jeff Whelpley Picks/Tips: Marcy - Accessibility Wins, Progress Towards an Engineering Discipline of Software by Mary Shaw (super awesome speaker at Gotocon Amsterdam), Notes on Client-Rendered Accessibility, Frozen banana ice cream (because summer), Development tips: Protractor accessibility plugin, My JSConf talk on automated accessibility testing, Chrome accessibility developer tools Kent - cloc and Live a balanced life Aimee - Color Blindness App Test, Learn Functional Programming Jeff - Universal JavaScript Angular Air is a video podcast all about Angular hosted by egghead.io instructor Kent C. Dodds. Please visit the Angular Air website (http://angular-air.com) to see upcoming and past episodes. Also be sure to follow Angular Air on Twitter and Google+ to stay up to date with future episodes. Also, all episodes are on the YouTube channel as well. --- Support this podcast: https://anchor.fm/angularair/support

02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

Accessibility for web applications typically gets added at the end of development cycles with different tools and low priority. This ruins the experience for many users and generally causes a huge impact on the quality of code. Because many companies are not held to supporting the standards of Section 508, Web AIM best practices, and WCAG by their clients and the impact in ROI is hard to measure it usually doesn't happen.   Karl Groves (@karlgroves), Accessibility Consultant at The Paciello Group , creator of Tenon.io, & viking web developer leads by example, being an unstoppable developer community advocate for integration of accessibility over supplementation. Tenon takes a very interesting approach in that it integrates with tools we already use. Karl goes through developer resources. Tenon, and how we can make Web Accessibility a ‘first class' citizen in our applications by making it part of our workflow and a fully integrated part of our process. Resources Tenon - http://tenon.io/ Tenon Chrome Plugin - https://chrome.google.com/webstore/detail/tenon-check/bmibjbhkgepmnehjfhjaalkikngikhgj?hl=en-US grunt-tenon - https://github.com/babaskate/grunt-tenon gulp-tenon-client - https://github.com/egauci/gulp-tenon-client Tenon Node - https://github.com/poorgeek/tenon-node tenon for Silverstripe - https://github.com/joshkosmala/silverstripe-tenon React & Tenon demo - https://bitbucket.org/tenon-io/tenon-demo-javascript-reactjs Modern Web Toolsets & The Next Generation of Accessibility Testing Tools (warning - content explicit)- https://www.youtube.com/watch?v=_uq6Db47-Ks&t=247 Karl's Viking Site - http://www.karlgroves.com/ Karl's Sandbox -  http://www.karlgroves-sandbox.com/ Marcy Sutton's Protractor Plugin - http://marcysutton.com/angular-protractor-accessibility-plugin/ Chrome Vox - https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmljglcjbhoiplfn?hl=en-US Steve Faulkner's Web Accessibility Toolbar - https://github.com/ThePacielloGroup/WebAccessibilityToolbar/releases/tag/2015-02-04 Tenon Visual Studio plugin - https://visualstudiogallery.msdn.microsoft.com/0ad320bc-80e4-402a-bf2b-d6c23a3a6730 MDN Docs - https://developer.mozilla.org Accessible Wordpress Templates - https://wordpress.org/themes/tags/accessibility-ready/ Microsoft Accessibility Resources for Developers - http://social.technet.microsoft.com/wiki/contents/articles/28725.accessibility-resources-for-developers.aspx?Sort=MostRecent&PageIndex=1 Panelists Erik Isaksen - UX Engineer at3Pillar Global Danny Blue - Senior Front End Developer at Deloitte Digital Adi Chikara - Advanced Technology Group Lead at 3Pillar Global

The crew talks to Marcy Sutton about the importance of accessibility.

The crew talks to Marcy Sutton about the importance of accessibility.

The crew talks to Marcy Sutton about the importance of accessibility.

In Episode 9, ‘Web Accessibility for JavaScript Components and Custom Elements'. Steve Faulkner (@stevefaulkner) from The Paciello Group and Marcy Sutton (@marcysutton) from Substantial discuss the lack of focus in product development today in building accessible applications & services. Many times web accessibility becomes an afterthought in creating a software product, having little prioritization from the business side until it is a problem. Retrofitting such an important part of our development can make web accessibility seem more like a chore with low ROI for the the time taken to implement it. It can be easy if developers know how to do it and hardly any work when it is successfully incorporated into a development process and it's valued at the business level.   With recent advances in the past few years in JavaScript MV* frameworks like Angular, React, & Ember we are seeing the need for web accessibility more and more. Heavy JavaScript applications tend to provide little or wrong functionality for things we take for granted like keyboard access. Examples on modifying these to better attend to user experience traditionally meant lots of overhead in development by forking the framework and updating it constantly. Based on the resources developers typically find in online searches & Roles the lack of good developer examples, WAI ARIA & even simple accessibility is easy to misunderstand.   Many newer client side frameworks focus on componentization of HTML elements. Angular Directives, Ember Components, React Classes and Web Components. Componentization gives developers a chance to build much faster and easier Web Accessibility using various tools like WAI ARIA roles at a much more focused & reusable level. What is the future of Web Accessibility with these technologies? Why are we so concerned about Web Accessibility?   References: https://github.com/marcysutton/accessibility-of-mvcs http://www.w3.org/TR/wai-aria/appendices#a_schemata https://www.youtube.com/watch?v=BgvDZZ8Ms8c https://www.youtube.com/watch?v=ZPsb-RR8SC0 http://w3c.github.io/aria-in-html/ https://www.youtube.com/watch?v=_IBiXfxhF-A http://www.polymer-project.org/articles/accessible-web-components.html http://marcysutton.com/target-corporate-website/ http://www.w3.org/TR/2013/WD-components-intro-20130606/#decorator-section http://www.paciellogroup.com/blog/ http://www.paciellogroup.com/resources/wat/ http://www.w3.org/WAI/intro/aria http://webaim.org/ https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA