Podcasts about deque

In this episode of the Post Status Happiness Hour, host Michelle Frechette interviews Gen Herres from Easy A11y Guide to discuss web accessibility. Jen shares her background as a developer and her journey in understanding and implementing accessibility standards. She emphasizes the importance of simplifying complex accessibility concepts for clients and offers strategies for agencies to sell accessibility services. Jen introduces a five-day challenge to help agencies qualify potential clients and sell their first accessibility package. The conversation highlights the significance of making websites accessible to a broader audience and the various reasons why accessibility is essential for businesses.Top Takeaways:Accessibility Doesn't Have to Be Scary:  Many people find web accessibility intimidating, but experts like Gen Herres help simplify the process. There are resources available to make accessibility more approachable.Planning for Accessibility Takes Time: Implementing accessibility properly requires time for strategy, testing, and client approvals. Starting now helps businesses integrate it seamlessly into their workflow instead of rushing later.Accessibility Can Help Generate More Revenue: Learning how to sell accessibility services effectively can help web professionals increase their income by offering more value to clients.Mentioned In The Show:Easy A11y GuideWCAGMozilla17 HatsEqualize DigitalWacomNew York E-Z Pass Apple VoiceOverDequeJAWSCloudflareWPAccessibility.dayCami MacNamara5-Day Accessibility Selling ChallengeAgency Accessibility SystemGuidebook for Accessibility at Your Agency

Diesmal geht es um ein Thema, das in der digitalen Produktentwicklung noch oft unterschätzt wird: Barrierefreiheit. Mit den Experten Marcel Bertram und Daniel Diener, beide Gründer von A11YPLAN, sprechen wir in dieser Folge über die Bedeutung von Barrierefreiheit in digitalen Produkten und warum sie nicht nur für Menschen mit Behinderungen relevant ist. Barrierefreiheit ist nämlich weit mehr ist als eine rechtliche Notwendigkeit. Barrierefreie Produkte schaffen generell bessere Nutzererlebnisse. Sie sorgen dafür, dass keine Stolpersteine im Weg stehen, wenn Menschen digitale Services nutzen möchten. Egal ob jemand blind ist, vorübergehend eine Einschränkung hat (weil man beispielsweise ein Kind auf einem Arm trägt) oder schlichtweg unter schlechten Lichtverhältnissen arbeitet – ein gutes UX-Design und barrierefreie digitale Produkte machen das Leben leichter. Und das betrifft am Ende uns alle, denn jeder von uns kann in Situationen kommen, in denen eine Website oder App schwerer zugänglich wird. Auch Dinge wie eine langsame Internetverbindung oder schlecht designte mobile Seiten können Hindernisse darstellen und das kennen wir wahrscheinlich alle irgendwo. Barrierefreiheit bedeutet also nicht nur, sich auf spezielle Nutzergruppen zu konzentrieren, sondern das gesamte Produkt so zu gestalten, dass es für jeden einfach nutzbar ist. Seit der Einführung des European Accessibility Act, der ab Juni 2025 gilt, müssen Unternehmen, die digitale Produkte oder Services anbieten, barrierefreie Angebote schaffen – und das nicht nur für neue Websites, sondern auch für bestehende, wenn sie wesentliche Aufrufe erfahren. Doch Marcel und Daniel machen klar: Barrierefreiheit ist nicht nur eine Frage des Gesetzes. Sie ist vielmehr ein klarer Business Case: Gut zugängliche Produkte reduzieren Supportanfragen, erhöhen die Kundenzufriedenheit und steigern den Umsatz. Die Berücksichtigung von Barrierefreiheit in der Produktentwicklung spart nicht nur Kosten, sondern ist auch eine langfristige Investition in die Kundenzufriedenheit. Für Product Owner, die sich bisher noch nicht intensiv mit dem Thema beschäftigt haben, empfehlen Marcel und Daniel, mit einer Bestandsaufnahme zu beginnen. Hier gibt es bereits zahlreiche Tools wie Google Lighthouse oder Deque, die automatisierte Prüfungen durchführen können. Doch das allein reicht nicht: Eine manuelle Überprüfung und echte Nutzertests mit Menschen, die Einschränkungen haben, sind unerlässlich, um sicherzustellen, dass das Produkt wirklich barrierefrei ist. Am Ende der Folge, wie immer, geben die beiden Experten praktische Tipps für den Einstieg in die Welt der Barrierefreiheit. Empathie ist dabei ein zentraler Punkt: Product Owner sollten sich aktiv mit der Frage auseinandersetzen, wie Menschen mit Einschränkungen ihre Produkte nutzen. Eine einfache Übung kann schon sein, auf dem eigenen Smartphone die Barrierefreiheits-Einstellungen zu testen oder Menschen aus dem eigenen Umfeld dabei zu beobachten, wie sie mit den Produkten interagieren. Barrierefreiheit ist keine Herausforderung, die Unternehmen vor sich herschieben sollten. Sie ist ein Schlüssel zu besseren Produkten, zufriedeneren Nutzern und langfristigem Erfolg. Wenn du als Product Owner dein Produkt auf das nächste Level heben willst, führt kein Weg an einer barrierefreien Gestaltung vorbei.

Estás escuchando una sección que explica cuestiones de la lengua española, su posición en el mapa de lenguas mundial y su relación con otras lenguas en la historia y en el momento actual. Todo ello gracias a Lola Pons, catedrática de Historia de la Lengua en la Universidad de Sevilla. Analizamos el lenguaje desde todas las perspectivas.

It's an all new extra extra big That Real Blind Tech show as it's our 2024 CSUN recap episode. It is so big that we have the ladies Jeanine and Allison recording with friend of the podcast David Goldstein and because someone who edits the show got sick we then have Brian and Ed recapping CSUN as well. It all comes together in one giant Kumbaya podcast episode for your listening pleasure.   Jeanine starts out discussing the announcements made by Aira at this year's CSUN. We'll give you a clue it has something to do with A.I.   And because Brian and Ed were not here yet, Allison, David , and Jeanine then discuss the braille with a lower case b keyboards announced at this year's CSUN.   We then cut to our main men on the ground at CSUN for their insights in to everything they experienced first hand at this year's CSUN.   Brian and Ed start off discussing a recent article by a man who is losing his vision that appeared in the Atlantic, and they could not disagree with the article more. They then discuss the upcoming release of David Kingsbury third edition of the Windows Screen Reader Primer. And then discuss the upsetting news about VoiceDream Reader moving to a monthly subscription model even if you have bought a lifetime license.   Mike Buckley then pops by to discuss the latest announcements coming out of Be My A.I.   Brian and Ed discuss the multiple cocktail hours they hit at CSUN, OKO, the new Guidance Guidance System, Celeste Glasses, Enivision AI, Vispero, Deque, WeWalk Cane, Fa Fable,  Stevie Wonder, Irish Car Bombs, Google Suite, and much more that they experienced in person at CSUN.     It's then back to the ladies and David for some more banter and more of Watcha Streaming, Watcha Reading. 

Impulsar el desarrollo barrial mediante la evaluación, priorización y negociación de lasnecesidades socio-económicas, a fin de diseñar y ejecutar políticas y programas socialescon instituciones del Gobierno Central, es parte de la misión de la ComisiónPresidencial de Apoyo al Desarrollo Barrial. Pero qué es en realidad esta comisión? Deque se encarga? ¿Cuáles son los proyectos que lleva a cabo? Donde tiene mayorpresencia? ¿Cómo usted en su barrio puede beneficiarse del programa que realiza? Poreso hemos invitado a su presidente el señor Rolfis Rojas.

Most people don't think about accessibility when it comes to the internet. We think of ramps and braille signs and audiobooks. But physical and developmental issues are much more complex than being able to get into a restaurant, especially when it comes to security. I talked with Justin Merhoff, chief of security for Deque (pronounced Dee-cue) Systems in Virginia about the need to make software and digital systems usable for all people, not just most people. And there is an action item for all you in the audience. The National Institute for Science and Technology is working on the first draft of NIST SP 800-50, a standard for cybersecurity and privacy learning, but this draft contains virtually nothing related to people with physical and learning disabilities. If you or people you care about fit that category, now is your chance to give feedback for that standard≥ Go to the site and download the form for comments. Make your voice heard now. --- Send in a voice message: https://podcasters.spotify.com/pod/show/crucialtech/message Support this podcast: https://podcasters.spotify.com/pod/show/crucialtech/support

Mark Steadman, Fidelity Investments, Director, Software Engineering - Mobile AccessibilityMark Steadman is Director of Mobile Accessibility at Fidelity Investments. Mark has made a career of being a developer who helps other developers be successful in supporting accessibility. He talks about what makes an efficient and consistent process for the developer side of things. His work began at State Farm supporting the Accessibility for Ontarians with Disabilities Act (AODA). That led to learning about assistive technologies, working at Deque, and now his current activities with mobile. Mentioned in this episode:Info about Accessibility at Blink

Salvete multum sodales omnes! Andreas solus vos alloquor nam Clara in Italia versatur Ilsaque aliis rebus maximi quidem momenti operam dat. Hoc igitur vobis soliloquium excepi ut de coeptis nostris aut nuper aut iam ante aliquod temporis spatium incohatis de eorum progressu loqui possem atque etiam de anni scholastici fine ad cuius finem paene perveni ego! Spero hoc episodion vobis esse placiturum! Ecce linktree nostrum ubi omnia nostra inveniri possint: https://linktr.ee/latinitasanimicausa Scribite ad nos! Suntne vobis consilia aestiva iam capta? Vosne ad aliquod Latine loquendi conventiculum ibitis? --- Send in a voice message: https://podcasters.spotify.com/pod/show/latinitas-animi-causa/message Support this podcast: https://podcasters.spotify.com/pod/show/latinitas-animi-causa/support

Guest Mike Gifford Panelist Richard Littauer Show Notes Hello and welcome to Sustain Open Source Design! The podcast where we talk about sustaining open source with design. Learn how we, as designers, interface with open source in a sustainable way, how we integrate into different communities, and how we as coders, work with other designers. Today, Richard is super excited to have as his guest, Mike Gifford, who's a Senior Strategist at CivicActions and a thought leader on digital accessibility and the public sector. He was the Founder and President of OpenConcept Consulting, which worked extensively with Drupal, and he became a Drupal 8 Core Accessibility Maintainer in 2012. As a long-term environmentalist, Mike has found ways to integrate his passions for the web and planet. Today, Mike talks about his views on sustainability, his work with open source software, and the importance of accessibility and multilingualism in technology. Download this episode now to hear more! [00:02:18] Mike shares his views on sustainability, and he tells us he's been working fully with CivicActions for the last two years after closing OpenConcept Consulting. [00:04:18] We learn about CivicActions, a web development firm that does a lot of work with both open source and Drupal, as well as HCD. They primarily work in the government space, largely focused on the US government. [00:05:15] Mike tells us about the Canadian Open Source Advisory Board that he runs. [00:06:21] We find out the differences between the Canadian and US government's approach to open source software. [00:08:13] How does Mike see himself as a designer in all these conversations? He talks about the work he does with the Drupal community to make Drupal more accessible. [00:09:35] Mike explains where oral design interfaces mix with open source and he mentions Preston So from the Drupal community, who wrote the book, Voice Content and Usability. [00:11:11] We hear about the groups of people who are looking at accessibility. [00:13:38] There's some great tools that are useful when talking about the disability spectrum, such as Accessibility Insights, which is a Microsoft tool, and an accessibility engine called, axe, which was built by Deque. [00:15:41] Mike talks about the multilingual accessibility being a challenge in technology, and the challenges of identifying language content and tools, especially in open source software, and the predominance of English in accessibility resources. [00:18:02] We hear about the open source work Mike's doing with CivicActions, a project he was involved in creating called, OpenACR, and the need for procurement to include accessibility requirements. [00:20:52] He highlights the responsibility of open source maintainers to set an example of accessibility best practices. [00:22:39] How does Mike think ChatGPT is going influence accessibility practices? He emphasizes the responsibility of humans to evaluate and implement accessible code. [00:26:00] Richard and Mike discuss the importance of building accessibility into the workflow of teams and developers. Accessibility is not just for those with disabilities but for everyone since abilities can impact all of us at one point. [00:30:58] Mike tells us where you can find him on the web. Quotes [00:02:33] “Sustainability is a word that is too loose and can be applied to many things much like accessibility.” [00:13:51] “It's about trying to remember that this is about progress, not perfection.” [00:21:07] “I think there's a huge responsibility for open source maintainers to set an example.” [00:21:35] “If you provide examples in your code that aren't following accessibility best practices, then you're propagating that.” [00:29:16] “Accessibility doesn't just affect a small number of people; it affects all of us at one point or another because we're human.” Spotlight [00:31:43] Richard's spotlight is his neighbor, Susan Reid, and The Kitchen Table Poems that she writes. [00:32:23] Mike's spotlight is CO2.js, a project from The Green Web Foundation. Links Open Source Design Twitter (https://twitter.com/opensrcdesign) Open Source Design (https://opensourcedesign.net/) Sustain Design & UX working group (https://discourse.sustainoss.org/t/design-ux-working-group/348) SustainOSS Discourse (https://discourse.sustainoss.org/) Sustain Open Source Twitter (https://twitter.com/sustainoss?lang=en) Richard Littauer Mastodon (https://mastodon.social/@richlitt) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Mike Gifford LinkedIn (https://www.linkedin.com/in/mgifford/) Mike Gifford Twitter (https://twitter.com/mgifford) Mike Gifford Mastodon (https://mastodon.social/@mgifford) CivicActions Accessibility (https://civicactions.com/) CivicActions (https://civicactions.com/) Preston So (Books) (https://preston.so/) Accessibility Insights (https://accessibilityinsights.io/) OpenACR (https://github.com/GSA/openacr) Axe tools-Deque (https://www.deque.com/axe/) The Kitchen Table Poems by Susan Reid (https://tinyletter.com/poems-tunes) The Green Web Foundation-CO2.js (https://github.com/thegreenwebfoundation/co2.js/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Mike Gifford.

