Podcasts about knowbility

Apple Journals & Day One | Matt MullenwegImportant Takeaways:Apple announced its own Journal app at WWDC, which competes with Automattic's product, Day One.Day One has a few advantages over Apple's Journal app. One of them is the upcoming feature of Shared Journals, which allows fully end-to-end encrypted shared private journals with friends and family.Another advantage of Day One is its cross-platform availability. Unlike Apple's Journal app, which is limited to Apple devices, Day One works on all Apple devices, Android devices, and the web.Link: Original ArticleA Place of One's Own, in Noho – Automattic DesignImportant Takeaways:Automattic has a unique office space in Noho, New York, which is described as a “magic space” with unobstructed views of lower Manhattan.The office design is inspired by the aesthetics of jazz clubs and features collections of mid-century vintage furniture, art and design books, and original art pieces.The office is designed to be a practical and elastic canvas for diverse uses, and it reflects the rich aesthetics of Automattic's multiple creative tools.The office space is not just for work; it also serves as a socializing and connecting space for Automattic employees.Link: Original ArticleLinking to Supporting Orgs – Make WordPress.orgImportant Takeaways:The post discusses the need for a dedicated page on WordPress.org to link to independent organizations that support WordPress's mission of democratizing publishing.These organizations are not officially part of WordPress but offer valuable resources and opportunities to get involved.The proposed structure for such a page includes an introduction, organization categories, organization listings, updates and announcements, and contact information.The organizations should align with the mission of WordPress, adhere to a code of conduct, and actively contribute to the WordPress community or the broader mission of democratizing publishing.A vetting process is suggested for adding organizations to this page, including initial screening, detailed review, contacting the organization, decision to list, and periodic review.Link: Original ArticleWordPress Accessibility Day Gains Nonprofit Status Through Partnership with Knowbility – WordPress Accessibility DayImportant Takeaways:WordPress Accessibility Day, a virtual 24-hour conference focused on accessibility best practices for WordPress websites, has gained 501(c)(3) nonprofit status through a partnership with Knowbility.The event was initially started in 2020 by the WordPress core Accessibility Team and was revived in 2022 by Amber Hinds and Joe Dolson as an independent event.The 2022 event was a success, with 11 organizers, 1604 attendees, and 20 volunteers from 52 countries. After all event expenses were paid, WordPress Accessibility Day donated $2,000 to Knowbility.The partnership with Knowbility allows WordPress Accessibility Day to gain nonprofit status, making donations tax-deductible in the United States. It also provides access to Knowbility's accessible online event planning resources.The 2023 event will be held from 10:00 AM CDT (3:00 PM UTC) on Wednesday, September 27th, until 10:00 AM CDT (3:00 PM UTC) on Thursday, September 28th. The event will be live captioned and have sign language interpreters.Link: Original ArticleOne Equity Partners acquires cloud services provider Liquid Web and forms new holding company, CloudOne DigitalImportant Takeaways:One Equity Partners (OEP) has completed the acquisition of Liquid Web, a provider of managed cloud services, forming a new platform known as CloudOne Digital.The senior leadership team of Liquid Web will transition to expanded roles in the new, larger CloudOne platform with Jim Geiger as CEO, Carrie Wheeler as COO, and Joe Oesterling as CTO.Liquid Web, founded in 1997, operates 10 global data centers with more than 500,000 sites under management. With its brand acquisitions, CloudOne Digital will serve over 187,000 clients worldwide.CloudOne Digital will offer a broad portfolio of cloud products that meet the needs of web-dependent small and mid-sized businesses, cloud servers for developers and businesses with highly persistent, compute-intensive workloads, and managed private cloud for mid-market businesses that require enterprise-grade infrastructure and solutions.OEP plans an aggressive expansion strategy for CloudOne Digital, aiming to combine and integrate complementary businesses in the multi-cloud infrastructure segment.Link: Original ArticleWordCampers Demand Changes to Q&A Format – WP TavernImportant Takeaways:WordCamp attendees are calling for changes to the Q&A format at live events, citing issues with attendees abusing the format for self-promotion or not asking relevant questions.WordPress Core Committer Felix Arntz suggested that questions taking longer than a minute should be asked informally at a later opportunity.Arntz proposed several ideas to improve the Q&A format, including submitting questions to a central platform for upvoting, discarding lengthy questions, and providing mandatory training for emcees on handling problematic Q&A situations.He also suggested making Q&A optional, depending on the speaker's preference, to create a more inclusive environment for speakers.The feedback received on Arntz's Twitter thread was largely positive, with other attendees offering their own suggestions for improving the Q&A format.Link: Original ArticleNew Filter Controls: Discover “Commercial” and “Community” in the Theme and Plugin Directory – Make WordPress.orgImportant Takeaways:New categorizations were introduced in the Theme and Plugin Directory in late 2022 to enhance the browsing experience. These filters categorize plugins/themes as “Commercial” and “Community.”The “Commercial” filter allows users to discover themes and plugins developed by professional companies and individuals who offer their products for a fee. These premium options often come with dedicated support, advanced features, and customization options.The “Community” filter showcases themes and plugins created by the WordPress community. These products are often developed by passionate individuals who share their work for free or follow an open-source philosophy.The introduction of these filter controls is part of an ongoing effort to improve the browsing experience and refine the visual aspects of the Theme and Plugin Directory as part of the site redesign.Users are encouraged to provide feedback on these updates and try out the new filter controls.Link: Original ArticleThe Power of Community: A WordCamp Europe Sponsorship StoryImportant Takeaways:Barn2 Plugins sponsored WordCamp Europe (WCEU) for the first time in June 2023. The experience was described as a great opportunity for networking, brand exposure, and team bonding.The company spent a total of €13,256 on the event, including sponsorship costs, travel and accommodation, team t-shirts, WordCamp tickets, and other related expenses.The sponsorship booth was a key part of their presence at the event. They created a quiz for attendees, with winners receiving premium swag items. The quiz was a success, with 145 participants.The team also produced a video showcasing some of their most popular plugins, which was displayed at their booth.The author, Katie Keith, highlighted the difficulty in calculating the return on investment (ROI) for sponsoring a WordCamp. However, she emphasized the intangible benefits, such as increased brand awareness, networking opportunities, and team building.Link: Original ArticleSustainability Team • Supporting Organizations • Commercial & Community Themes & Plugins • Pattern Curation – Post StatusImportant Takeaways:The WordPress Sustainability Team has been established with the main objective of embedding sustainable practices into the WordPress community and its processes, focusing on ensuring longevity socially, economically, and environmentally.Several organizations exist to support the work of WordPress, such as The WP Community Collective and HeroPress. A proposal has been made to display such supporting organizations.Filters have been introduced for Themes and Plugins to distinguish between Commercial and Community efforts. The Patterns Directory is considering using filters for displaying all patterns associated with a theme.The post also includes a roundup of other WordPress news, including updates on WordPress 6.3 and 6.4, WP-CLI releases, community events, core updates, design updates, and more.Link: Original Article ★ Support this podcast ★