Welcome to Episode 30 of More than a Refresh, where JD sits down with Glenda Sims, "the good witch of accessibility" and Chief Information Accessibility Officer at Deque Systems. Listen in as they discuss why independence is the crux of accessibility, social structures vs. brain patterns, and why accessible design is good for all users. Please click here to access a transcription of this episode.

Quer aprender sobre carreira, marketing, negócios, inovação e muita motivação? Mara é formada em técnico em contabilidade e Graduada em Pedagogia. Se dedica a empresa Contra Fogo Jung que seu pai e seu tio adquiriram há 26 anos, atualmente exerce a função de gerente administrativo financeiro. Marina é Cirurgiã dentista formada pela Unisul, pós-graduada em cirurgia, especializando-se em ortodontia e ortopedia facial e mini residente em Harmonização Orofacial.

[LA] Diluvii memoria homines a vitiis arcere non valuit qui peiores in dies fiebant. Attamen Abrahamus, vir virtute ac pietate ornatus, Deo placuit, qui ei progeniem numerosissimam promisit. Postea, a Deo probatus, fidem suam mira oboedientia demonstravit. [EN] In today's episode we read the story of Abraham's election and faith and Isaac's sacrifice

In this episode of the podcast, Bart speaks with The Humphrey Group's Director of Learning Experience Design about the often-overlooked importance of making your communication accessible. Justyna explains why it's never been more important – and easier – to think about how to reach all audiences. She explains what accessible communication is, why it's overlooked, tools and technology you can use (and already have at your fingertips) and resources to draw on. By the end of this conversation, you'll see why every leader who wants to inspire should think about making their communication accessible. Visit the following links for resources and further reading on accessibility: Haben Girma – Disability justice lawyer, author, speaker, & inclusion activist: https://www.linkedin.com/in/habengirma Sheri Byrne-Haber – Certified accessibility professional with a background in universal design, law, & business: https://www.linkedin.com/in/sheribyrnehaber Tiffany A. Yu – Disability advocate and CEO & founder of Diversability: https://www.linkedin.com/in/tiffanyayu IAAP – For accessibility-related news and updates as well as job opportunities: https://www.accessibilityassociation.org/ Deque systems – Self-directed learning on digital accessibility: https://www.deque.com/ 00:27 Intro 01:05 Introducing Justyna 02:07 Bart introduces "accessibility" 02:56 How Justyna works on accessibility 03:58 Define accessibility 04:23 Examples of poor accessibility 05:55 Justyna's story 06:18 ADHD and learning disabilities diagnosis 08:25 The importance for leaders to understand accessibility 09:18 Industries seeking out neuro-diverse talent 10:04 Accessibility is not just for disabled people. It makes the product better for everyone 10:56 Providing multiple ways to represent content 12:32 Stats on disabilities 13:41 Things communicators need to know 15:46 Cognitive load 16:24 Increase the likelihood your message will get across 17:47 New tech is helping 18:24 Examples of using smartphone differently from spouse 20:13 3 pieces of advice to leaders 20:57 Don't surprise me! 23:11 Structure is key 23:51 Present multiple ways 25:33 Everyone is the expert on their own experience 26:39 Make sure that mistakes are OK 27:40 Bart sums it up 28:37 Advice on getting started 29:41 Resources 30:39 Thank yous 30:59 Outro

[LA] Aucto hominum numero, neminem praeter Noémum invenit Deus qui virtutem colebat. Itaque Noemus, a Deo admonitus, arcam ex ligo factam exstruxit et in eam par omnium animalium induxit. Pluit vehementer quadraginta diebus. Quidquid in arca non inerat, periit. Postea autem Deus foedum cum Noemo fecit eique dixit deinceps nullum diluvium terrae contingere. [EN] In today's episode, we read the story of the great flood. God chose Noah and established an alliance with him.

Eterno Retorno: El regreso a la filosofía en su edición 2023. Una vez mas Goris y Fernandez retornan a la constante búsqueda del saber de color. En esta oportunidad el retorno es el tópico, y se barajan en el episodio las implicancias varias que tiene el tema para los disertantes.

It's an all new That Real Blind Tech Show. Brian and Ed welcome in Justin Yarbrough from Deque Systems. Justin will be presenting at this year's all virtual Axe-Con taking place on March 15 and 16th. You can register to attend the conference here.   We kick the interview off learning a little bit about Justin's backstory. Justin then explains to us what he does at Deque Systems as an Accessibility Consultant.   Justin tells us a little about his presentation at this year's Axe-Con. His presentation will be on the second day of the all virtual conference on March 16th and will be about working in Digital Accessibility with a disability.   Justin explains to us what he enjoys about working in digital accessibility, and walks us a little through Deque's testing philosophy.   We then get Justin's advice for anyone looking to get in to the field of Digital Accessibility, and learn about Deque University.   Next we dive into Justin's role as an advocate for the blind, as Justin has written a few articles about the   on board flight entertainment systems and accessibility issues specifically focused on United Airlines.   We discuss the current state of web accessibility and what is wrong with it. We get Justin's thoughts on what you should do if you come across a website or app with accessibility issues.   Justin then tells us about his go to tech products.   Make sure to tune in to Axe-Con on Thursday, March 16th to hear Justin's presentation, and you can keep up with Justin on Twitter at @FatElvis04 and on his website.   To contact That Real Blind Tech Show, you can email us at ThatRealBlindTechShow@gmail.com, join our Facebook Group That Real Blind Tech Show, join us on the Twitter @BlindTechShow , or leave us an old school phone message at 929-367-1005, and make sure to visit our website where you can listen to any of our past episodes.

On today's episode, we're talking to Dylan Barrell, Chief Technology Officer at Deque Systems, Inc, a web accessibility software and services company aimed at giving everyone, regardless of ability, equal access to information, services and applications on the web.We talk about:- Dylan's background and what Deque does.- The importance of accessibility in software.- Dylan's book, “Agile Accessibility Handbook,” and why he wrote it.- Are there any particular tools to identify accessibility issues in software?- Countries that are leading the way around SaaS accessibility.- Advice for smaller, newer SaaS companies to prioritize accessibility.- How tech trends like AI, the IoT and algorithms have impacted accessibility.Dylan Barrell - https://www.linkedin.com/in/dylanbarrell/Deque Systems - https://www.linkedin.com/company/deque-systems-inc/This episode is brought to you by QrveyThe tools you need to take action with your data, on a platform built for maximum scalability, security, and cost efficiencies. If you're ready to reduce complexity and dramatically lower costs, contact us today at qrvey.com.Qrvey, the modern no-code analytics solution for SaaS companies on AWS.#saas #analytics #AWS #BI

Palabras al aire con Sagrario Fernández-Prieto.Suscríbete a CesarVidal.TV y escucha este audio antes que nadie y sin publicidad: https://www.cesarvidal.tv1. Padrón2. "shopping"3. "streetwear"4. "mary janes"5. Evasé6. "brand curator"7. Dequeísmo8. Área9. "sofases"10. "vertir"11. Trolebús12. Volvoreta

En este stream te cuento sobre el fenómeno que se da en el español conocido como "dequeísmo" y cómo evitar caer en él.

James and Amy discuss common accessibility mistakes that you should avoid in your web applications.SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:02:54 - What is Accessibility00:10:59 - Sponsor Shoutout: Dato CMS00:11:52- 1. Not Using Alt Tags on Images00:15:30 - 2. Not Using Semantic HTML Tags00:22:16 - 3. Not Checking for Accessible Colors and Contrast Ratio  00:24:18 - 4. Relying on Color To Communicate00:26:10 - 5. Not Adding Validation to Your Forms00:29:39 - 6. Setting Outline to None00:30:45 - 7. Ignoring Reduced Motion Preferences00:33:08 - Sponsor Shoutout: Zeal00:34:00 - 8. Using Non-descriptive Link Text00:35:16 - 9. Not Using Aria Role Tag00:37:29 - 10. Not Labeling Your Input Fields00:39:16 - Additional Resources00:40:50 - Grab Bag Questions00:41:16 - Picks and PlugsLinksGive a Damn About Accessibiility - https://www.accessibility.uxdesign.cc/A11ycasts - https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7gStorybook - https://storybook.js.org/Deque - https://www.deque.com/Ekster Wallet - https://ekster.com/Peak Design Bag - https://www.peakdesign.com/products/travel-duffel

Christopher Land, Oracle, Senior Accessibility Technical Program Manager Chris started out in web development and was first exposed to accessibility working for the University of Michigan. That led to accessibility consulting work at Deque and Level Access where he learned from a great team of experts and did a lot of training. Now he is Senior Accessibility Technical Program Manager at Oracle. 

Recordamos qué son el dequeísmo y el queísmo, con algunas reglas prácticas para detectarlos y evitarlos. En el apartado de consultas, hablamos de los verbos «clicar» y «cliquear».   Escuchar audio

Brian and Ed welcome in Jon Buonaspina to the That Real Blind Tech Show lair. Jon works for DeQue Systems.   Jon begins with  telling us what DeQue Systems does, and what his role with the company entails. He then lets us know how someone without a visual impairment ended up working in accessibility.    We then get Jon's thoughts about whether or not the Department of Justice should implement some kind of minimum web accessibility standards, and yes, we hate using the word minimum.   Jon discusses some of the tools he uses when working with a client, and how he learned screen reader technology.   The conversation then turns to Laugh For Sight and The roast of Brian Fischler which Jon was at.   If your company is in need of accessibility fixes, maintenance, help building your companies accessibility team, please reach out to Deque Systems here.      To contact That Real Blind Tech Show, you can email us at ThatRealBlindTechShow@gmail.com, join our Facebook Group That Real Blind Tech Show, join us on the Twitter @BlindTechShow , or leave us an old school phone message at 929-367-1005.

Cicero Augustinum fecit Christianum? In libro tertio Confessionum Augustinus narrat quo modo Ciceronis verba suum animum mutaverint. ______________________ Did Cicero turn Saint Augustine into a Christian? In the third book of the Confessions, Saint Augustine narrates the effect of reading Cicero on his life. ______________________________________________ Paginarum nexus: Twitter: https://twitter.com/litteraechristi​ Youtube: https://youtu.be/nOgWAio3BYk #latin​ #latinpodcast​ #latineloquor​ #christianlatin​ #ecclesiasticallatin​ #ecclesia​ #ecclesiacatholica​ #SaintAugustin #Augustinus #Sanctus Augustinus #confessions #confessiones

In this episode, I talk to Chris Coyier and Dave Rupert from the Shop Talk Show! We talk about all sorts of topics having to do with front end development, design, and accessibility. Specifically, web components, CodePen, Eleventy, Astro, and much, much more! Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Sound editing by Chris Enns of Lemon Productions. Transcripts can be found at: https://toddl.dev/podcast/transcripts/shoptalkshow/ Show Notes https://twitter.com/chriscoyier - Chris on Twitter https://twitter.com/davatron5000 - Dave on Twitter https://chriscoyier.net/ - Chris's Homepage https://daverupert.com/ - Dave's Homepage https://codepen.io/ - CodePen https://paravelinc.com/ - Paravel https://css-tricks.com/ - CSS-Tricks https://shoptalkshow.com/ - Shop Talk Show https://www.youtube.com/realcsstricks - Real CSS Tricks YouTube https://larahogan.me/donuts/ - Lara Hogan Donut Manifesto https://www.deque.com/axe/ - axe (Deque) https://tenon.io/ - Tenon https://webaim.org/ - WebAIM https://wave.webaim.org/extension/ - WAVE browser extension https://developers.google.com/web/tools/lighthouse/ - Google Lighthouse https://www.w3.org/TR/WCAG21/ - WCAG (Web Content Accessibility Guidelines) https://twitter.com/goodwitch - Glenda Sims (@goodwitch) https://astro.build/ - Astro https://slinkity.dev/ - Slinkity https://www.netflix.com/title/81228573 - Komi Can't Communicate --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

Palabras al aire con Sagrario Fernández-Prieto. Suscríbete a CesarVidal.TV y escucha este audio antes que nadie y sin publicidad: https://www.cesarvidal.tv 1. Sazón 2. "Blue monday" 3. Por si las moscas 4. "están haciendo que" 5. "insolente fallecimiento" 6. Dequeísmo 7. Rato 8. Trabajo en proceso 9. Piel fina 10. Yocovid

Palabras al aire con Sagrario Fernández-Prieto. Abónate a nuestro canal en IVOOX por 3€ al mes y podrás acceder a este audio antes que nadie y sin publicidad. 1. Ukelele 2. Raudales 3. LOL 4. Meterse en un jardín 5. "frases aspiracionales" 6. "blanco sobre negro" 7. Verso suelto 8. Dar motivos 9. "civilizatorio" 10. "yo de ti" 11. "divertáis" 12. Dequeísmo

Links from the show:PHP 8.1 Breaking ChangesBC breaking changes in PHP 8.1Adding final class Deque to PHPThis episode of PHPUgly was sponsored by:Honeybadger.io - https://www.honeybadger.io/PHPUgly streams the recording of this podcast live. Typically every Thursday night around 9 PM PT. Come and join us, and subscribe to our Youtube Channel, Twitch, or Periscope. Also, be sure to check out our Patreon Page.Twitter Account https://twitter.com/phpuglyHost:Eric Van JohnsonJohn CongdonTom RideoutStreams:Youtube ChannelTwitchPeriscopePowered by RestreamPatreon PagePHPUgly Anthem by Harry Mack / Harry Mack Youtube ChannelThanks to all of our Patreon Sponsors:Honeybadger ** This weeks Sponsor **ButteryCrumpetShawnDavid QKen FTony LFrank WJeff KShelby CS FergusonBoštjan OMatt LDmitri GKnut E BMarcusMikePageDevRodrigo CBillyDarryl HBlaž OMike WHolly SPeter ABen RLuciano NElgimboWayneKevin YAlex BClayton SKenrick BR. C. S.ahinkledreamupEnno RSeviMaciej PJeroen FRonny M NChris CTristan IF'n SteveRobertThorsten

Janos is an experienced certified web accessibility specialist who spent the last 5 years driving accessibility efforts in a large financial institution. We talk about his story of getting into the field, why inclusive design is important, how you can start learning the basics, the challenges of retrofitting existing internal tools to satisfy accessibility requirements, and a lot more. Also, Janos shares a bunch of easy tips and tools for designers who want to create accessible products and experiences. We got so much content, that we couldn't fit all the information into 1 recording, so we are going to get the second session focusing on the future of accessibility in design and common objections against it. Janos on Linkedin Janos on Twitter axe by Deque

#94 If you rely on automated web accessibility tools, you're doing it wrong. A site could pass an automated checker and be filled with major accessibility errors. Find out 12 issues automated web accessibility checkers can't detect.

Hey friends! Our first podcast is in the books! Although I was nervous as heck, it was a blast getting to spend time with some people who really know their stuff when it comes to accessibility. Jon Sasala was the perfect complement in style to mine which apparently involves looking at the corner of my screen. Note to self, need to work on looking at or near the camera on occasion. And if Jon wasn't enough, I had the honor of hearing both Tanya Scales and Jon McLaren of HubSpot really drive it home. If you have thoughts about this episode and want to comment, go on over to the HubSpot Community Developers' Blog and comment away! Video link As promised here are the show notes! The WebAIM Million Report: Statistics on accessibility web-wide. HubSpot Developer Documentation on accessibility: This guide was written to be a good starting point for those starting to learn about accessibility. Deque courses and axe tools: Popular accessibility testing tools and educational information. HubSpot theme boilerplate GitHub repository: Start from a foundation that HubSpot and community members continue to iterate on improving accessibility, performance, and best practices. Feel something could be better? contribute! HubL menu() function: Build your own menu HTML, CSS, and JavaScript. Web Content Accessibility Guidelines (WCAG): The industry standards for digital accessibility. Deque - Coding Accessible SVGs: The comprehensive screen reader test mentioned by Tanya during the podcast - re: Stefen's question IAAP - International Association of Accessibility Professionals: Referenced during podcast for Tanya's credentials - for more information on this org and certifications Web A11y Slack workspace (not HubSpot) The #accessibility channel in our HubSpot Developer Slack.