Lē Silveus McNamara says consuming Tech has a stimulant effect on the nervous system and the overconsumption of a stimulant, like technology [is] bad for your health. Thanks to Fable for sponsoring the transcript for this episode. Transcript Nic Hi, I'm Nic Steenhout, and you're listening to the accessibility rules soundbite, a series of short podcasts where disabled people explain their impairments, and what barriers they encounter on the web. Just to remind you that transcripts are available for all episodes at the time of publication from the website at https://a11yrules.com. I am really grateful to Fable for sponsoring this episode. Fable is a leading accessibility platform powered by disabled people. Fable moves organizations from worrying about compliance to building incredible and accessible user experiences. They do that through product testing and custom courses. You can learn more about how Fable can work with your team at https://makeitfable.com/nic. Today I'm talking with Lē McNamara. Hey, Lē, how are you? Lē Hi, I'm doing well thank you, Nic. Nic It's been a while since we've been in touch on and off on the web. And we worked a little bit together a while back on the Knowbility internet accessibility rally. And that was fun. And finally we get to connect. So let me ask you this, what's your disability or your impairment? Lē So well, I am a multiple neurodivergent. So I and I also live with a chronic illness. So the nuts and bolts are C PTSD, chronic pain condition and autoimmunity with self diagnosed autism, which is kind of a recent discovery that I have made of myself as part of being a part of the accessibility world. And man has that discovery, blown some things up wide open for me. So it's been that's been an exciting adventure the last few years. Nic It can be very exciting to realize you, you have something that has never been diagnosed, but suddenly when you realize it's like all the pieces of puzzle come together. Lē Exactly. Yep. Yeah. Nic So we're talking about barriers on the web, what would you say your your greatest barrier or your biggest pet peeve related to your disabilities and using the web? What what would that be? Lē So I would say the number one is going to be the overuse of high saturation, or what I call emergency colors. So when you are neurodivergent, although many of us see especially high saturation colors differently. So if you imagine, in your mind, a bright red, we might see that as more of a neon. And that same mechanism of you know, when you see when you're online and you see an emergency pop up, for example, and it's in that bright, high saturation red, that same mechanism that makes it so that that red gets your attention is overly stimulating for me. Right. And so when that color, whether it's high saturations reds, yellows, or oranges, when those colors are used, outside of the context of their intention, which is to say, an emergency, we need your attention right now. That hook, right, that hook into the mind can be very problematic. And in fact, when I see a website that uses especially high saturation, red as a branding color, and so you'll see it in blocks all over the side, or see buttons all over the site. It actually causes both high anxiety and nerve pain so that overstimulation can be so severe that it puts the nervous system into overload. And the experience of that internally is anxiety, frustration, sometimes a sense of panic, but also active pain that can last sometimes for a few minutes, but sometimes for several days. Nic Would you say then that companies that have red as a brand color need to change that or what would be a solution there? Lē Yes. So really, what we're looking at is the saturation level. So you can use red, but you want to bring the saturation level down. Right. And actually, if you want to see examples of what I mean by this, I did write a blog post that is currently posted on the TPGi website. It's called Going beyond WCAG losing spoons online. And in that article, I extrapolate some of the various issues that I have found on the internet and one of these, this is one of the issues and I do give visual examples that you can consent into or not for my, my neurodivergent peers, and also hex codes so that you can really see what I mean by high saturation, but your designers will know what you mean. And so you just want to bring the saturation down. So if you're using a warmer read that that's better Right. And then I would just say if you do you know, if you're a company that sort of stuck with a high saturation color that you've invested a lot of time in marketing in, and it's in your logo. Well, if it's just in your logo that might be okay. But take it out of the website in large blocks, right? Take it out as a big block background color, or as button colors, text colors, etc. Nic Thank you. If you had one message for designers or developers, what would it be? Is it along the lines of beware your colors? Or do you have something else for for them to think about? Lē I think it's I think it's broader than that. I think one of the things that, as a culture we are still overlooking when it comes to these new technologies, and how much time we're all spending with them is that at the end of the day, consuming Tech has a stimulant effect on the nervous system. And this is true for everyone, regardless of whether or not they're neuro divergent, but not unlike the consumption of overconsumption of a stimulant, like caffeine, for example, is bad for your health, the overconsumption of a stimulant, like technology, like the screen based technologies that we use, is also bad for your health. And that's just even more so true for those of us with what we call sensory sensitivities who are neurodivergent. Right? So I would encourage designers to educate themselves on the basic neuroscience of that and be thinking about it as they're designing to minimize their does minimize the stimulant nature of their designs, you know, as that as that light comes in through the eyes and affects the brain and affects the nervous system, right. So and that can be that can be a lot of things that can be minimizing motion, minimizing the amount of content on the screen at any one time, so minimizing clutter, you know, not not putting too much information all in one space. Limiting limiting color, color variance, decreasing the saturation of colors across the color spectrum, right. So there are a lot of things that we can think about and imagine to do to say, to say we understand this as a stimulant, naturally. So what can we do to minimize that effect, and that is going to not only help my population, but it's also going to decrease the negative long term effects of technology use on the population at large. Nic Lē, thank you so much for sharing your your experiences and giving some advice to our listeners. So thank you. Yeah, thank you

Rich Schwerdtfeger, Retired, IBM, Former Chief Technology Officer for Accessibility Rich began his work in accessibility with the early development of a screen reader for Windows. He was a key member of the world-wide team that brought technologies like ARIA into mainstream use for accessibility. Rich chaired the board of Knowbility and currently is President and Creator at A Diver's Life YouTube Channel.

Today we interview Sharron Rush, Executive Director of Knowbility,  about creating an accessible and inclusive digital world. We'll talk about the importance of digital accessibility in the modern age, the ways a website can become more inclusive, and the Knowbility programs promoting accessibility through contests, conferences, consulting, and more.To support Knowbility and discover more ways to help, visit: https://www.knowbility.org/To learn more about the show, view transcripts, and more visit:https://www.actsofimpact.comSpecial thanks to Sharron and the Knowbility team. Music by Alex Grohls.

What is it like to work at a top company for 18 years and then suddenly have that taken away from you?Today's episode talks about the grim reality of layoffs, and the joy of restarting your career when faced with umpteen unknowns.Lori Knudsen has worked in pharma sales for over 20 years as a cardiovascular specialty representative. And now, as the Founder of Knowbility Consulting, she helps students find their ideal career. So it's safe to say, Lori knows quite a bit about how the heart works!In this honest and revealing episode, Lori shares how she landed her first job in Sales, and how life was like going through a big career transition.We also talk a lot of strengths based coaching and how our strengths can reveal whether we are in the right or wrong career, especially if faced with a crossroads. I hope you enjoy this episode as much as I did, with so many key takeaways.Follow Lori on LinkedIn and her website:https://www.linkedin.com/in/lori-knudsen/https://www.knowbilityconsulting.com/Get a copy of Youmap the book here.--------------------------------------------------------------Liked this episode? A few things:1. Share the podcast with three of your closest friends! And please leave a great review on Apple Podcasts here, as it would mean a lot to me and hopefully help others discover this resource for Job Seekers ! 2. You will love my weekly emails called Charge-Up! .. they're no fluff no spam, where I share my favourite career insights from movies, TV shows, news and my own personal experiences, that I don't share anywhere else. Make sure you sign up here!  3. Come hang out with me LIVE on LinkedIn and Youtube every Friday at 2 pm CET where I answer your questions and often bring in fab guests:LinkedIn: https://www.linkedin.com/in/sonalbahl/ Youtube: https://www.youtube.com/SuperChargeYourself4. Share your favourite takeaways and tag me on your Instagram: https://www.instagram.com/supercharge_yourself/

Jessica McKay, Anthony Vasquez, Erica Braverman –  19th of October 2021, 8 pm GMTBefore becoming Knowbility's Director of Community programs, Jay started her journey in education. First as a music therapist and then as an assistive technology specialist, with the goal of building inclusive learning environments for all. She serves as an advisory member for the National Center for Accessible Educational Materials, the Center on Inclusive Technology & Educational Systems and the State Leaders of Assistive Technology in Education.With experience in community organizing, Jay understands the value of people power, building relationships and holding each other accountable to create more equitable and inclusive spaces. She will graduate from California State University Northridge with a Master of Science in Assistive Technology and Human Services in December 2021Erica is from Michigan and moved to Austin to serve in AmeriCorps. She has a Bachelor's degree in Spanish from the University of Michigan, a Master of Arts in Teaching from Wayne State University and a certificate in UX Design from UC San Diego.Erica started as a volunteer with Knowbility and competed in AIR in 2019 before joining the team. Prior to this she was a teacher working primarily with English learners. One of her first experiences with internet accessibility involved learning about the types of barriers that her students experienced when they interacted with English language mobile apps.