A few months ago we heard from Amber Hinds about the importance of accessibility and how her WordPress plugin can help you create more accessible content. She also said that you need a human being to catch most accessibility issues – that’s where Bet Hannon comes in. Bet tells us all about what to look for when auditing your website, and how to execute a sampling audit. We also talk about a TON of tools. In Build Something More, listeners get a pre-and post-show. The pre-show is all about beer. The post-show is about database queries. (more…) View on separate page Transcript Joe Casabona: Real quick before we get started, I want to tell you about the Build Something Weekly newsletter. It is weekly, it is free, and you will get tips, tricks, and tools delivered directly to your mailbox. I will recap the current week’s episode and all of the takeaways, I’ll give you a top story, content I wrote, and then some recommendations that I’ve been using that I think you should check out. So it is free, it is a weekly, it’s over at howibuilt.it/subscribe. Go ahead and sign up over at howibuilt.it/subscribe. Hey, everybody, and welcome to Episode 219 of How I Built It, the podcast that offers actionable tech tips for small business owners. That’s a relatively new tagline I’m trying. It used to be “the podcast that asks, ‘how did you build that?'” But we’re expanding beyond that and I’m really excited about that. First, before we get into it, I want to thank our sponsors: TextExpander, Restrict Content Pro, and The Events Calendar. You’ll be hearing about them later in the show. But first, I want to bring on Bet Hannon. Bet Hannon is the CEO of Bet Hannon Business Websites. We are going to be talking about their website accessibility sampling audit. In an earlier episode, I spoke to Amber Hinds about accessibility in general, their tool, the Accessibility Checker. Now we’re going to learn how an agency actually goes about doing an audit and helping their clients not get sued and have a more accessible website. So Bet, how are you today? Bet Hannon: I’m great. Glad to be here. Joe Casabona: Thanks for coming on the show. For those of you who are not Build Something Club members, bet and I had a fantastic pre-show conversation about craft beer. So if you are interested in that, you should become a Build Something Club member over at buildsomething.club. But for now, Bet, before we get into the nitty-gritty, why don’t you tell us a little bit about who you are and what you do. Bet Hannon: Great. So I run an agency that’s focused on WordPress. I got involved with WordPress in about 2008 after I had worked for 15 or so years in nonprofit management and doing some techie geeky things for the organizations that I served. But my position got downsized in that financial crisis and kind of stumbled into starting to do a little freelancing and then develop that into an agency. And have been loving it. I love problem-solving for people. Every project is like a little puzzle to solve. Joe Casabona: Yes, absolutely. That is what I also enjoyed about. When I was doing the full-time freelance website making thing, that was always my favorite part. I wrote a plugin recently, the first one in a while and I was like, “Man, I miss this.” So I’ll have to make it a habit of coding regularly. You lose it too. I guess it’s kind of like riding a bike. But men, things change. Bet Hannon: I know. I’m missing more. I’m doing more. I’m doing less and less of that myself, you know, as I’m running the agency. But it is nice to get in. What I miss is diving in and doing Gravity Forms customization. Joe Casabona: Nice, nice. Well, not nice that you miss it, but nice that you would do it. I always liked customizing Gravity Forms. So you got into WordPress in 2008. So this is your second recession, we’ll say. As we record this, there’s still a global pandemic. Bet Hannon: We actually have been doing okay. I was kind of worried for a bit. You know, a lot of folks really just figuring out they need websites or they need to revamp their websites, or they need to repurpose their websites. So we’ve been doing okay. Joe Casabona: That’s great. That’s interesting. I had a conversation with Brad Morrison back in May 2020 about that very thing. Like we were both kind of making websites in 2008, 2009. And I feel like whenever there is a recession, people realize they need to pivot or improve their online presence. I mean, especially true with this current one because…yeah. Bet Hannon: Right, right. Figuring out how to get information out there about when they’re going to be open or how they’re going to do curbside pickup or all of that stuff. I am kind of notoriously bad for giving unsolicited feedback about websites. So when I go to the local restaurant and I’ve looked up their thing, and I go, “Hey, your colors here are not accessible and this is terrible on mobile.” Joe Casabona: Man, I would do the same thing, where I’m like, “This should really be like that.” However, the PDF doesn’t download or whatever. Your website not…” Bet Hannon: Last week I went to the dentist. I paid the dentist bill from a couple months ago, but there’s no way to pay it online. I had to call and give them and do it over the phone. So when I went in, I said, “You should really not be taking those numbers over the phone. It’s easy to make a payment form. Call me.” Joe Casabona: Yeah, exactly. “Let me know.” I’m always incensed when you can’t pay for something online or whatever. So you have a WordPress agency now. Would you say that your main focus is accessibility or it’s just something you bake into every website? Bet Hannon: Well, it’s something we bake into every website. We got started with accessibility almost four years ago now. We had a client where we were doing administrative maintenance on their site and they are… they’re still our client. They were our a big agricultural Water District in California. And because of the way they’re connected to the state of California, they became aware that they were going to have some accessibility requirements. And they asked about what needed to happen. We said, “Oh, we could refer you to somebody.” And they said, “Well, we want to work with you. Let’s all learn this together.” Joe Casabona: Wow. Bet Hannon: So we dived in, and our entire team got trained and learned a lot about accessibility and worked through a lot of that with the client and just really got hooked. When you start diving into what makes the site accessible, but also the power of making the website available to more people and usable by more people and seeing how it really can impact people’s lives, whether they have a permanent disability or a temporary disability even, you know, to be able to use the sites. And so we just really got excited about that. Some of the best advice I got as an agency owner was never ever put accessibility in a proposal as something to be refused. That you should never put yourself in a position of allowing the client to throw people with disabilities under the bus in terms of bringing down the cost. That for me it’s staking our reputation as an agency on… everything we do has accessibility baked in. And I truly believe that accessibility is going to be what mobile responsive used to be five or 10 years ago. In another five to 10 years, everybody will be doing accessible websites and it’ll just be what every self-respecting developer does. So we’re just kind of on the early curve for that. Joe Casabona: I love that. When you said that it reminded me a lot of responsive web design. Because that was something that I felt I got in on early. I saw Ethan Marcotte talk about it super early. I put it in my proposal as like, “Do you want a responsive website?” And then I was like, “Why am I even asking? It’s just going to be part of it. It’ll be part of the cost. If they want to buy a cheap website from someone else, they can.” Bet Hannon: Yeah. And quite frankly, more often than not, when I talk to clients, and I say, “Look, this is part of what we do. We bake it into everyone. There are some legal requirements that you may or may not have. You need to do this,” and they’re like, “Oh, yeah, thanks. I hadn’t even thought about that yet.” So they’re usually grateful for having it or the topic being brought up. Joe Casabona: Absolutely. I mean, it’s our job right to advocate on behalf of our clients and inform them, right? When I go to a pizza shop, the pizza shop should expect that I know how to make the perfect pizza. I shouldn’t expect that they know how to make a website. Right? Bet Hannon: Well, it’s kind of what we do as freelancers and agencies. The client comes to us and they may say, “I want this one inch of website.” And we start looking at their… our job is to kind of take a consultative approach and to say, “If you added this on, this would really impact your business in a positive way. You can really grow your business by adding this thing on,” or “tell me about how you do the sales process. Oh, we can help automate that for you.” You know, so that you’re taking more of a consultative approach to helping people understand what they might need that they don’t yet know that they need. Sponsor: This episode is brought to you by Restrict Content Pro. If you need a fast, easy way to set up a membership site for yourself or your clients, look no further than the Restrict Content Pro WordPress plugin. Easily create premium content for members using your favorite payment gateway, manage members, send member-only emails, and more. You can create any number of subscription packages, including free levels and free trials. But that’s not all. Their extensive add-ons library allows you to do even more, like drip out content, connect with any number of CRMs and newsletter tools, including ConvertKit and Mailchimp and integrate with other WordPress plugins like bbPress. Since the Build Something Club rolled out earlier this year, you can bet it’s using Restrict Content Pro. And I have used all of the things mentioned here in this ad read. I have created free levels. I’ve created coupons. I use ConvertKit and I’m using it with bbPress for the forums. I’m a big fan of the team, and I know they do fantastic work. The plugin has worked extremely well for me and I was able to get memberships up and running very quickly. Right now, they are offering a rare discount for how I built it listeners only: 20% off your purchase when you use RCPHOWIBUILTIT at checkout. That’s RCPHOWIBUILTIT, all one word. If you want to learn more about Restrict Content Pro and start making money with your own membership site today, head on over to howibuilt.it/rcp. That’s howibuilt.it/rcp. Thanks to Restrict Content Pro for supporting the show. And now let’s get back to it. Joe Casabona: So you mentioned that your team got trained. What was that like? Is there a certification process for accessibility? Bet Hannon: Mm hmm. Joe Casabona: All right. I was going to add a second part of that question, but your face lit up. So go for it. How was it like? Bet Hannon: There are. They’re both. There’s some online journey. There’s a ton of training that you can do out there. So if you’re just starting out and you’re wanting to learn more about website accessibility, some free options for doing that are going to WordPress TV. And there have been a bunch of presentations at various WordCamps on some of the technical pieces for accessibility. I’ll just be the first to confess that I’m not the lead developer at our agency. So some of those kind of technical pieces are not where I would necessarily be helpful to people. But there are tons of presentations from WordCamps to start getting going. There are some LinkedIn Learning pieces. Joe Dolson, who’s an accessibility advocate within WordPress has a great LinkedIn Learning course on Accessibility and WordPress. Very helpful. And then we had our folks do Deque, D-E-Q-U-E, deque.com, they do services around accessibility, but they also have some learning pieces. You can buy basically a membership for a year to do their self-paced online learning pieces. So we have everybody in our group do their base level, which is just awareness about disabilities, and what different accommodations are. So just kind of educating our team about what those are. And then our lead developer has been doing more advanced pieces in preparation for taking a certification exam. So there’s the International Association of Accessibility Professionals. They actually have some certification pieces. Those are several levels, in fact. Those are kind of where our folks are going. So as you may or may not have guessed, one of the ways that you might you would test a website for accessibility might be to use yourself a screen reader. So screen readers are what people who have visual impairments might want to use, and it reads out loud things that are on the web page. We’ve done that, and our developers done that for a long time. But we became aware like, I don’t know, maybe like six months ago, sort of like, well, you can use these tools, but are you using them like a visually impaired user would use them? So I did a little networking and found the consultant and agency, that is the Oregon Federation for the Blind refers people to. So if I experienced blindness and I needed to get training, my state would send me to this guy to learn how to use a screen reader. And we sent her to do training with him, our lead developer. And that was amazing because we had known for sure, but sure enough, people who are blind or visually impaired use screen readers differently than maybe we had anticipated. And so that then helps us be better at testing what we’re doing and how we’re building things out. Joe Casabona: Wow, that’s really interesting. I’ll mention one more resource that I read. Because there’s a chapter in my book on accessibility. But I read “Accessibility for Everyone.” It’s a book by Sarah… Oh, my gosh. Her last name is escaping me right now. I’m very sorry, Sarah. Oh, no, it’s not even Sarah. It’s Laura Kalbag. Laura Kalbag. That’s right. Sorry. But the book is fantastic. I will link that and everything that Bet just mentioned in the show notes over at howibuilt.it/219. Your mention of using a screen reader is very interesting because for my book, there’s a video component where I tried using one in order to show my readers how to use it to test. And honestly, it’s just I had never used one before. So I don’t think it was the most effective demo. But that leads me to ask another question, which is there must be resources in general for testing accessibility with a target audience. Right? So for example, I have transcripts for this podcast. I suspect that there’s a way for those who… Forgive me, I don’t know that I… The proper terminology is escaping me but people who are deaf or have hearing impairments. Is that the right way to put it? Bet Hannon: Mm hmm, hard of hearing. Joe Casabona: Okay. Someone got upset with me for saying hard of hearing Bet Hannon: Well, all kinds of groups, there are a variety of takes on things. Hard of Hearing is what I do see often. Joe Casabona: Okay, cool. That’s what I thought too. Okay, cool. But in any case, I guess, are there resources for you to test accessibility features with those who are most likely to use them? Bet Hannon: Do you mean doing testing with disabled users? Joe Casabona: Yes. Bet Hannon: The actual disabled users? Joe Casabona: Yes, yes. Bet Hannon: Well, people with disabilities often are chronically underemployed, and so if you have a way that you want to do a lot of testing, you could certainly do some networking to find people who could help you with testing. I think you should never ever ask a disabled person to test for you without getting compensated. Joe Casabona: Of course. Bet Hannon: I mean, think that’s just rude. We have several folks that test for us and consult with us when we have questions. Sometimes you’re testing a site and it’s just really hard to get a sense for… you know, if you tagged into this in a certain way, it might get you into a trap that you couldn’t get out of. You know, what are the clues? And so, just kind of having people do some testing for us. So we have a few people that do that for us. Joe Casabona: Got you. Bet Hannon: But resources for finding those people, I don’t… I mean, that’s going to vary quite widely. Joe Casabona: Got you. But there are resources available if you do some networking, like you said, and ask around. Bet Hannon: Yeah. You know, I would ask around. I mean, there’s some state agencies in your state, probably. You could network around about where do they send people when they need training? And then those people who are doing training on those things may often do some consulting like that on the side. Joe Casabona: Awesome. That makes perfect sense. This has already been super informative. Now, you have a website accessibility sampling audit. In a previous episode, I think I mentioned this earlier, with Amber Hinds, we kind of talked about like the WCAG ratings and things like that, which is sort of an automated thing, right? You go to a website, you get a rating. If it’s double, great. If it’s triple, even better. But we still need a person auditing your website, right? Bet Hannon: Yeah, yeah. Right. There are a variety of tools that are out there, automated tools there where you can test your site. And wave.webaim.org is the one that Amber was probably talking about. That’s one of the best known. Lighthouse is another one. It’s a Chrome extension that you can put in in the specter tools and you can look at there. They’re great. Those automated tools are really good and important to us because they can help save you a lot of time. The important thing to remember about them is that they only catch about 30% of the accessibility issues. And you may get some false positives and false negatives. And you’ll always need humankind of… you’ll need to look at things with a human eye. Those testing tools are never going to be enough to say that you’re fully accessible. So, for instance, an AI tool can tell you “yes or no, there’s an alt tag for this image.” Yes is good, No is bad. But if the alt tag is the name of the file, jpg49678, that’s not compliant. So it can give you the false negative that you had all the alt tags are taken care of when they’re not really. So you want to make sure that you’re using those tools as they’re intended, to do some basic screening, but at the same time that you’re really looking at things. Even the tools that Amber and her team have put together are great but they really require you to engage. And that’s the thing with accessibility. There is really no just put a plugin on or just pay to make it go away. You really have to learn what’s accessible and what’s not and implement it regularly. Accessibility has some parts for WordPress, and that’s what we deal with almost always. For WordPress, some parts of accessibility are in the theme. So whether your menu is accessible or not is largely controlled by your theme, for example. Your color contrast of your buttons and your color contrast is set by your theme. But a huge piece of accessibility is your content. So when you’re putting in content, are you making sure that the images have alt tags? Are you making sure that the H tags and the headings are nested without skipping any levels? So a lot of that content piece is stuff that people are just going to have to learn and learn to implement correctly as they go. Joe Casabona: That’s a really important point. I think Amber made the same point, right? Because Accessibility Checker… I don’t know if you’ve used it. Bet Hannon: Oh, yeah. Joe Casabona: She gave me a pro version. That was an inaudible “oh, yeah.” But the education part is really important. When I look at my blog posts and I see the kind of score I get, it’s like, “Hey, you have two h2 tags in a row here and you skipped an h2 tag or whatever it is.” Because I always forget if the… maybe this is a question you can answer for me. The site title is an h1 in most themes, which means your blog post… Bet Hannon: No, the page title is the h1. Joe Casabona: The page title is the h1. Okay. Bet Hannon: Yeah, yeah. Joe Casabona: So if I’m looking at a blog post… gosh, I should know this, but I don’t right now. If you’re looking at a blog post, should the title of the blog post be an h1 or an h2? Bet Hannon: Well, the title of the post or the page will be the h1. And that should be taken care of in the theme. The theme should handle that for you. And then when you start putting in H tags for kind of organizing your content, you should start with h2s. And you can go you can skip from an h2 to an h2. You just can’t go from an h2 an h4. Joe Casabona: Right. Bet Hannon: I think people often don’t quite understand or get that you shouldn’t use the H tags to style font. Right? Joe Casabona: Right. Bet Hannon: An H4 four can have as big a font as the h3 or the whatever. But you’re kind of organizing the content. I sometimes say it’s like when you were in high school English, and you had to do that outline with the Roman numerals and the capitals and then the lowercase Roman numerals and lowercase letters, and you have to kind of build it out in that way. My team doesn’t like that because “who learns to do that in English class anymore?” is what they tell me. Then I feel old. Joe Casabona: Really? Hold on. We can talk about this in Build Something More because it’s a sidetrack. People don’t learn how to do that in English class anymore? I’m outraged. Bet Hannon: Ohhh, yes. Well, you graduated before No Child Left Behind really diminished education. Joe Casabona: Oh, gosh. Bet Hannon: My wife is a college professor and sometimes what people have not learned in high school is quite astounding. Joe Casabona: Ah, that saddens me. Bet Hannon: Yeah, it is. My team sometimes talks about it as nesting file folders. That’s a different example that you can talk about. Like the whole drawer is the h1 and then you can have h2s and then nested folders. But you have to make sure that you don’t skip any. Joe Casabona: That’s interesting. I’m going to bet like most of my blog posts are inaccessible because I guess it was just always like a mental block for me. I thought the site title was h1, the page titles h2. So I always started in on h3. Bet Hannon: Oh, okay. Yeah, yeah. Joe Casabona: I better go back and fix all those. I reckon that there’s like… Bet Hannon: A few at a time. And that’s the thing. When people realize that they’ve been doing something incorrectly… I mean, know better, do better. That’s the thing. When you know better you can do better. And so when you realize that you may have not done that correctly over time, it can seem insurmountable. I mean, it just seems like this overwhelming task, I mean, if you have hundreds or thousands of posts to deal with. So the key is start and do a little at a time. Just make a goal to do two of them a week or three a week. It doesn’t take very long once you figure out what you’ve done. And then just kind of make your way through them. There are some tools for doing that. There’s a couple of really great alt tag checker tools. So there’s a free one in the repository—and now I’m going to forget its name, but we can put it in the show notes—that basically when you install the plugin, it’ll show you all the images in your media library and just show you which ones are missing alt tags. Joe Casabona: Oh, great. Bet Hannon: But then you still need to go back and fix them. And then there’s a paid tool, and it costs like $200 a year. I don’t remember the name of it, either, we’ll get into the show notes… Sorry, guys. I know it’s two, guys. Well, one is written by my friend Andrew Wilder and his team, but the other one I don’t even know. But anyway, the paid tool is really nice because it pulls in all existing alt tags. It will use AI to try and generate an alt tag based on what’s there. You have you still have to go in and kind of like say, “Oh, that’s not quite right. Let me actually fill this out.” But it gives you that help, that start. And then when you fix it there using that plugin, it fixes it on every post that’s used that image. So if you have a lot of images, it’s probably worth getting that paid tools. Joe Casabona: Yeah, for sure. For 200 bucks saving you hours of work. That’s really interesting. Because as we’re talking about this, I thought I could probably make a plugin that loops through the content of all of my posts and just bump up the heading. I’d still need to check. Bet Hannon: Yeah. If you knew it, you could do that, I suppose. Joe Casabona: I’d have to make sure it doesn’t go above h2. So I’d have to say, “Is this an h3 change to an h2, or whatever.” It would have to be smarter than just looping. Bet Hannon: If you knew you were consistently making the error, right? Joe Casabona: Yes. For me personally, I’m confident I consistently make that error. You know why I’m confident? I write in Ulysses, which is a fantastic writing app. It’s markdown, and it exports directly to WordPress. And I always start with an h2 for the document title, and it bothers me, and then I do h3 for all subsequent headings. So I know for a fact. Bet Hannon: Oh, yeah, yeah, yeah. If you start fixing it, you could do that. You might be able to do that. I got into doing more database query stuff a couple of years ago. We had a really large site with a ton of stuff, and very active site. We were going to be doing a new theme for them. And there’s always that problem where you have the active site where there’s WooCommerce, or an active blog, or whatever, and then like, you’ve got to pull that back together. So I was experimenting with a plugin that purportedly was going to merge in the changes from the production site. And in the testing, it looked all great. But during the time we had it in development, it got stuck in some kind of a loop with Gravity Forms entries. And I had 15 million, with an M, additional extraneous entries. I just had to start learning how to write queries to get stuff out because it was so huge. I couldn’t even get it to load. Joe Casabona: Jeez. That’s horrifying. Bet Hannon: It was crazy. Joe Casabona: There was a plugin a few years back that I guess was not viable market wise. It was bought by Delicious Brains. Bet Hannon: By the time I was looking at this, they’d already pulled that off. Joe Casabona: Oh, man. Bet Hannon: This was another one. But it’s a difficult problem. It’s not an easy problem to solve. Anyway, I learned how to do a little bit of SQL. Joe Casabona: Very nice, very nice. We can talk about that in Build Something More because I have some fun stories. Sponsor: This episode is brought to you by TextExpander. In our fast-paced world, things change constantly, and errors in messaging often have significant consequences. With TextExpander, you can save time by converting any text you type into keyboard shortcut called a snippet. Say goodbye to repetitive text entry, spelling and message errors, and trying to remember the right thing to say. When you use TextExpander, you can say the right thing in just a few keystrokes. TextExpander lets you make new approved messaging available to every team member instantly with just a few keystrokes, ensuring your team remains consistent, current, and accurate. TextExpander can also be used in any platform, any app and anywhere you type. So take back your time and increase your productivity. But that’s not all it does. With its advanced snippets, you can create fill-ins, pop-up fields, and more. You can even use JavaScript or AppleScript. I can type out full instructions for my podcast editor, hi, Joel, in just a few keystrokes. Another one of my favorite and most used snippets is PPT. This will take whatever text I have on my keyboard and convert it to plain text. No more fighting formatting is I’m copying from Word or anyplace else. Last month I saved over two hours in typing alone. That doesn’t even take into the account the time I saved by not having to search for the right link, text, address, or number. You have no idea how many times I want to type out a link to a blog post or an affiliate link and I can’t remember it and then I have to go searching for it. That generally takes minutes. But since I have a TextExpander snippet, it takes seconds. TextExpander is available on Mac OS, Windows, Chrome, iPhone, and iPad. I’ve been using it a lot more on my iPhone lately because I’ve been working from my iPhone more because there are days when I’m just not in front of my computer right now. If you’ve been curious about trying TextExpander or simple automation in general, now is the time. Listeners can get 20% off their first year. Just visit textexpander.com/podcast and let them know that I sent you. Thanks so much to TextExpander for sponsoring the show. And now let’s get back to it. Joe Casabona: We haven’t even talked about the service yet, the website accessibility sampling audit. Tell us how that works, how you put it together, why you put it together, all that fun stuff. Bet Hannon: So you might want an accessibility audit of your site to help you know what things are wrong. Like you have been doing some of these things to try and fix things, but there may be still things that you are not sure are problems yet. And it is difficult with accessibility to know… It’s kind of like SEO—knowing where you’re kind of moving toward. It’s a moving target or that’s kind of fuzzy sometimes. So getting an audit is a great thing to do. Traditionally, an accessibility audit would look at every single page in detail and give you a detailed report of every single page of your website. And as you might imagine, that’s a labor-intensive thing because that’s a lot of work. So even if you have a moderate-sized site, it could run you into tens of thousands of dollars. And so what we discovered is that, by and large, if you have problems on with accessibility on your site, you can catch a lot of those with a sample of your content. So we developed an audit that was taking a sample of your content, and then you as the site owner can get this report. And then you have to extrapolate from there. If on your site audit we note that you have images without alt tags, you probably have a lot more than those then on the pages we looked at. So we try to work with folks to do around 25 URLs or so. Even sites that are really big blogs with thousands of posts, you really don’t need more than about three or four posts to do that. Unless you have a blog with a variety of authors. So we try to tell people, you know, try to get all of your page templates represented, try and get a good kind of representative sample of content through time. So like maybe if you start changing and doing better with your H tags now… but we’re only looking at those, we might not pick up that you still have that problem earlier. Joe Casabona: Got you. Bet Hannon: So we want to look at content creation through time. We want to get a variety of the authors on the blog. So maybe one person is continuing to do this one thing that is creating accessibility issues. Look at various features. If you’re doing a WooCommerce site or some other eCommerce site, you know, you want to look at the checkout process, you want to look at its membership site, looking at the process for doing that, and just try to work with them to come up with around 25 URLs to look at in terms of doing that. Joe Casabona: That’s right. And then we produce a big report. Often the reports are more than 15 pages. We actually give them a list of everything we looked for whether or not they violated it so they know what we checked for. We use those automated tools, but then we have human beings checking the page. And then if we run into something where we’re not sure about, we’ll call in our consultants and have people with actual disabilities looking at the content as well. And then we do include an hour of consultation time at the end. So then you can jump into a Zoom call, we can explain it to you, we can demo problems for you, show you why it’s a problem. Some people find that really helpful. If you want, you can bring your… we don’t need to do the remediation. But if you have a regular developer you work with, you can bring them on the call and we can make it more of a technical call about how they might need to fix that or what they might want to do to fix a problem. Joe Casabona: That’s great. That sounds a lot like when Gutenberg first rolled out I created a course, and I basically said like, “How to audit your website to see if it’s ready for Gutenberg.” Very similar. Page templates. I said just like, “Pick a sampling of old and new posts.” But content through time is a very nice, snappy way to put it. I know exactly what you’re saying and I think that’s great. Authors, various features, things like that. And then the one-hour consultation at the end. Patrick Garman came on the show a few weeks ago. They have in a WooCommerce performance site audit, also includes some consultation time. This was not a planned question or anything like that, but do you think that the audit has been a good addition to your business? Do you think it’s helped your business a lot? Because it seems like it’s an idea that’s catching on more, at least in the WordPress space. Bet Hannon: It is. I do think we have to be careful about taking on too many. It takes about two weeks start to finish and we only onboard one a week just because it represents a pretty good chunk of labor for us. And keeping up with our other projects is kind of priority in terms of paying the bills. But it is a good thing. Because most of an accessibility audit is done from the front end, we’re able to do audits on sites that are not WordPress. We can do a Shopify site or a Wix or Weebly site. But those folks don’t tend to want to do those kind of things. But you can do it on any kind of other platforms that someone might want to do. I think people are increasingly concerned. I’m seeing that more niche-driven. So for a bit, we had a ton of audits for food bloggers. So a pretty well-known food blogger got sued around accessibility, and it just raised that awareness for everybody that they… On the one hand, a good number of them are like, “I don’t want to get sued.” But what they also do know that it’s an important thing to do. They can increase their audience, it gives more people access to their content. So they definitely aren’t just anxious about being sued. And I want to be careful about not throwing around the fear-monger kind of thing. Joe Casabona: Right. Right. Bet Hannon: I mean, it is about not getting sued at one level, but it’s also that there are a lot of really great reasons to make your site accessible. Joe Casabona: Yeah, absolutely. I’ve said this on the show before. People ask me how I grew my show so quickly, and I think one of the big growth points in the show’s history is when I added transcripts. I saw a definite increase in traffic to the site and even an increase in listenership. Sometimes it’s not just the deaf and hard of hearing who want to read the transcript. It’s people who maybe can’t listen at that moment and or maybe they want to read along while they listen. Bet Hannon: I have seen statistics go by that say that 80% of the videos on LinkedIn are played without sound. Joe Casabona: Wow. Bet Hannon: 80%. It’s very high. It’s pretty high like that for Facebook, too. I think about that, well, one of the times when I’m surfing LinkedIn is in the early morning when I don’t want to wake somebody up, or when I’m in a waiting room somewhere, pre-COVID, or where I just can’t listen. But I sure watch videos go by and yeah, the captions. Joe Casabona: For sure. I mean, that’s super interesting. 80%. That’s wild. For me, it’s usually maybe I listened or watched something and I remember a phrase and I want to find that phrase. So even for those who do listen or watch with the sound on, the transcript or the captions, the searchable text is invaluable to a lot of people. Bet Hannon: Well, you’re getting the search engine juice from that too. Joe Casabona: Yeah, exactly. Bet Hannon: Right? Joe Casabona: Yeah. Bet Hannon: When you think about captions, you have to think about whether it is… if it’s a video, often you’re doing captions because the video is conveying something of the conversation or the interaction as well. But for a podcast, doing the transcript… Well, I often do listen to podcasts at time and a half or, you know, I bump it up. If you got a transcript for me to read, it’s much faster. I can read a lot faster than I can listen. Joe Casabona: Yeah, yeah, for sure. Awesome. Bet Hannon: So it’s not just situations where I might be time pressed and I just want to skim through stuff. Sponsor: This episode is brought to you by the Events Calendar, the original calendar for WordPress. This free plugin helps you with calendaring, ticketing, and more powerful tools to help you manage your events from start to finish. Whether you run school events, concert at a venue, or fundraisers for nonprofits, the Events Calendar gives you the tools you need to make it your own. And with the Events Calendar Pro, you can create custom views, recurring events, add your own custom fields to events, and much more. Run virtual events? No problem. With the Virtual Events add on you can quickly and easily manage your online-only or hybrid events. With deep Zoom integration, custom virtual event coding for search engine optimization, and the ability to embed video feeds directly on your website, the Events Calendar makes putting virtual and hybrid events together easier. And I can’t stress this one enough. Let me tell you, I have tried to roll my own webinar software, my own live stream event software, and it is difficult. And I have 20 years’ experience making websites. The Events Calendar is the tool that you need to make virtual events a lot easier. You can even sell tickets and only show the stream to ticket holders. If you run events, whether in-person or online, you need the Events Calendar. Head on over to howibuilt.it/events to learn more. That’s howibuilt.it/events to start running your events more efficiently today. Thanks so much to the Events Calendar for supporting the show. And now let’s get back to it. Joe Casabona: I know some well-known, big time podcasters who have kind of poo pooed transcripts because they don’t feel the added cost is worth it. And I’m just like, “First of all, you’re making more money than I am podcasting.” Even if you don’t use… Rev is expensive. My virtual assistant transcribes the videos I sent her so I know that she understands the task at hand, and she transcribed a 30-minute video in like three hours. Worth it. Worth it to pay her that. It’s cheaper than Rev. Bet Hannon: And there’s some other services that are up and coming too. And I think we will see more and more of those. Joe Casabona: I’ve been using otter.ai. Any place that offers an educational discount, I’ll grab it. Bet Hannon: I just heard about Otter today in another… I was in a meeting this morning and somebody mentioned that one. Joe Casabona: How funny. Bet Hannon: I hadn’t heard about it. Joe Casabona: What’s that called? That’s called something. You hear about it once and you hear about it everywhere. Bet Hannon: Synchronicity Joe Casabona: Oh, man. Bet Hannon: Oh, no. Joe Casabona: There’s something effect. I’ll look it up for the post-show. But anyway, we could talk tools all day. I mean, I guess that’s helpful, right? It’s an accessibility show. But otter.ai and Descript both offer educational discount, so if you have a .edu address, you can get it at like half price. So I’ll just snag those. I’ve been pretty happy with Otter. There’s a few things, but it’s AI, transcription. Bet Hannon: Right. And I don’t know if it kind of produces a transcript, but I do know that I’ve been seeing going around that Zoom is giving… For Zoom, they’re giving free on the fly too closed captioning for meetings. Joe Casabona: Yes. Bet Hannon: But if that gets saved in a file, that would be checked out. Joe Casabona: Yeah, absolutely. Bet Hannon: There’s a way to turn that on in your account. Even if it’s live transcription, stuff like that is often a little buggy. But at least you’ve got something to start with from there. Joe Casabona: Again, you can hire an editor to edit it or have your virtual assistant read through and just spellcheck. It’s probably easier for them. So yeah, absolutely. Gosh, this has been super great. As we wrap up, if somebody wants to get started, maybe they have a website, and they’re not sure if it’s accessible, what are some tips to get started? Bet Hannon: Well, the first would be don’t be tempted by what are called the overlay plugins. So it’s big business right now. Those overlay plugins have huge amounts of venture capital pouring in. So their ads are everywhere, and they want to suck you in with just “buy our service and everything will be taken care of.” And they don’t. So don’t get sucked in with that. And then just start educating yourself about what needs to be there. I’d say the very base kinds of pieces are the things that we’ve already talked about in this podcast. You know, your alt tags and you’re heading tags, and then just start trying to work your way through testing your site, getting your content squared away. But ask questions. There are tons of people out on Twitter and LinkedIn and other places that are, if you have a question, willing to look at that and give you some, you know, not free consulting, but point you in the direction of some resources. Joe Casabona: Awesome. That’s fantastic. And with alt tags—again, I think I brought this up on the show previously, but I do want to drive this point home—it should be as descriptive as reasonably possible. Is that kind of the way to put it? Bet Hannon: Right. Yeah. We have a blog post that should come out on our site in another couple of weeks about alt tags. We’re in process with it. But yeah, you want to make it descriptive of the image, but you never want to put in the word image or photo or graphic or anything like that, because the screen reader reads that out loud. The screen reader already tells someone that it’s an image. And so you would just say, you know, “Father and child playing on the beach on a sunny day.” You know. It shouldn’t be too horribly long but it should be… If it’s a photo of a person, it can say, “Photo of Joe Casabona, an incredibly good-looking Italian man.” Joe Casabona: Well, thank you. You’re making… Bet Hannon: You can embellish your own text. Joe Casabona: Yeah, there you go. People will probably picture like Fabio or something. Maybe Fabio is like old-timey reference and newer, good-looking Italian man. That’s interesting. So “father and daughter on beach on a sunny day” is good. But maybe like, father and daughter on beach sunny day with red pale and father’s wearing like green swim trunks. That’s too much. Bet Hannon: Too much detail. Too much detail. Right. Yeah. Well, the thing you don’t want to do is you don’t want to put anything in a meme-like image with text on the top. People do that a lot. They just go to Canva and they’ll make a little meme thing to promote an event or to promote whatever. The thing is, when you do that, you need to make sure that you’re providing alternatives for that. So you can do it but you just want to make sure that… For instance, we have clients where they’re doing a lot of events driven pieces. They might make that graphic, but then in the text of the post, they need to… so that the alt text on the graphic can say, “Graphic promoting this event, details in the post below.” And then the person can skip into the content and get the details. Joe Casabona: Yeah, details in the post below. That’s another thing that I think Amber mentioned. Go ahead. Bet Hannon: But the thing is, if you only put that little Canva image that’s kind of meme, like, Google can’t see that text either. So you’re not getting any search engine juice off of that. Joe Casabona: That’s really interesting. So you wouldn’t necessarily want to have that exact text in the alt tag if it’s also like the title of the post and mentioned in the post below. Is accurate that accurate? Bet Hannon: Right, right. It becomes repetitive. Joe Casabona: Okay. Cool, cool. Bet Hannon: And actually, people who are using screen readers, which the alt text is about people who are using screen readers, like the rest of us, they skim through content. When we all go to a website, we just skim through, and we’re looking at the headings, and we’re looking for what interests us. We’re not really reading every word. So people who are using screen readers are skimming through, and they’re skimming through to look at the headings, H tags, come back to play on the links. And you want to make sure your links are set up so that the link text, the part that gets underlined or made into a colorable or whatever that effect is, but that link text is descriptive because often they’re just skimming through the text and having the screen reader read out that text to them. So if all of your link texts say “click here,” “click here,” “click here,” there’s no context. They’re gone. Joe Casabona: Oh, jeez. Wow. All right. Lots of really good… Bet Hannon: So “click here to learn more about accessibility. Click here to do blah, blah, blah. Click here to download a blah, blah.” Joe Casabona: Yeah. Love that. Right. And then I guess the same with buttons. You don’t just want to say like, “Click here.” You want to say like, “Enroll today” is usually what I put. But maybe I put “enroll today in Podcast Liftoff” or whatever. Bet Hannon: Right. I mean, yes, potentially. And then you remembering that buttons are really just links. Joe Casabona: This will be the last question before we wrap up. We’ve been talking forever. Bet Hannon: [inaudible 00:51:51] Joe Casabona: I know. I know. It’s just such a great conversation. This is mostly for me, and I hope the listeners are getting something out of it. With anchor tags, you can add a title text, right? Bet Hannon: Mm hmm. Joe Casabona: What’s the utility of the title text? Can I say like, “Enroll in the clickable tags” and then have a title that has more context? Or is that kind of like frowned upon? Bet Hannon: Oh, you’re asking me more of a technical question now. I’m sure there’s an answer, but I don’t know. Joe Casabona: All right. I mean, that’s a good answer too because that means at least you weren’t presented with some hard opinion on it. I’ll find something… Bet Hannon: You gotta remember I’m very rarely any more in the content in that way. Joe Casabona: I’ll find the link for the show notes for that because that’s… Bet Hannon: Cool. Joe Casabona: Again, we didn’t talk about that. It just came to my brain and I wanted to ask. Bet Hannon: Yeah, for sure. Joe Casabona: Before we wrap up, you gave us some great tips, do you have any trade secrets for us? Bet Hannon: Oh, yeah. Just don’t get hooked into those overlay things. They are… I really try not to say this very often, but they’re really kind of evil. A, they purport to fix all your problems, but they can only deal with the 30% that’s AI. They kind of make it sound like you won’t get sued if you use them. But that’s not really the case. Actually, we’re seeing some cases where people are being targeted because they’re using them. And the predatory lawsuit people know that they can’t take care of everything. They’re hooking people in a way that just feels kind of manipulative and not very… just not a good heart behind that. Joe Casabona: It’s snake oil. Bet Hannon: It’s snake oil. It really is. And because it’s an overlay, so it’s fixing some of those accessibility problems on the fly as your page is loading, which is adds extra bloat, slows your site down, do those increasingly focusing on speed. So it’s not great for your search engine kind of results and all of that as well. And when you stopped paying for that service, all of those problems are still there. You haven’t fixed anything. You’re paying all that money to the service over time and nothing’s getting fixed. Joe Casabona: That’s really interesting. So these overlay products are not like, “Here’s what’s wrong.” It’s like, “Here’s what we’re telling you is wrong and we’re just going to add a little JavaScript to fix it or whatever.” Bet Hannon: It’s like, “We will try and fix the things we can fix.” So they’ll use AI to put in alt tags, which may or may not be correct. They’re just guessing at the alt tags. And then they put these little, they put some little tools over on the side. Well, if you are a person that has a tool, an accessibility tool that you use on the web, if you have a screen magnifier or you already use some kind of colorblind filter thing, you have tools that you already are familiar with that you have installed that you want to use. And so those little accessibility tools things, it’s kind of like, look at me, I’m trying to be accessible is what it comes down to. And for people with disabilities, it’s sort of like saying to them, “Hey, you should leave the tools that you like and all the shortcuts for to use my second rate thing that’s going to come…” Because those tools conflict them. They create a conflict. So you should leave the tools that you know, and like, and know all the shortcuts to and use my special tool over here that I paid minimal bucks for.” Joe Casabona: It’s almost like a virtual signal. Bet Hannon: It’s frustrating. It’s a virtue signal but it’s really… it’s like telling the person in the wheelchair, “You got steps in front of your restaurant, you need to go around and use the ramp and come to the kitchen.” Joe Casabona: Jeez. Bet Hannon: It’s really offensive. Joe Casabona: Absolutely. And it just goes to show you, right? Because… Bet Hannon: I get that people want to be concerned about accessibility, but take some time to think it through in. Joe Casabona: Yeah. I mean, be concerned and then find an actual solution and not some Band-Aid that you bought at the dollar store. Bet Hannon: Yeah, exactly. Exactly. Those services are not cheap either. And that’s the thing. Over time, you’re paying a lot of money, but it’s not really getting fixed. It’s just a kind of a cover-up that’s going to go away when you stop paying. Joe Casabona: Yeah, absolutely. It just goes to show you that the best way you can be accessible is to write good semantic HTML and know the best practices. That’s just… Bet Hannon: Yeah, exactly. Joe Casabona: Awesome. Bet Hannon: Know better and do better. Joe Casabona: Yeah, know better and do better. I love it. Bet, this has been such a great hour we’ve been talking for. We may talk about other stuff in Build Something More. So be sure to catch our pre-show where we talk about craft beer, our post-show where we talk a little bit more over a build something club. Bet, if people want to learn more about you, and they should, where can they go to find you? Bet Hannon: You can find me on Twitter @BetHannon, and then our website is bhmbizsites.com. Joe Casabona: Fantastic. I will link those and lots of stuff that we talked about. This is a tool-heavy episode. So it’s going to be long show notes over and howibuilt.it/219. Bet, thanks so much for joining us today. I really appreciate it. Bet Hannon: It’s been great. Thanks for having me. Joe Casabona: Thanks to everybody listening. I really appreciate it. Thanks to our sponsors, TextExpander, Restrict Content Pro, and the Events Calendar. Until next time, get out there and build something. Sponsored by:Restrict Content Pro: Launch your membership site TextExpander: Get 20% off your first year by visiting the this link. The Events Calendar Source

Ben Myers Some Antics Website Twitter GitHub LinkedIn Links Putting RedwoodJS Docs to the Test JAWS - Website NVDA - Website VoiceOver - Website axe DevTools axe-core axe-con GOV.UK Design System GOVUK-react Grommet Lighthouse accessibility scoring Lighthouse accessibility audits The Automated Accessibility Coverage Report Web Accessibility in Mind (WebAIM) Deque Systems The A11Y Project AnthonyBen Myers, welcome to the show. BenHowdy. Howdy. It's good to be here. AnthonyWhy don't you introduce yourself to our guests and let us know who you are and what you do?BenAbsolutely. My name is Ben. I've been doing web development full time for nearly three years now. I try to be a force in the community for accessibility advocacy. Web accessibility is a big passion of mine, I like to blog about it. Recently I've started a weekly Twitch stream where I bring on guests and they teach me something about web development, core web tech and/or accessibility. So if you've seen me around, that's likely why.AnthonyWe've gotten to know each other through the React Podcast Discord, we actually just talked with Chan yesterday. You have now spun off your Twitch channel, Some Antics, which I really like I think that's a really great name for an accessibility channel.I was really excited that you were doing it because we had already been talking about doing some sort of accessibility themed stream for RedwoodJS. We got to do that for Some Antics and I had a great time. I would love to hear a little bit about who your influences were in terms of creating it. I kind of have an idea, but I think our listeners would find it interesting.BenSo in terms of that stream, the main influence would be a Jason Lengstorf and his Learn with Jason show. For viewers, or I guess listeners who are unfamiliar, Learn with Jason is a twice weekly show where Jason brings on guests and they cover various aspects of the Jamstack. It's really great because you get to see just a wide variety of the web development world. It's such an open, inviting community, which I really appreciate.I've been trying to sort of, I don't want to say like, ape that whole thing. But, I've been inspired by that approach, bringing on people in the web development world. People who can show off interesting things that perhaps they don't always have the platform to do. And just teach me and teach the audience a new thing the web.I focus on core web technologies because. I think that's really foundational to the stuff that we do on a day in and day out basis. We have tons of frameworks. We have meta frameworks, I'm sure at some point we'll have meta meta frameworks, but at some point it all comes down to the building blocks. And I think the single most impactful thing I can do for web development is really focusing on getting absolutely solid with those building blocks.AnthonyI'd be really curious to hear, how did you first get it programming? Like what was the first kind of program you ever wrote or your first programming language or your first website? Anything like that? BenOkay. I have always been a computer guy. This goes back to even as an infant, as a toddler. One of my favorite like family stories that gets passed around every once in a while, is that my parents realized like, "Oh, Ben's probably been on the computer too much as of late and we need to wean them off of that." They turned the computer off and you know, this was in the day where all computers by default had towers and everything that people weren't really using laptops.They turn the computer off and they stuck a post-it note over the power button on the tower. If it said no little toddler me really wanted to use the computer. So he took the sticky note off, turned it upside down. So it said on stuck it back on, turn the power on and started using the computer. Just really and truly computers have been a big part of just me growing up. They were a big part of my childhood.I actually made my first website back in like 4th and 5th grade. I used one of those free website builders and it was atrocious. I do not look back on that site with the most kindness, perhaps, but it was my first site. I got to college and I had this idea that I was probably going to end up doing something technical, but I wasn't sure what that would be.I was undecided for my major, but I figured, you know what? I like computers. I'm going to play around with computer science as well as the business IT program that we had. Ultimately I ended up taking computer science and really enjoying that. That's kind of my journey to getting into programming, a childhood full of computers. AnthonyYeah, it definitely resonates with, I'm sure, me and Chris, same sort of situation growing up. We're really excited to have you here because something that I talked about when I was on your stream is that we're really focused on full stack development here, obviously this is FSJam, fullstack Jamstack. Part of what we really enjoy about that is that it allows solo developers to go really far by themselves with these tools. But what comes along with that is a responsibility, I see, of having a whole end to end understanding of the project.You need to know where hangups could be or where faults could be. Accessibility can be something that tends to get kind of shuffled around to different departments or different developers and there's not always the investment that can be made into having just an accessibility expert. I think it's really important for people who are working in these kinds of spaces to make sure that they are thinking of accessibility and that they have a mental model about accessibility and they have the tools they need to make accessible websites.For me, I think of it in those two kind of buckets, I think of the mental model. Of how do you think about whether your site or your app is actually accessible and then the tools you use to test and to verify, and to improve the accessibility of that site. So do you think that's a good framing and then which one would you like to kind of go into from there?BenYeah, I think that's a fantastic framing. You really do have to consider both the actual accessible experience and the process that you're going to take to get there. I would give the caution that in my experience, accessibility tends to fall apart not so much in the technical execution but in the process. Inaccessible sites are the product of processes that don't facilitate accessibility. AnthonyGreat and can we go into that? What are the processes that are failing us and how should they be altered? BenThis is largely going to depend a whole lot on the context of the work that you do. My experience is in enterprise. I'm able to take advantage of the teams that we have. I work with a design team and that design team is going to share some of the responsibilities. They are going to have to pick color palettes that are accessible. They're going to have to pick accessible typography.Business takes some ownership. As a product owner you need to be including accessibility requirements in your acceptance criteria. To consider a story done, accessibility requirements have to be documented and met. You need testing. You may have a centralized accessibility team. You may have quality assurance engineers who work with the team directly.Developers, and this is increasingly likely in a full-stack world, might be responsible for that testing yourself, but all of these roles have to be met. It's not just, it's about developing the accessible site. It's about designing the accessible site. It's about encoding those accessibility requirements into the agile workflow or into the requirements themselves for the stories.It's about the testing. It's about all of these things. There's so many different parts of this picture. If you're living that full stack, JAMstack dream of being the lone developer that can build the site. That also means that you're taking on every piece of that puzzle as well. Which can be a challenge for sure.ChrisOne of the things, things that I always like to think of when it comes to accessibility is a spectrum. It's not just binary. Some people are colorblind. When you put a warning sticker and a success sticker, they may look exactly the same to some people or another instant is mouth support. Could be limited when they prefer to use a keyboard.So could you tab down the entire page, you know, to the section you need. As I see it, yes, we could all always be better accessibility, but it's not necessary. Like how do I complete accessibility? How do I take it off? It's more, what am I doing to try my best? I believe if you're trying to even just do something is better than nothing.BenI think there's a lot of truth to that. And I think there's a lot of truth to, as you're kind of talking about this spectrum of ability. When you're first coming to learn accessibility, and the importance of accessibility, you'll often find resources that break down disabilities into several categories. Those categories, for instance, might be vision impairments, like blindness, low vision, colorblindness, etc. There might be hearing impairments I'm for instance, hard of hearing. So I need to leverage captions and transcripts quite often, or they assist in my comprehension.There's motor disabilities, live loss and paralysis. There's cognitive disabilities as well, learning disabilities and dyslexia and, and stuff like that. The thing about those categorizations as well, I think they can be helpful for developers to step outside of their bubble step outside of their comfort zone. And imagine what navigating the web, what that experience might be like for people with disabilities. I think it risks. Turning disability into a bit of a monolith into saying these are the properties that disabled people have.These are the experiences that they have, and that's just simply not true. Two people with the same disability will experience a very differently based on their life circumstances. In fact, many disabled people have multiple disabilities. This is kind of a recurring joke. I see in the disability community that if you have one disability, you've actually have three disabilities, cause things are comorbid and they build on top of each other.While disability is not one concrete experience, breaking it down into those categories of visual, auditory, cognitive motor can be a helpful way to start approaching experiences. We start breaking things down in terms of how might someone with those experiences navigate the page. Do y'all mind if I go through a quick exercise with you?AnthonyLet's do it, yeah.BenAll right. Y'all have seen forums before. I'm pretty confident you've seen forms before. Um, and sometimes those forms are prone to having placeholders. If you're unfamiliar with the placeholder, that's the little grayed out text that exists inside of an empty form field. And once you start typing in that form field, the placeholder text goes away. Based on kind of the like categories of disabilities, the visual auditory, cognitive motor, what are some possible access issues you might, uh, think of with a placeholder. ChrisYou could on the placeholder put a pattern. It needs to be two letters. Space, two letters space, two lies like a sort code. And then obviously you don't copy the same structure, error, but that's one of them. I'm actually going to say my favorite Google's accessibility, placeholder label. They are all awful where the place holder becomes the label. When you start typing, I hate them. Please everybody stop doing them.BenThere are tons of things to side eye about that. But even if we're just talking about like the native placeholder, right? Like we're, we're talking like Symantec input element with type equals text and we're using the placeholder attributes. What are some possible access issues that we might get from that? AnthonyAn issue is as soon as you start typing and you lose the placeholder, then if you don't remember what it says, you like get lost. So I know people who have like, Attention disability type. That could be a problem.BenAbsolutely, or people with short term memory loss. We're providing a key context about the page and how we expect you to do it and then we take it away from you the moment you start doing anything with it. If you have short-term memory loss, if you have attention disorders, if you have really any cognitive disability that makes complex experiences difficult for you to understand, placeholders are an access problem there. We could also talk about the vision aspect of it. Placeholders usually appear in a very light gray, which means they're nightmarish for color contrast. AnthonyI'd like to get into this. You had mentioned something I wanted to drill in on. You talked about designing for accessibility before even developing. And I think this is kind of some of the things that we're talking about right now is. The types of considerations you can make before a single line of code is written. And so what are some of those considerations you can make? And how can we design for accessibility before we even start coding? BenWhen we work in the web we usually talk about making things accessible for people with vision disabilities, because much of the web is inherently visual in nature. I would also add that the kind of like second highest group that you need to consider is anyone who needs to navigate the page using the keyboard. We often make this assumption that our users have similar experiences and capabilities as we do, but the truth is you are not your user.As you're considering accessibility from a design perspective before any code is written. You do need to consider, Hey, these colors, do they have sufficient contrast? That's super important. You also need to consider is color. The only way we're indicating information. If we're showing a graph, if part of our experience data visualization, and we have a couple of lines and one of those lines is blue and another is green, and this is our big, important data.What if someone's colorblind or to tie it back to work that I do on a day-to-day basis, foreign validation often requires, uh, we, we show, Hey, you filled this out correctly with green and you filled this out incorrectly with red. Well, for someone who has red, green colorblind, those colors are likely the same color to them, or very similar. Right? So making sure that color isn't the only indicator of information is hugely important. Also keyboard behavior, focus management is absolutely.One of the things that I think it's forgotten about is if you're opening modals and sidebars and dialogues, where should the focus go? Where should we put the users' cursor so that their screen reader announces where they're at and where should it go when you close that experience? And all of these things need to be decided before you ever write a line of code. And ideally if you're in an organization that has the design team to support it, Ideally that should be the design team that's documenting those requirements.ChrisI've heard the iPhone is very good at accessibility. iOS is done by Apple. Where does the most impact come in accessibility: from an OS and then an app or from the app and then the OS? Does picking a browser matter more in terms of accessibility than the website?BenThat's a fantastic question. And the answer is specs are great. I love specs. So the truth is your operating system, your browser, and your website all work in concert and they all have different specs that they're trying to meet. Your browser packages up your page, your DOM, into an alternate version of the page called the accessibility tree. It's an alternate version of the DOM and it exposes us to the operating system in such a way that strangers can pull from and figure out like what's the state of the current application.But browsers are limited by the language that the operating system uses, the primitives that the operating system provides. So if operating system, doesn't say that like, Hey, buttons are an element that can exist. Then the browser is limited by that. So browsers and operating systems have to work together, but browser just have to work together with your page for browsers to put together a meaningful representation of your page for assistive technology, you as the developer have to make sure that your page is descriptive meaning semantic markup.So this is just one way, like you have to write a meaningful page so that your browser can translate it in a way that's meaningful for assistive technology and all of these three things work together that work together with specs. I would say that as far as we're concerned, while all three of these things work in concert, it is the site that's going to have the most effect your browser can't fix a broken site. Your operating system, can't fix a broken site. The only thing that can fix a broken site is the developer.Additionally browsers and operating systems there they're usually adhering to specs that are put together by the worldwide web consortium, uh, specifically the web accessibility initiative team there they're conforming to those specs pretty well, decently consistently. So there is variation there, but you're not going to see nearly as much impact in that regard as you are from just. Building a strong site.ChrisIt's that question of how much you can control. You can control to support our year 11 or not. And you can control to support accessibility or not just things that you need accessibility no matter if you have any disabilities or not. For the prime example. As you age, you start relying on things like bigger text. How many websites do you know that have bigger text options by default? I think that's a really rabble as like built into the website.I'm dyslexic myself. For so much of my life, I thought dyslexia was at disability, but now I view as a  and I removed the dis and keeping the ability. It really changes how you can see and your mind works differently. And that's why I always think about accessibility as this. Bonus instead of this thing that takes away, because like we say, with good accessibility, you get to properly, fully navigate a website using your keyboard, small things like that is things that you only get when you view the abilities from disabilities.BenI think there's also something to be said for the web by default is pretty accessible. If you're using semantic elements you're a large chunk of the way there. This means that inaccessibility is often the product of the process, breaking things. Developers implemented the site in a way that broke the native accessibility or designers designed a site that out of the box was not accessible, etc.I really, truly believe that accessibility is good design, no qualifiers there. Accessibility is good design. It does help everyone, right? Everyone benefits from a more accessible site. Chris, what you're referring to is an effect that in the disability community, we call the curb cut effect. Back in, I want to say it was the sixties, the city of Berkeley decided to implement curb cuts. This was through the efforts of several quadriplegic, Berkeley students who pushed for a more accessible path through the downtown Berkeley.The city implemented these curb cuts, Chris, I believe they're called pram cuts or pram ramps on the other side of the pond. But it's where the sidewalk slopes down into the road, into the intersection. Basically this would allow wheelchair users to not have to hop the curb every time they wanted to get into the road to cross the road and not have to hop over the curb every time they wanted to get back on the sidewalk.What Berkeley found over the next few years was that these curb cuts weren't only being used by wheelchair users. They were also being used by parents with strollers and people with luggage, people with like straight carts, just bring stuff along. Like many people were able to benefit from this. A modern day example of curb cuts might be closed captioning. So I mentioned I'm hard of hearing.I often use captions as a way to just help my comprehension, even when I can technically hear the thing. It just helps to have that additional aid. However, closed captions can also benefit people with auditory processing disorders or people for who that language is not their first language or people who are in loud environments, such as bars, where you wouldn't be able to hear the TV anyway. Accessibility really does benefit everyone.However, I think my caveat there is if we lean too heavily in the accessibility is for everyone aspect, we de-center disabled people. And that gets really uncomfortable. Like at its heart, accessibility is advocating for disabled users. If we de-center their experience then it often becomes about developer preferences and in many ways about developer egos. At the heart of accessibility has to be disabled people.ChrisI wish I could have closed captions for real life. My girlfriend tries to talk to me, but if there's a washing machines going, I can hear what she's saying, but I can't comprehend what she said. It's just like, I can't explain it. It's so weird. BenThe single biggest use case, for me, for closed captions has been watching Dr. Who. Love Peter Capaldi but his accent was difficult for me to comprehend. It was a very, very strong accent. And yet I need my British Sci-fi, you know? AnthonyWe've talked about how to think about designing an accessible website, considerations, like semantic markup, color contrast, being able to tab through a page, being aware of different types of disabilities and the different challenges they will each encounter. Now we have a site that we've done our best to design. Once we're actually implementing it, what are some of the tools, the tips, the techniques that we can use to verify and test that it is accessible?BenI think one of the easiest for people to wrap their head around is keyboard navigation. I think many developers, I'm not going to make this like a universal statement, but I think many developers would consider themselves power users of technology. And therefore many of us likely already use keyboard navigation to quickly hop through a form and stuff like that. This is something that's already pretty familiar to us.It's also pretty clear when something doesn't behave as intended, right? When the focus order hops around or when something we expect to be focusable or keyboard navigable isn't focusable or keyboard navigable. Keyboard navigation is one of those things that I think for many of us will come pretty familiarly and is something that I think can provide immense accessibility testing value.The next thing I'm going to suggest is getting really good with screen readers. This is something that can seem pretty daunting, but the truth is when disabled users use assistive technology, by necessity they become power users of their assistive technology. They have to, that's how they navigate the world. You have to get good at it. As developers who are committed to meeting accessibility needs and committed to meeting the needs of people with a wide variety, with a wide array of experiences, we have to test for those experiences.So get familiar with screen readers. If you're on Windows, the screen reader that you're going to want to look into is JAWS, which is a paid screen reader. It's quite expensive, that's the most commonly used streaming, There's NVDA, which is free and I believe open source. If you're on Mac there's VoiceOver, which is built into the operating system. There are screenwriters for mobile operating systems as well. You can find those with a quick Google search.But by and large screen readers are going to have several navigation modes. Tabbing. The focus that you're used to, focus implies interactivity. If you can tab to something that implies that it's interactive, so you should be able to tab to, for instance, links, buttons, and foreign fields. If you can tab to something and it's not keyboard interactive, that is a wrong experience.Most of the time when you're tabbing, you're looking for keyboard interactive elements. The next screen reader, navigation mode is the virtual cursor. This is usually the, "just read everything" mode. So if you want to skim through all the static texts and the images and stuff like that, you're going to want to find whatever your screen readers virtual cursor is.And the next thing is that screen readers, and this is something that I think a lot of developers don't actually really know about screen readers, most stream readers come with a way to hop between different elements of the same type. For JAWS it's a plethora of keyboard shortcuts, with Mac it's VoiceOver. It's a tool called the rotor. If you can't see the page, then you can't just scroll down the page and quickly skim through it. Screen readers provide whether it's the rotor or the keyboard shortcuts. They provide ways to skip through parts on the page to get to the parts that you care about really quickly.That can often be very unintuitive. Like, we as sighted people, the three of us on this call, we might go, well, who would ever want to skip through a page by going from link to link? But many people do so this is a mode that screen readers provide. So figure out what your equipment for the reader that you're testing with and use that. There are also automated tools. You can run scans. One of the biggest ones is a Chrome extension called axe DevTools. This will scan through your page and automatically figure out some of the defects.There are limits to automation, and I think we'll get to those in due time, I suspect. But there are a plethora of tools to use and I think you have to use all of them in concert. You have to test the keyboard navigability, you have to test the screen reader experience. You can run the automated tests, etc, but I think you have to do all of the above to really, truly get a holistic understanding of the experience. ChrisWhat's your opinion on tools, like UserWay where it's like a SAS product to do accessibility for you? Is that a definitely no or is that just like a bandaid on the issue?BenI have to be very careful about this. You're talking about tools called accessibility overlays for listeners who might not be familiar. You might go to a site and sometimes see in the bottom left corner there's a little accessibility symbol. You can click that and it opens up a panel that provides several accessibility features. Like, hey, we can update your color scheme, or we can make your texts large, stuff like that. Or we can read your page aloud.The way I will word this is, Accessibility experts do not trust accessibility overlays. The truth is many of them do not do anything that the user would and already have the assistive technology to do, right? Like they're simulating a screen reader, but a simulated stream reader is not going to be anywhere near as good as the screen reader you actually use on a day to day basis. Additionally, it's been demonstrated that several of them actually commit accessibly errors themselves.They have poor focus behavior and stuff like that. Really and truly, what you're looking at there is a field that realized that lawsuits were going to get more and more common and they started getting venture capital checks their way. I don't believe that they provide anywhere near the support for accessibility that just fixing your dang site would do. And I don't believe that they ever can.ChrisIt's interesting. If there's anything I'm proud about being British is our government websites. The UK government has that UI totally open on GitHub. I hear for accessibility it is really, really good. It's called like govuk-react. I think it is. But that's supposedly like really good for accessibility as that was one then main goals as like, how do you fully make something that everybody needs to use? Because to give the backstory that I do know before.GOV.UK standardized that interfaces. Every single government agency had that own website, own forms, own styles, own system. All of it never spoke the same style or language. They decided to start an initiative where every government agency would use the same UI library, same user interface patterns. As a user, it doesn't visually look amazing, but for accessibility of a government website is next to none. Every time I use it. It's great.For example, in the UK right now, we have a thing called a census. So that's every single house old in the country. You have to go onto the centers and say like, there's two people living in this house and this is what we do. So the government can allocate spending and voting rights and all them things, every single person in the UK has to do it. It's a really interesting thing to look up about the gov UK and how they achieved. I believe a very good accessibility record. Well, I'm not the answer about that. BenI've heard fantastic things about the GOV.UK design system, and I'm incredibly excited to see more and more design systems that come out with accessibility baked in as much as possible. For me, the first one that flew onto my radar was a design system called grommet. I guess it's more of a component library than anything, but I think design systems and/or component libraries are a powerful tool.They can standardize accessibility practices across a product and across an enterprise. I would encourage you, if you're working in the design space in your company, if you're working in part of a larger enterprise, to see how your design system can leverage accessibility and codify that into best practices there. I think oftentimes with design systems, you still have to do your own testing.I think this is one of the recurring things I learned from accessibility. You can have tools that improve the developer ergonomics and handle a lot of stuff right out of the box. But accessibility is so contextual that you have to still test it yourself. You have to still make sure it works for everyone in the context of your own application. Yes, look for tools that are doing accessibility well. Look at tools that make it really easy to be successful at accessibility, and then still test it because every app is going to be different.AnthonyDo you ever use the accessibility score from lighthouse? Because lighthouse gives you a whole bunch of metrics for like performance, SEO, and one of them is accessibility. I've always wondered about that metric and what goes into it and if it's useful to optimize around or not.I once saw that we had deployed a Redwood to Netlify and Vercel, it was the exact same app deployed from the exact same code base and each deployed project got a different accessibility scores. I thought that was really interesting. The whole lighthouse thing is kind of a black box to me. I didn't really know how to drill into that, so I'm curious if you know anything about that. BenThe specific stats that lighthouse looks for you can read about at web.dev. I want to say lighthouse is behind the scenes using the same engine that powers the axe DevTools extension. Maybe with some more Google-y opinions in there, but I don't know what specifically might've caused your discrepancies that you were seeing there. But I think tools like that are incredibly powerful. I'm very passionate about accessibility, but the truth is I don't think every developer can or will be an accessibility expert.I would hope that would be part of the expectation, but the truth is there are so many things on our plate. So many things can slip under the radar. One of the really important things is figuring out how to surface accessibility issues that might be lying latent in our app. I think automation fills a very powerful role. Deque system the company puts together the axe DevTools extension. They have just wrapped up their axe-con, which is an accessibility conference. I was fortunate enough to attend a talk by Glenda Sims about axe DevTools and the role automation plays in accessibility testing.One of the things I was really surprised to learn was of all 2000 audits that Deque performed 57% of defects are surfaced by automation. And the bulk of these are going to be things that you can pretty easily calculate with a machine, right? 30% of all defects were color contrast issues, according to this report. And I can put the report in the show notes for y'all cause it's good stuff, but yeah, 57% of the issues surfaced in these audits were specifically surfaced by automation.Because computers are really good at checking a whole bunch of simple rules really quickly. For instance, does all of your texts meet color, contrast requirements? That is something that to test that manually would be a waste of your developer or testers time. I'm really good at checking. Do all images have an alt attribute, but something that computers can do really quickly, it would be a waste of your testers time. You want accessibility engineers thinking about higher order problems. Like. Complex interactions.I do want to talk about the limitations, though, of automation in this regard. We might be asking ourselves, well, why only 57%? Why can't the tools find 100%? Why can't they find 90%? Like why 57%? And the truth is, again, accessibility is very contextual. It's easy for a computer to say, "yes," this image has alt text. What's difficult is deciding whether that alt text is meaningful or helpful. And that's a very contextual thing. The same image might have different texts depending on what page it's on.We could have, for instance, the example of George Washington's presidential portrait. The painting that was made of George Washington when he took office. On different pages the alt text for that might be different on some pages. It might just simply be president George Washington. It's simple as that. Totally fine. On a biography of George Washington, we might actually interpret that picture as decorative. It doesn't actually add anything, we're already talking about George Washington.You don't really need to know that there even is a picture of George Washington. It might be all you have is the empty string, which causes screen readers to ignore that image altogether. Or if the presidential portrait is showing up on an art blog that's talking about the different painting styles, maybe you don't necessarily need to describe what George Washington looks like, but you do need to describe the brush strokes.It's very contextual and something that machines are never really going to be able to solve. As ever, you really need to combine automated testing with manual testing, but in such a way that the automated testing handles all of the like low level, easily calculable binary pass-fail stuff so that your accessibly engineers can focus on solving the bigger, harder, more contextual problems.AnthonyAs we're getting close to the end of our time, are there any last big ideas, things that you think we haven't covered that is really important for developers to keep in mind?BenAccessibly is important and there often times aren't one right answer. Again, make sure you're centering disabled people's experience in your advocacy of accessibility. There's a lot to it, but there are tons of resources out there. I'll make sure that some get added to the show notes, look for resources like web.dev or Deque systems or the a11y project. That's a 1 1 Y project. These are developers who are in this space day in, day out who have done testing and have just a wealth of expertise and a willingness to hop in and help solve problems.Remember that when we're building experiences, when we're building interfaces, that's our job. Our job is building an interface that users can use. The HTML, the CSS, JavaScript, the frameworks, the meta-frameworks, the Redwood, all of that is incidental. It's how we work, it's not what we do. What we do is we make usable interfaces. Take some time to figure out what you can you do today to make your experience just a bit more usable and then what can you do going forward. How can you adjust your process to continue baking accessibility into your app? AnthonyThanks so much, Ben. I've really enjoyed getting to pick your brain in this episode, but also over the many months that we've gotten to know each other. I highly, highly encouraged people to check out both your streaming show and also your blog. You're one of these developers out there putting out this really fantastic accessibility content that I think people should know about. Why don't you also make sure that people know where they can find your stuff and how they can get in contact with you? BenSo, first of all, you should follow me on Twitter @bendmyers. You can also find me on my blog at benmyers.dev where I post mostly about accessibility stuff. And then finally, every Tuesday on Twitch at twitch.tv/someanticsdev where we will be sharing, just learning, following along with core web technologies, as well as with accessibility. It's been a great time and I would love to see y'all there.ChrisMy final question is simple. Yes or no, can beautiful websites still be accessible?BenYes.ChrisThere you go. Simple. BenI think there's something to be said for emotional appeal as a key part of accessibility. I would argue that in many cases, beautiful sites are more accessible.