01:09 - Todd's Superpower: Advocacy For Accessibility * Getting Started * Designing With Web Standards by Jeffrey Zeldman (https://www.amazon.com/Designing-Web-Standards-Jeffrey-Zeldman/dp/0321616952) * The A11Y Project (https://www.a11yproject.com/) * W3C (https://www.w3.org/) 06:18 - Joining The W3C * The W3C Community Page (https://www.w3.org/community/) 07:44 - Getting People/Companies/Stakeholders to Care/Prioritize About Accessibility * Making A Strong Case For Accessibility by Todd Libby (https://www.smashingmagazine.com/2021/07/strong-case-for-accessibility/) * Diplomatic Advocacy * You Don't Want To Get Sued! / $$$ * “We are all temporarily abled.” 15:20 - The Domino's Pizza Story * Supreme Court hands victory to blind man who sued Domino's over site accessibility (https://www.cnbc.com/2019/10/07/dominos-supreme-court.html) 18:21 - Things That Typically Aren't Accessible And Should Be * The WebAIM Million Report (https://webaim.org/projects/million/) * WCAG (https://www.w3.org/WAI/standards-guidelines/wcag/) * Color Contrast * Missing Alt Text on Images * Form Input Labels * What's New in WCAG 2.1: Label in Name by Todd Libby (https://css-tricks.com/whats-new-in-wcag-2-1-label-in-name/) * Empty Links * Not Using Document Language * Triggering GIFS / Flashing Content * Empty Buttons – Use a Button Element!! * Tab Order * Semantic HTML, Heading Structure 26:27 - Accessibility for Mobile Devices * Target Size * Looking at WCAG 2.5.5 for Better Target Sizes (https://css-tricks.com/looking-at-wcag-2-5-5-for-better-target-sizes/) * Dragging Movements 28:08 - Color Contrast * Contrast Ratio (https://contrast-ratio.com/) 33:02 - Designing w/ Accessibility in Mind From the Very Beginning * Accessibility Advocates on Every Team * Accessibility Training 36:22 - Contrast (Cont'd) 38:11 - Automating Accessibility! * axe-core-gems (https://github.com/dequelabs/axe-core-gems) Reflections: Mae: Eyeballing for contrast. John: We are all only temporarily abled and getting the ball rolling on building accessibility in from the beginning of projects going forward and fixing older codebases. Mandy: Using alt-tags going forward on all social media posts. Todd: Accessibility work will never end. Accessibility is a right not a privilege. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: JOHN: Welcome to Greater Than Code, Episode 251. I'm John Sawers and I'm here with Mae Beale. MAE: Hi, there! And also, Mandy Moore. MANDY: Hi, everyone! I'm Mandy Moore and I'm here today with our guest, Todd Libby. Todd Libby is a professional web developer, designer, and accessibility advocate for 22 years under many different technologies starting with HTML/CSS, Perl, and PHP. Todd has been an avid learner of web technologies for over 40 years starting with many flavors of BASIC all the way to React/Vue. Currently an Accessibility Analyst at Knowbility, Todd is also a member of the W3C. When not coding, you'll usually find Todd tweeting about lobster rolls and accessibility. So before I ask you what your superpower is, I'm going to make a bet and my bet is that I'm 80% positive that your superpower has something to do with lobster rolls. Am I right? [laughter] Am I right? TODD: Well, 80% of the time, you'd be right. I just recently moved to Phoenix, Arizona. So I was actually going to say advocacy for accessibility, but yes, lobster rolls and the consumption of lobster rolls are a big part. MAE: I love it. That's fantastic. MANDY: Okay. Well, tell me about the advocacy. [chuckles] TODD: So it started with seeing family members who are disabled, friends who are disabled, or have family members themselves who are disabled, and the struggles they have with trying to access websites, or web apps on the web and the frustration, the look of like they're about ready to give up. That's when I knew that I would try to not only make my stuff that I made accessible, but to advocate for people in accessibility. MAE: Thank you so much for your work. It is critical. I have personally worked with a number of different populations and started at a camp for children with critical illnesses and currently work at an organization that offers financial services for people with disabilities – well, complex financial needs, which the three target populations that we work with are people with disabilities, people with dementia, and people in recovery. So really excited to talk with you today. Thanks. TODD: You're welcome. JOHN: When you started that journey, did you already have familiarity with accessibility, or was it all just like, “Oh, I get to learn all this stuff so I can start making it better”? TODD: So I fell into it because if you're like me and you started with making table-based layouts way back in the day, because what we had—Mosaic browser, Netscape Navigator, and Internet Explorer—we were making table-based layouts, which were completely inaccessible, but I didn't know that. As the web progressed, I progressed and then I bought a little orange book by Jeffrey Zeldman, Designing with Web Standards, and that pretty much started me on my journey—semantic HTML, progressive enhancement in web standards, and accessibility as well. I tend to stumble into a lot of stuff [laughs] so, and that's a habit of mine. [laughs] MAE: It sounds like it's a good habit and you're using it to help all the other people. So I hate to encourage you to keep stumbling, but by all means. [laughter] Love it. If you were to advise someone wanting to know more about accessibility, would you suggest they start with that same book too, or what would you suggest to someone stumbling around in the dark and not hitting anything yet? TODD: The book is a little outdated. I think the last edition of his book was, I want to say 2018, maybe even further back than that. I would suggest people go on websites like The A11Y project, the a11yproject.com. They have a comprehensive list of resources, links to learning there. Twitter is a good place to learn, to follow people in the accessibility space. The other thing that, if people really want to dive in, is to join The W3C. That's a great place and there's a lot of different groups. You have the CSS Working Group, you have the accessibility side of things, which I'm a part of, the Silver Community Group, which is we're working on the Web Content Accessibility Guidelines 3.0, which is still a little ways down the road, but a lot of great people and a lot of different companies. Some of those companies we've heard of—Google, Apple, companies like that all the way down to individuals. Individuals can join as individuals if your company isn't a member of the W3C. So those are the three things that I mainly point to people. If you don't really want to dive into the W3C side of things, there's a lot of resources on the a11yproject.com website that you can look up. MANDY: So what does being a member entail? What do you have to do? Do you have to pay dues? Do you have to do certain projects, maybe start as an individual level, because I'm sure we have mostly individuals listening to the show. Me as a newbie coder, what would I do to get started as a member of this initiative? TODD: Well, I started out as an individual myself, so I joined and I can get you the link to The W3C Community Page. Go to sign up as an individual and someone will approve the form process that you go through—it's nothing too big, it's nothing complicated—and then that will start you on your way. You can join a sub group, you can join a group, a working group, and it doesn't cost an individual. Companies do pay dues to the W3C and if your company is in the W3C, you get ahold of your company's liaison and there's a process they go through to add you to a certain group. Because with me, it was adding me to The Silver Community Group. But as an individual, you can join in, you can hop right into a meeting from there, and then that's basically it. That's how you start. JOHN: What are the challenges you see in getting not only the goals of a W3C, but I'm assuming specifically around accessibility? TODD: Some of the things that I've seen is buy-in from stakeholders is probably the number one hurdle, or barrier. Companies, stakeholders, and board members, they don't think of, or in some cases, they don't care about accessibility until a company is getting sued and that's a shame. That's one of the things that I wrote about; I have an article on Smashing Magazine. Making A Strong Case for Accessibility, it's called and that is one of few things that I've come across. Getting buy-in from stakeholders and getting buy-in from colleagues as well because you have people that they don't think about accessibility, they think about a number of different things. Mostly what I've come across is they don't think about accessibility because there's no budget, or they don't have the time, or the company doesn't have the time. It's not approved by the company. The other thing that is right up there is it's a process—accessibility—making things accessible and most people think that it's a big this huge mountain to climb. If you incorporate accessibility from the beginning of your project, it's so much easier. You don't have to go back and you don't have to climb that mountain because you've waited until the very end. “Oh, we have time now so we'll do the accessibility stuff,” that makes it more hard. MAE: John, your question actually was similar to something I was thinking about with how you developed this superpower and I was going to ask and still will now. [chuckles] How did you afford all the time in the different places where you were overtime to be able to get this focus? And so, how did you make the case along the way and what things did you learn in that persuasion class of life [chuckles] that was able to allow you to have that be where you could focus and spend more time on and have the places where you work prioritize successful? TODD: It was a lot of, I call it diplomatic advocacy. So for instance, the best example I have is I had been hired to make a website, a public facing website, and a SAAS application accessible. The stakeholder I was directly reporting to, we were sitting down in a meeting one day and I said, “Well, I want to make sure that accessibility is the number one priority on these projects,” and he shot back with, “Well, we don't have the disabled users,” and that nearly knocked me back to my chair. [laughs] So that was a surprise. MAE: There's some groaning inside and I had to [chuckles] do it out loud for a moment. Ooh. TODD: Yeah, I did my internal groaning at the meeting so that just was – [chuckles] Yeah, and I remember that day very vividly and I probably will for the rest of my life that I looked at him and I had to stop and think, and I said, “Well, you never know, there's always a chance that you're able, now you could be disabled at any time.” I also pointed out that his eyeglasses that he wore are an assistive technology. So there was some light shed on that and that propelled me even further into advocacy and the accessibility side of things. That meeting really opened my eyes to not everyone is going to get it, not everyone is going to be on board, not everyone is going to think about disabled users; they really aren't. So from there I used that example. I also use what I call the Domino's Pizza card lately because “Oh, you don't want to get sued.' That's my last resort as far as advocacy goes. Other than that, it's showing a videotape of people using their product that are disabled and they can't use it. That's a huge difference maker, when a stakeholder sees that somebody can't use their product. There's numbers out there now that disabled users in this country alone, the United States, make up 25% of the population, I believe. They have a disposable income of $8 trillion. The visually disabled population alone is, I believe it was $1.6 billion, I think. I would have to check that number again, but it's a big number. So the money side of things really gets through to a stakeholder faster than “Well, your eyeglasses are a assistive technology.” So once they hear the financial side of things, their ears perk up real quick and then they maybe get on board. I've never had other than one stakeholder just saying, “No, we're just going to skip that,” and then that company ended up getting sued. So that says a lot, to me anyways. But that's how I really get into it. And then there was a time where I was working for another company. I was doing consulting for them and I was doing frontend mostly. So it was accessibility, but also at the same time, it was more the code side of things. That was in 2018. 2019, I went to a conference in Burlington, Vermont. I saw a friend of mine speaking and he was very passionate about it and that talk, and there was a couple others there as well, it lit that fire under me again, and I jumped right back in and ever since then, it's just then accessibility. MAE: You reminded me one of the arguments, or what did you say? Diplomatic advocacy statements that I have used is that we are all temporarily abled. [chuckles] Like, that's just how it is and seeing things that way we can really shift how you orient to the idea of as other and reduce the othering. But I was also wondering how long it would be before Pizza Hut came up in our combo. [laughter] MANDY: Yeah, I haven't heard of that. Can you tell us what that is? TODD: [chuckles] So it was Domino's and they had a blind user that tried to use their app. He couldn't use their app; their app wasn't accessible. He tried to use the website; the website wasn't accessible. I have a link that I can send over to the whole story because I'm probably getting bits and pieces wrong. But from what I can recall, basically, this user sued Domino's and instead of Domino's spending, I believe it was $36,000 to fix their website and their app, they decided to drag it out for a number of years through court and of course, spent more money than just $36,000. In the end, they lost. I think they tried to appeal to the Supreme Court because they've gone up as high as federal court, but regardless, they lost. They had to – and I don't know if they still have an inaccessible site, or not, or the app for that matter because I don't go to Domino's. But that's basically the story that they had; a user who tried to access the app and the website, couldn't use it, and they got taken to court. Now Domino's claimed, in the court case, that he could have used the telephone, but he had tried to use the telephone twice and was on hold for 45 minutes. So [laughs] that says a lot. JOHN: Looks like it actually did go to the Supreme Court. TODD: Yeah. Correct me if I'm wrong, I think they did not want to hear it. They just said, “No, we're not going to hear the case.” Yeah, and just think about all these apps we use and all the people that can't access those apps, or the websites. I went to some company websites because I was doing some research, big companies, and a lot of them are inaccessible. A little number that I can throw out there: every year, there's been a little over 2,500 lawsuits in the US. This year, if the rate keeps on going that it has, we're on course for over 4,000 lawsuits in the US alone for inaccessible websites. You've had companies like Target, Bank of America, Winn-Dixie, those kinds of companies have been sued by people because of inaccessible sites. MAE: Okay, but may I say this one thing, which is, I just want to extend my apologies to Pizza Hut. [laughter] MANDY: What kinds of things do you see as not being accessible that should be or easily could be that companies just simply aren't doing? TODD: The big one, still and if you go to webaim.org/projects/million, it's The WebAIM Million report. It's an annual accessibility analysis of the top 1 million home pages on the internet. The number one thing again, this year is color contracts. There are guidelines in place. WCAG, which is the Web Content Accessibility Guidelines, that text should be a 4.5:1 ratio that reaches the minimum contrast for texts. It's a lot of texts out there that doesn't even reach that. So it's color contrast. You'll find a lot of, if you look at—I'm looking at the chart right now—missing alt texts on images. If you have an image that is informative, or you have an image that is conveying something to a user, it has to have alternative text describing what's in the picture. You don't have to go into a long story about what's in the picture and describe it thoroughly; you can just give a quick overview as to what the picture is trying to convey, what is in the picture. And then another one being another failure type a is form input labels; labels that are not labeled correctly. I wrote a article about that [chuckles] on CSS-Tricks and that is, there's programmatic and there's accessible names for form labels that not only help the accessibility side of it, as far as making the site accessible, but also it helps screen reader users read forms and navigate through forms, keyboard users also. Then you have empty links and then a big one that I've seen lately is if you look up in the source code, you see the HTML tag, and the language attribute, a lot of sites now, because they use trademarks, they don't have a document language. I ran across a lot of sites that don't use a document language. They're using a framework. I won't name names because I'm not out to shame, but having that attribute helps screen reader users and I think that's a big thing. A lot of accessibility, people don't understand. People use screen readers, or other assistive technologies, for instance, Dragon NaturallySpeaking voice input. But at the same time, I've got to also add accessibility is more than just deaf, or blind. I suffer from migraines, migraine headaches so animation, or motion from say, parallax scrolling can trigger a migraine. Animations that are too fast, that also trigger migraine headache. You have flashing content that can potentially cause seizures and that's actually happened before where an animated GIF was intentionally sent to someone and it caused a seizure and almost killed the person. So there's those and then the last thing on this list that I'm looking at right now, and these are common failures, empty buttons. You have buttons that don't have labels. Buttons that have Click here. Buttons need to be descriptive. So you want to have – on my site to send me something on the contact form, it's Send this info to Todd, Click here, or something similar like that. MAE: Can you think of any, John that you know of, too? I've got a couple of mind. How about you, Mandy? MANDY: For me, because I'm just starting out, I don't know a whole lot about accessibility. That's why I'm here; I'm trying to learn. But I am really conscious and careful of some of the GIFs that I use, because I do know that some of the motion ones, especially really fast-moving ones, can cause problems, migraines, seizures for people. So when posting those, I'm really, really mindful about it. JOHN: Yeah, the Click here one is always bothers me too, because not only is it bad accessibility, it's bad UX. Like HTML loves you to turn anything into a link so you can make all the words inside the button and it's just fine. [laughs] There's so many other ways to do it that are just – even discounting the accessibility impact, which I don't want it. TODD: Yeah, and touching upon that, I'm glad you brought up the button because I was just going to let that go [chuckles] past me. I have to say and I think it was in the email where it said, “What's bothering you?” What bothers me is people that don't use the button. If you are using a div, or an anchor tag, or a span, stop it. [laughs] Just stop it. There's a button element for that. I read somewhere that anchor tag takes you somewhere, a div is a container, but button is for a button. MAE: I love that. The only other ones I could think of is related to something you said, making sure to have tab order set up properly to allow people to navigate. Again, I liked your point about you don't have to be fully blind to benefit from these things and having keyboard accessibility can benefit a lot of people for all kinds of reasons. The other one is, and I would love to hear everybody's thoughts on this one, I have heard that we're supposed to be using h1, h2, h3 and having proper setup of our HTML and most of us fail just in that basic part. That's another way of supporting people to be able to navigate around and figure out what's about to be on this page and how much should I dig into it? So more on non-visual navigation stuff. TODD: Yeah, heading structure is hugely important for keyboard users and screen reader users as well as tab order and that's where semantic HTML comes into play. If you're running semantic HTML, HTML by default, save for a few caveats, is accessible right out of the box. If your site and somebody can navigate through using let's say, the keyboard turns and they can navigate in a way that is structurally logical, for instance and it has a flow to it that makes sense, then they're going to be able to not only navigate that site, but if you're selling something on that site, you're going to have somebody buying something probably. So that's again, where tab order and heading structure comes into play and it's very important. JOHN: I would assume, and correct me if I'm wrong, or if you know this, that the same sort of accessibility enhancements are available in native mobile applications that aren't using each HTML, is that correct? TODD: Having not delved into the mobile side of things with apps myself, that I really can't answer. I can say, though, that the WCAG guidelines, that does pertain to mobile as well as desktop. There's no certain set of rules. 2.2 is where there are some new features that from mobile, for instance, target size and again, I wrote another article on CSS-Tricks about target size as well. So it's if you ever noticed those little ads that you just want to click off and get off your phone and they have those little tiny Xs and you're sitting there tapping all day? Those are the things target size and dragging movements as well. I did an audit for an app and there was a lot of buttons that were not named. A lot of the accessibility issues I ran into were the same as I would run into doing an audit on a website. I don't know anything about Swift, or Flutter, or anything like that, they pretty much fall into the same category with [inaudible] as far as accessible. JOHN: I also wanted to circle back on the first item that you listed as far as the WebAIM million thing was color contrast, which is one of those ones where a designer comes up with something that looks super cool and sleek, but it's dark gray on a light gray background. It looks great when you've got perfect eyesight, but anybody else, they're just like, “Oh my God, what's that?” That's also one of the things that's probably easiest to change site-wide; it's like you go in and you tweak the CSS and you're done in a half hour and you've got the whole site updated. So it's a great bit of low-hanging fruit that you can attach if you want to start on this process. TODD: Yeah. Color contrast is of course, as the report says, this is the number one thing and let me look back here. It's slowly, the numbers are dropping, but 85.3%, that's still a very high number of failures and there's larger text. If you're using anything over 18 pixels, or the equivalent of 18—it's either 18 points, or 18 pixels—is a 3:1 ratio. With that color contrast is how our brains perceive color. It's not the actual contrast of that color and there are people far more qualified than me going to that, or that can go into that. So what I'll say is I've seen a lot of teams and companies, “Yeah, we'll do a little over 4.5:1 and we'll call it a day.” But I always say, if you can do 7:1, or even 10:1 on your ratios and you can find a way to make your brand, or whatever the same, then go for it. A lot of the time you hear, “Well, we don't want to change the colors of our brand.” Well, your colors of your brand aren't accessible to somebody who that has, for instance, Tritanopia, which is, I think it's blues and greens are very hard to see, or they don't see it at all. Color deficiencies are a thing that design teams aren't going to check for. They're just not. Like you said, all these colors look awesome so let's just, we're going to go with that on our UI. That's one thing that I actually ran into on that SAAS product that I spoke about earlier was there was these colors and these colors were a dark blue, very muted dark blue with orange text. You would think the contrast would be oh yeah, they would be all right, but it was horrible. JOHN: You can get browser plugins, that'll show you what the page looks like. So you can check these things yourself. Like you can go in and say, “Oh, you're right. That's completely illegible.” TODD: Yeah. Firefox, like I have right here on my work machine. I have right here Firefox and it does this. There's a simulator for a visual color deficiencies. It also checks for contrast as well. Chrome has one, which it actually has a very cool eyedropper to check for color contrast. If you use the inspector also in Firefox, that brings up a little contrast thing. The WAVE extension has a contrast tool. There's also a lot of different apps. If you have a Mac, like I do, I have too many color contrast because I love checking out these color contrast apps. So I have about five different color contrast apps on my Mac, but there's also websites, too that you can use at the same time. Just do a search for polar contrast. Contrast Ratio, contrast-ratio.com, is from Lea Verou. I use that one a lot. A lot of people use that one. There's so many of them out there choose from, but they are very handy tool at designer's disposal and at developers' disposal as well. JOHN: So I'm trying to think of, like I was saying earlier, the color contrast one is one of those things that's probably very straightforward; you can upgrade your whole site in a short amount of time. Color contrast is a little trickier because it gets into branding and marketing's going to want to care about it and all that kind of stuff. So you might have a bit more battle around that, but it could probably be done and you might be able to fix, at least the worst parts of the page that have problems around that. So I'm just trying to think of the ways that you could get the ball rolling on this kind of a work. Like if you can get those early easy wins, it's going to get more people on board with the process and not saying like, “Oh, it's going to take us eight months and we have to go through every single page and change it every forum.” That sounds really daunting when you think about it and so, trying to imagine what those easy early wins are that can get people down that road. TODD: Yeah. Starting from the very outset of the project is probably the key one: incorporating accessibility from the start of the project. Like I said earlier, it's a lot easier when you do it from the start rather than waiting till the very end, or even after the product has been launched and you go back and go, “Oh, well, now we need to fix it.” You're not only putting stress on your teams, but it's eating up time and money because you're now paying everybody to go back and look at all these accessibility issues there. Having one person as a dedicated accessibility advocate on each team helps immensely. So you have one person on the development team, one person on the dev side, one person on the marketing team, starting from the top. If somebody goes there to a stakeholder and says, “Listen, we need to start incorporating accessibility from the very start, here's why,” Nine times out of ten, I can guarantee you, you're probably going to get that stakeholder onboard. That tenth time, you'll have to go as far as maybe I did and say, “Well, Domino's Pizza, or Bank of America, or Target.” Again, their ears are going to perk up and they're going to go, “Oh, well, I don't really, we don't want to get sued.” So that, and going back to having one person on each team: training. There are so many resources out there for accessibility training. There are companies out there that train, there are companies that you can bring in to the organization that will train, that'll help train. That's so easier than what are we going to do? A lot of people just sitting there in a room and go, “How are you going to do this?” Having that person in each department getting together with everybody else, that's that advocate for each department, meeting up and saying, “Okay, we're going to coordinate. You're going to put out a fantastic product that's going to be accessible and also, at the same time, the financial aspect is going to make the company money. But most of all, it's going to include a lot of people that are normally not included if you're putting out an accessible product.” Because if you go to a certain website, I can guarantee you it's going to be inaccessible—just about 99% of the web isn't accessible—and it's going to be exclusive as it's going to – somebody is going to get shut out of the site, or app. So this falls on the applications as well. Another thing too, I just wanted to throw in here for color contrast. There are different – you have color contrast text, but you also have non-text contrast, you have texts in images, that kind of contrast as well and it does get a little confusing. Let's face it, the guidelines right now, it's a very technically written – it's like a technical manual. A lot of people come up to me and said, “I can't read this. I can't make sense of this. Can you translate this?” So hopefully, and this is part of the work that I'm doing with a lot of other people in the W3C is where making the language of 3.0 in plain language, basically. It's going to be a lot easier to understand these guidelines instead of all that technical jargon. I look at something right now and I'm scratching my head when I'm doing an audit going, “Okay, what do they mean by this?” All these people come together and we agree on what to write. What is the language that's going to go into this? So when they got together 2.0, which was years and years ago, they said, “Okay, this is going to be how we're going to write this and we're going to publish this,” and then we had a lot of people just like me scratching their heads of not understanding it. So hopefully, and I'm pretty sure, 99.9% sure that it's going to be a lot easier for people to understand. MAE: That sounds awesome. And if you end up needing a bunch of play testers, I bet a lot of our listeners would be totally willing to put in some time. I know I would. Just want to put in one last plug for anybody out there who really loves automating things and is trying to avoid relying on any single developer, or designer, or QA person to remember to check for accessibility is to build it into your CI/CD pipeline. There are a lot of different options. Another approach to couple with that, or do independently is to use the axe core gems, and that link will be in the show notes, where it'll allow you to be able to sprinkle in your tests, accessibility checks on different pieces. So if we've decided we're going to handle color contrast, cool, then it'll check that. But if we're not ready to deal with another point of accessibility, then we can skip it. So it's very similar to Robocop. Anyway, just wanted to offer in some other tips and tricks of the trade to be able to get going on accessibility and then once you get that train rolling, it can do a little better, but it is hard to start from scratch. JOHN: That's a great tip, Mae. Thank you. TODD: Yeah, definitely. MANDY: Okay. Well, with that, I think it's about time we head into reflections; the point of the show, where we talk about something that we thought stood out, that we want to think about more, or a place that we can call for a call of action to our listeners, or even to ourselves. Who wants to go first? MAE: I can go first. I learned something awesome from you, Todd, which I have not thought of before, which is if I am eyeballing for “contrast,” especially color contrast, that's not necessarily what that means. I really appreciate learning that and we'll definitely be applying that in my daily life. [chuckles] So thanks for teaching me a whole bunch of things, including that. TODD: You're welcome. JOHN: I think for me, it's just the continuing reminder to – I do like the thinking that, I think Mae have brought up and also Todd was talking about earlier at the beginning about how we're all of us temporarily not disabled and that I think it helps bring some of that empathy a little closer to us. So it makes it a little more accessible to us to realize that it's going to happen to us at some point, at some level, and to help then bring that empathy to the other people who are currently in that state and really that's, I think is a useful way of thinking about it. Also, the idea that I've been thinking through as we've been talking about this is how do we get the ball rolling on this? We have an existing application that's 10 years old that's going to take a lot to get it there, but how do we get the process started so we feel like we're making progress there rather than just saying, “Oh, we did HTML form 27 out of 163. All right, back at it tomorrow.” It's hard to think about, so feeling like there's progress is a good thing. TODD: Yeah, definitely and as we get older, our eyes, they're one of the first things to go. So I'm going to need assistive technology at some point so, yeah. And then what you touched upon, John. It may be daunting having to go back and do the whole, “Okay, what are we going to do for accessibility now that this project, it's 10 years old, 15 years old?” The SAAS project that I was talking about, it was 15-year-old code, .net. I got people together; one from each department. We all got together and we ended up making that product accessible for them. So it can be done. [laughs] It can be done. JOHN: That's actually a good point. Just hearing about successes in the wild with particularly hard projects is a great thing. Because again, I'm thinking about it at the start of our project and hearing that somebody made it all through and maybe even repeatedly is hard. TODD: Yeah. It's not something that once it's done, it's done. Accessibility, just like the web, is an ever-evolving media. MANDY: For me. I think my reflection is going to be, as a new coder, I do want to say, I'm glad that we talked about a lot of the things that you see that aren't currently accessible that can be accessible. One of those things is using alt tags and right now, I know when I put the social media posts out on Twitter, I don't use the alt tags and I should. So just putting an alt tag saying, “This is a picture of our guest, Todd” and the title of the show would probably be helpful for some of our listeners. So I'm going to start doing that. So thank you. TODD: You're welcome. I'm just reminded of our talk and every talk that I have on a podcast, or with anybody just reminds me of the work that I have to do and the work that is being done by a lot of different people, other than myself as well, as far as advocacy goes in that I don't think it's ever going to be a job that will ever go away. There will always be a need for accessibility advocacy for the web and it's great just to be able to sit down and talk to people about accessibility and what we need to do to make the web better and more inclusive for everybody. Because I tweet out a lot, “Accessibility is a right, not a privilege,” and I really feel that to my core because the UN specifically says that the internet is a basic human and I went as far as to go say, “Well, so as an accessibility of that internet as well.” So that is my reflection. MAE: I'll add an alt tag for me right now is with a fist up and a big smile and a lot of enthusiasm in my heart. MANDY: Awesome. Well, thank you so much for coming on the show, Todd. It's been really great talking with you and I really appreciate you coming on the show to share with us your knowledge and your expertise on the subject of accessibility. So with that, I will close out the show and say we do have a Slack and Todd will be invited to it if he'd like to talk more to us and the rest of the Greater Than Code community. You can visit patreon.com/greaterthancode and pledge to support us monthly and again, if you cannot afford that, or do not want to pledge to help run the show, you can DM anyone of us and we will get you in there for free because we want to make the Slack channel accessible for all. Have a great week and we'll see you next time. Goodbye! Special Guest: Todd Libby.

Hugh Forrest is the Chief Programming Officer for South by Southwest (SXSW), where he oversees content for the SXSW Conference and the SXSW Music Festival, the SXSW Film Festival, and SXSW EDU.He was named "Austinite of the Year" in 2012 by the Austin Chamber of Commerce (along with fellow SXSW Directors Roland Swenson, Louis Black, and Nick Barbaro). In 2014, they were named Austin Entrepreneurs of the Year by Ernst & Young. He received an honorary doctorate of humane letters in 2018 from Kenyon College, his alma mater.In addition to his work at SXSW, he has previously served on the National Advisory Board for the Poynter Institute in St. Petersburg, Florida. Hugh is currently part of the Board of Directors for Austin Habitat for Humanity and serves on the Board of Directors for the Austin-based accessibility company Knowbility.Before joining the SXSW team in the dark ages of 1989, he founded a small monthly alternative publication called The Austin Challenger. He also wrote for several other newspapers and publications, including the Austin Chronicle, the Texas Sports Chronicle, the West Austin News, Willamette Week, and the Seattle Weekly.Photo credit: Dylan O'Connor SXSW Conference & Festivals | March 16–20, 2021"Creativity Without Frontiers" is now available at Unknown Origins Books and all relevant book retailers.Stay in touch:Web: https://www.unknownorigins.com/Twitter: Unknown Origins (@UnknownOrigins9) / TwitterInstagram: Unknown Origins (@unknownoriginsuo77)Facebook: https://www.facebook.com/Unknown-Origins-112791887004124LinkedIn: https://www.linkedin.com/company/unknown-origins/YouTube: Unknown Origins - YouTube Music composed and performed by Iain Mutch@ 2021, Unknown Origins. All rights reserved.Support the show (https://www.paypal.com/unknownorigins)Buzzsprout - Let's get your podcast launched! Start for FREEDisclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show (https://www.paypal.com/unknownorigins)

In this episode, Lori Knudsen of Knowbility Consulting stops by to chat with Brian. Lori talks about the shift in her life to gratitude and how it changed her, her transitions in her life and career, looking in the mirror to see the biggest obstacle to starting her business and how an American Business icon shapes her biggest piece of Intentional Encouragement. 

Emily states: "Hardest part of the job is coming up with solutions. It's one thing to identify what's wrong, it's entirely another thing to give clients an alternative solution that's accessible to start with but also reasonable for them to implement." Thanks to Twilio for sponsoring the transcript for this episode. Make sure you have a look at: Their blog: https://www.twilio.com/blog Their channel on Youtube: https://www.youtube.com/twilio Diversity event tickets: https://go.twilio.com/margaret/ Thanks to Gatsby for being a sponsor of the show. Gatsby is a modern website framework that builds performance into every website by leveraging the latest web technologies. Create blazing fast, compelling apps and websites without needing to become a performance expert. Make sure you have a look at their site: https://www.gatsbyjs.org Transcript Nic: Welcome to the Accessibility Rules Podcast. This is episode 90. It's going to be a bit different because it's been so hot where I've been that I could not go without turning off the air, ac unit, which means I could not actually record without making airplane noises in the back so I've invited Christopher Schmitt, a colleague of mine and previous guest of the show to be the guest host. So, I'll leave that to them in a moment. I'm Nic Steenhout and I talk with people involved in one way or another with web accessibility. If you're interested in accessibility, hey, this show's for you. To get today's show notes or transcript, head out to https://a11yrules.com. Thanks to Twilio for sponsoring the transcript for this episode. Twilio, connect the world with the leading platform for voice, SMS, and video at Twilio.com. I also want to thank Gatsby, a new sponsor of the show. Gatsby is a modern website framework that builds performance into every website by leveraging the latest web technologies. Create blazing fast and compelling websites without needing to become a performance expert. Christopher: Hello, everyone. My name is Christopher Schmitt. I am not Nic but I do welcome you to the Accessibility Rules podcast. Nic can't make it to the podcast this week, he is out traveling where it's so hot he can't actually have great audio. It's my understanding. So he asked me to guest host today. So, I'm really honored to do that. And, with us, today as a guest is Emily Lewis. Hello, Emily. Emily: Hi, Christopher. Christopher: Hey, great. You are also where it's really hot. Emily: It is. I'm in Albuquerque, New Mexico. I think we're going to hit 100 F today. Christopher: Oh, well, nice. Emily: But, I have air conditioning so… Christopher: Yeah, we have air … we have silent running air conditioning, which is… which I am grateful every day as I am living in Austin, Texas now, so… yeah. We are actually celebrating the 28th day of 100 degrees Fahrenheit  in the summer. Emily: Ah, good times. Climate change. Christopher: Yeah, definitely. I think we have a parade a few months ago out here. But, yeah. Let's just get started with you so… Welcome to the podcast, Emily. To get started just tell me one thing most people don't know about you. Emily: I don't know. I'm a pretty transparent person and I've been fairly public within the web community in the past 10 years or so, so I guess if they don't know it about me I don't want them to. So… Christopher: That's Ari. I must admit, we have known each other for a long time, right? Emily: Yeah, yeah. Christopher: Right, I'm just checking in to make sure we are right on that one. We've known each other for a while. Emily: Full disclosure. Christopher: Did you know when we first met? Because I'm terrible with this. Emily: I do. You reached out to me to ask me to do one of your online summits. Christopher:  Oh really? Emily: … and then I happened to be going to South by Southwest later that year and you and Ari took us to BBQ. We didn't know you and it was a long road through backwoods and I was with Jason and he and I were looking at each other like, “I hope these people are safe” Christopher: And it turned out we're not. We …. No, actually, Texas chainsaw massacre was filmed like 45 minutes from where downtown Austin is so… Emily: I believe it. Christopher: So we usually do a … if we have people from out of town we … Ari, my girlfriend and so we should do… we invite people to BBQ. Especially for South by Southwest. So it's not... South by Southwest is not the web geek mecha it used to be, right? Emily: No, not anymore. Christopher: So that's like… I don't know… 80,000 people descend upon Austin whereas when I first started going it was more like 4,000 people going. So, it's a little different. Different scale of economies there. Emily: Yeah Christopher: So...And so yeah, one of the things we do… and, you know, you did a great job at the summit and you just have a great personality on stage. You're so thorough and I just… you know… every time… because, before accessibility, before working with Nic and Knowbility we ran a conference, a web conference company and every time I could, you know, I thought you'd be a good fit. I'd try to get you involved in some way, in some projects like that. So, just because you're very thorough and you have great stage performance. I mean, it's not a performance, I don't know what it is but it's just you have a … going on stage you do a great job. So.. yeah. Emily: Ah, thank you. It doesn't feel that way inside. Christopher: No? Oh no, it definitely does. It's like, I kind of … I tried stand up comedy and just all the little things. I think everyone else is now because every comic ha a podcast now and they talk about the process a lot more than they could, like in the ‘90s and whatever. And so, it's just amazing how much little things they have to do to win over a crowd and all the things they have to think about when you do that too. So, it's kind of refreshing in a way when you think about it. We are just speaking at conferences isn't our … it' normal in our industry but for a lot of other industries it's not normal. Emily: Right Christopher: Because our industry change so much. So, like,  when I was first starting out about it, there was 2 ways you could tell people you know what you're doing. One, you could actually write books about it or you go to conferences about it and then somewhere along the way something called Blogs happened. So that was networking. Right...so enough about me and all. So I'm honored to guest host the podcast with you, actually. Emily: Thank you Christopher: So, yeah. There are many definitions of the definitions on web accessibility. How do you define it? Emily: For me, it's really simple and aligns with my new job with Knowbility. It's equitable access. Making it possible for anybody to access digital information, digital experiences, commerce communities. All of it. Just making it possible. Christopher: So is there a difference between equal access and equitable access? Emily: Well, I think equal access equality is based on the same for everybody and equitable is providing the means for people to have accessibility maybe based on different needs. I think that's accurate. It's not … equitable is not making it the same for everybody, it's about building experiences that different people can use different ways but they can still fundamentally achieve the same goal. Christopher: Okay, sure. Okay. And where does your role fall within the work of web accessibility? Emily: So, right now I've only just recently shifted my career to really, really focus on accessibility so right now I'm doing auditing and assessments of sites and making recommendations for improvements. I'm getting to do a little bit of client support and client training. And, most recently I got to do some usability studies which were just awesome. And, it hasn't shown up too much because I'm still new to the job but advocacy and education that I think that is going to be a big part. So, social media, community engagement, writing, presenting… Christopher: So you're really excited about usability testing that you did. What about it did you like? Emily: I've never had a chance to watch someone interact with a website with speech to text software or eye-tracking software or you know if you've ever done like a ...you're testing screen magnification on our browsers we just resize the text but there's actual screen magnification software that's very different and I got to watch someone use that on their phone which was mind-blowing. So, just seeing first hand how someone is using a site in a different way than I ever have or seen anybody. So, it was eye-opening Christopher: How did you become aware of web accessibility and it's importance? Emily: It really kind of was just a job. One of my first jobs in web development was for a US federal agency. The USDA which is focused on agriculture, and I was a webmaster for one of their conservation sites and the bulk of that job as a webmaster, which tells you how old I am, was keeping the site up to date with 508 standards. So USDA staff would update the site and edit it and do things and I would go behind them to make sure that what they had done met those accessibility standards. It was kind of like an ongoing or rolling audit job. Christopher: Nice Emily: Yeah, so I at the time didn't really have a complete appreciation for the accessibility part of it. Like, I knew it was about accessibility but I didn't have that kind of connection I was just talking about with the user experience. But, I liked … it was a set of rules and I was a new developer trying to figure out how to be a developer so a lot of rules made a lot of sense and made my job easier. So, yeah, but I was attracted to the standards aspect of it before I really understood the accessibility aspect. Christopher: And do you feel like there's a difference between usability and accessibility? Emily: Well, yeah. Something can be technically accessible and not really usable. So, I feel like… my partner Jason - my boyfriend, they don't make a word for people who are in their mid 40's and aren't married but he does usability work for the government but accessibility is a part of it. So, fundamentally things have to meet accessibility and then on top of that, it goes through usability testing. So I guess that accessibility could be viewed as a part of usability. Christopher: Yeah I always have a tough definition there. There's a definition about it that separates usability from accessibility but when I started out it was always tough to separate the two as two distinct items. Because, I felt like if it's not accessible it's not usable, right? You can't have a good user experience if it's not accessible. It was always just like… it still is the barrier of what the difference is between those two. Emily: I honestly feel like our industry is still defining it. I mean, I see it with Jason all the time with his work and he works with the government which are really large projects with lots and lots of people and they're still trying to define this stuff. So, yeah, I think it's ongoing. It's sort of evolving as we understand this stuff. Christopher: Right, and our industry changes so fast, right? Emily: Oh my god yes. Christopher: 5 years ago we were not even talking about tablets. Like, you know. Emily: Yeah, and there's going to be so much more. I mean, as we are seeing now people having these … Echos and … I don't know, I don't have them in my house but these voice-activated devices and, you know, the more that stuff evolves the more our role, our jobs and the aspects of accessibility and usability are going to change too. It's hard to challenge it. Christopher: Yeah, it is. The conventional UIs, I mean with Echos, yeah, That's a bit of trouble, yeah. So, I do have them in my house So, um… Emily: They're watching you. Christopher: Yeah, I call them peeping Toms. That's what I call them. So… but, it is kind of weird but it's basically how much I hate light switches. And so that's why. I just like walking into a room and like, alright, turn it on and then sometimes I get a cold or the flu and you know, your throats sore or whatever and you're like “Man, I wish I had a light switch right now!” Emily: So that would be the thing that most people don't know about you. Your hatred of light switches. But now they do. Christopher: Now they do, yeah. I don't know what they know or don't already. Just, yeah, so...alright. What barriers did you or are you facing in terms of implementing accessibility? And how are you getting over them? Emily: Well, I mean, in my job now that I'm focused on accessibility it's a little different than when I ran an agency and accessibility was just … it really wasn't a priority for my job. So, today I feel like the hardest part of my job is coming up with solutions for some of the sites and interfaces that we work with because it's one thing to identify what's wrong. It's totally a different thing to give them alternatives solutions that's accessible to start with but also pretty reasonable for them to implement and on some level I can't help still being a client. You know, having worked with clients for so long. Like, you still have to support their overall design in business school. Christopher: Right Emily: I think that's incredibly hard. Christopher: Yeah I mean, it's .. it was like, Friday, I left work and I was trying to figure out in the back of my head … we tabulate what we do each day but they're kind of broad strokes. We don't have to do like a timesheet like what we do every hour and so I was trying to figure out where did my afternoon go. And, part of it, I realized on my way home I was like, “Oh yeah, I had to deconstruct this bad code example the client had used and then try to reformulate it into an accessible standards-based solution” and it took forever. Emily: Yup Christopher: Just to do that, right? And, it was a total time sink. Emily: Yup Christopher: Not like… I mean, it was good. It was a good challenge to do it but it still takes a long time to do that if it's not something easy code. It's amazing. And, I said this sarcastically last week. I was just impressed with the ability of the developers to avoid Semantic HTML. Emily: Yeah, I mean… Christopher: Yeah Emily: I was working on that same system with you and it was just, every day it was just an “Oh, that never would have occurred to me to do that.” Christopher: Yeah. Exactly. It was kind of crazy. But, yeah, I think that's also kind of our … like what we do is a benefit too. It's like we actually give alternatives to clients. I guess that's what we … that's kind of neat too. Emily: Yeah and I also like… you know we work with some really, really smart people who have a lot of experience and so, you know, watching what they do. How they make suggestions and solutions, really helps me expand what I might have considered in the first place, as a way to make a problem access… you know, solve it and make it accessible. So, yeah. I feel really lucky we have a lot of people who have so much more experience than I do. Christopher: What is your favorite word? Emily: Well, I don't know if this is like a PG-13 podcast so Nic can … I'll give you two options for Nic to choose from, but Christopher, you know this. Fuck is probably my favorite word. But, for the PG-13 listeners - ice cream. Ice cream makes me so happy. If someone says ice cream I'm instantly looking forward to it. Christopher: Oh man, you are going to enjoy Access-U, which is the conference that Knowbility puts on. It's for practical training purposes in accessibility. Ah, for the last two years they've brought an ice cream truck to the event. So, you will… Hopefully I made you happy and looking forward to May already. Emily: Alright now I'm like - I've got to get some ice cream today. Christopher: So, yeah. So like, I feel bad because Nic asked me this question and I just… I whiffed at it and so I didn't answer the question. And so, now that I have a second chance of sorts. If you don't mind me saying what my word is? Emily: Oh yeah, do it. Christopher: It's moist. Emily: Oh, you like that word? Christopher: Yeah, that's exactly why I like that word. Because everyone hates it. So, I feel like it says what it is in a way. It's like… it's kind of gross. Yeah. Emily: I like it for cake. Anything else just makes me think of humidity and discomfort. Christopher: Yeah, well I grew up in Florida. So I feel… Emily: Yeah, you love that, right? Christopher: Yeah, I just can't wait. Yeah. The move from Florida to Ohio which didn't happen in the end… I was just like, “What the heck. What's going on over here?” Christopher: What was your greatest achievement in terms of web accessibility? Emily: I really don't feel like I've achieved it yet. I mean, I've been doing front-end development, CMS development, project management for digital products for like 23 years or something like that and I've always built with standards of accessibility in mind but it's never… it's never been the focus. I've only just done that shift a few months ago so I haven't had a chance to do anything great. Christopher: I see ...I see some of your issue reports. I think you've done some great issue reports. Emily: You know, I will say that I used to have a podcast myself and it started, I guess about 8 or 9 years ago which was kind of early and we had transcripts right from the beginning. That was really important to me. Christopher: Yeah Emily: I don't know if that's a great achievement but it was a commitment that I felt was important. Christopher: Yeah, just think about how many podcasts there are that don't have transcripts. Emily: I don't understand that. Christopher: Yeah Emily: I really don't understand that. Christopher: Yeah, I felt bad because I don't have transcripts for my own podcasts that I used to run and I just … there was all this content that was just waiting to be discovered and all this content that's not been discovered. I mean, even though they have video of a podcast that they turn into audio and they don't have a transcript for it. Emily: Mmhmm, well I mean, it's an accessibility issue. But, there's business reasons for it. I mean, Google eats that up. Your podcast gets a tonne more exposure. I mean, our podcast was getting high… high up in the Google search results for almost all of our web topics. Because we had lots and lots of keywords. Christopher: Yeah. Emily: And also helps you consume the content in a different way. Like, maybe you can't listen to it and you want to scan the transcript for saline information. It just makes sense. Christopher: Yeah, I think so. Okay, cool. Well, that's awesome. Well, that's a good place for us to wrap up for now. But, thanks for being on the Accessibility Rules podcast. Emily: Thanks for having me. Christopher:  Okay, awesome. Until next time. Nic: Thanks for listening. Quick reminder, the transcript for this and all other shows are available on the show's website at https://a11yrules.com Big shoutout to my sponsors and my patrons. Without your support, I couldn't not continue to do the show. Do visit patreon.com/steenhout if you want to support the accessibility rules podcast. Thank you.

Show Description****************We're talking accessibility with Christopher and Nicolas from Knowbility. Does accessibility transcend the web? Is it discouraging how much work still needs to be done? How do we get people the skills needed to help with accessibility on the web? Should accessibility be a role in house? And is Javascript the enemy of accessibility? […]

If you don’t feel “engaged” at your job, this is the podcast for you!  Even if you do, perhaps you know someone who isn’t.  Maybe it would be a good time for them to speak with a Career Consultant to see if they are truly in a position that is fulfilling to them.  My Why […] The post Lori Knudesn, Founder of Knowbility Consulting is my Why Can’t You? podcast guest this week! appeared first on Why Can't You?.

Nic Steenhout is a long term A11y (accessibility) advocate who works remotely for Knowbility, an Austin, TX based non-profit. In this episode Scott and Nicolas talk about various kinds of accessibility from the web to mobile devices to wheelchair ramps! He's also the host of the A11y Rules podcast. https://twitter.com/vavroom https://a11yrules.com/

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.

Glenda Sims is an accessibility consultant, speaker, author and trainer for Knowbility, a non-profit whose mission is “barrier free IT”. She works at Deque where she is a Senior Accessibility Consultant. There she shares her expertise and passion for the open web with government, educational institutions, small businesses and Fortune 500 companies. She performs hands on web accessibility assessments, develops accessibility roadmaps and strategies, and consults with developers and designers.

Glenda Sims is an accessibility consultant, speaker, author and trainer for Knowbility, a non-profit whose mission is “barrier free IT”. She works at Deque where she is a Senior Accessibility Consultant. There she shares her expertise and passion for the open web with government, educational institutions, small businesses and Fortune 500 companies. She performs hands on web accessibility assessments, develops accessibility roadmaps and strategies, and consults with developers and designers.

Glenda Sims is an accessibility consultant, speaker, author and trainer for Knowbility, a non-profit whose mission is “barrier free IT”. She works at Deque where she is a Senior Accessibility Consultant. There she shares her expertise and passion for the open web with government, educational institutions, small businesses and Fortune 500 companies. She performs hands on web accessibility assessments, develops accessibility roadmaps and strategies, and consults with developers and designers.