We fact check many moons and remember Dr Charles Geschke. We follow up on 5K iMacs, international keyboards and Apple's Oscar nominations. In the news gender neutral Siri voices, LG, Apple Amazon home automation alliance, and Swift Collections. We cover the Apple Spring Forward event; Apple Card Family, podcast subscriptions, AirTags, color iMac M1, and iPad Pro M1. Picks: Air Tag accessories, Kennsington StudioDock iPad Docking Station, Subs.

In this video, I’m joined by Preety Kumar of Deque to take a look at their DevTools plugin for axe. Short story: this is an amazing plugin that helps you quickly find accessibility problems on any website, then helps …

Y con ustedes un vicio más del lenguaje: ¿qué de qué, o qué?

Y con ustedes un vicio más del lenguaje: ¿qué de qué, o qué?

Hoc nono acroamate incredibilem feminam vobis ostendo quae nata saeculo secundo p.C.n universos christianos non solum mirabili suae vitae et mortis exemplo verum etiam scripto carissimo illustravit. Auscultate et cognoscite Divam Vibiam Perpetuam, invictam Christi martyrem.

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

El Impostor: En este nuevo episodio de color, Goris y Fernande analizan la teoría Gervasiana de tipos ideales humanos. El impostor, como uno de los tipos ideales menos reconocidos, se analiza en... Visita RadioNegra ~ nuevos episodios en www.negraradio.blogspot.com !

El Amor por los Objetos:  En un nuevo episodio se debate la relación amorosa entre los humanos y los objetos que los circundan. La llegada de un pedal de efectos a la vida de Goris cuestiona si... Visita RadioNegra ~ nuevos episodios en www.negraradio.blogspot.com !

Pesimismo y Optimismo En este primer reencuentro con la Filosofia de Color, el típico nos lleva a analizar la incesante dicotomía que existe entre el optimismo y el pesimismo. La humanidad entera se... Visita RadioNegra ~ nuevos episodios en www.negraradio.blogspot.com !

Hola, gente linda de Español sin fronteras. El día de hoy, hablaremos de fenómenos lingüísticos como dequeísmo, queísmo y lambdacismo.

durée : 00:03:02 - Une femme en Auvergne France Bleu Pays d'Auvergne

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

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

Audīre hoc epīsodium licet apud https://youtube.com/LegioXIIIListen to this episode at https://youtube.com/LegioXIII Cavēte! Hoc episodium nōn diūtius in legioxiii.podomatic.com sed apud hunc nexum in Tubulō (YouTube) locātur: https://youtu.be/0F1ddgY73jo  De Alexandri Veronensis Carminibus Latinis Per Se Illustratis loquuntur Iulus et Lucius, atque etiam de L. Voreno & T. Pullone qui in Caesaris De Bello Gallico V.44 narrantur. Alexandri carmina: http://www.carminalatinaperseillustrata.com Alexandri podcast: http://sermonesraedarii.podomatic.com http://youtube.com/ScorpioMartianus  http://youtube.com/DivusMagisterCraft  http://legioxiii.podomatic.com

Kris Van Houten: @krivaten | krivaten.com | Q2 Show Notes: 00:55 - Kris' Interest and Passion for Accessibility 06:07 - Using Ember for Accessibility: Pattern Adoption 10:13 - Context Switch Awareness and Managing Focus 12:08 - Asynchrony and Desired Interaction 14:04 - Building a Form Input Component 19:05 - Things That Are Hard to Catch 22:41 - Assistive Browsers? 28:17 - Making Things Accessible From the Start Resources: Building for Accessibility by Nathan Hammond @ Wicked Good Ember 2015 The A11y Project: Web Accessibility Checklist WCAG 2.0 checklists Why Don't Screen Readers Always Read What's on the Screen? Part 1: Punctuation and Typographic Symbols Mozilla Accessibility Kris' Blog Post Series on Accessibility: Part 1: What is accessibility and why should we care? Part 2: A Primer on Accessibility Part 3: Getting Our Apps Ready for Accessibility Part 4: Building an Accessible Icon Component in Ember Part 5: Building an Accessible Input Component in Ember Part 6: Building an Accessible Alert Component in Ember Part 7: Building an Accessible Numbers Component in Ember Part 8: Building an Accessible Currency Component in Ember Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil. WIL: Hello. CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We're going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general? KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it. Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?" I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let's just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code. CHARLES: Right, it's the path of least resistance. Everybody's got a job to do. Everybody's got features to deliver so that practice can be very easily self-perpetuating, right? KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That's where I was a little over a year ago basically. When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important." I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work. But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He's able to totally transform how's individuals able to use the app. For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It's for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this. CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It's not just a thin layer but your HTML is actually part of the UI. KRIS: Exactly, yeah. CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility? KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page. What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically. CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me? KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it. CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard. WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode. CHARLES: Right. KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That's what we're working on and talking a lot about at Q2 is basically this pattern adoption. CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say? KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that. CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them? KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users. One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening. I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That's one of the key areas that I think of. CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality." KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It's hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment. CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work? KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application. CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible. KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up? What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it." We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way. CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check? KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you. To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now. CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset." KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there. CHARLES: Yeah. We've talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing? KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That's one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit. One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously. That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It's not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented. CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not. For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They're going to be using Safari. They're going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things. I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points. KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It's not how it's treating the content. That's again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There's still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity. One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There's a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements." One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day. CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way. KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface. CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone -- KRIS: For sure. CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites. KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how. [Laughter] CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that. KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years. CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have? KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those. Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things. To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just A11yProject.com and read through the content there. It's very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation. On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It's a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML. I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements. I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started. Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There's a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well. CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include. KRIS: Awesome. Thanks. CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.

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.