- [Stefani] Welcome, everyone. We'll get started shortly. Just waiting for everyone to join in. Thanks for joining, everybody. We'll get started in about one minute. Just letting everyone join in. Actually shorter than one minute. It's just the top of the hour now. Good morning, good afternoon. My name's Stefani Cuschnir. I'm a part of the business development team here at TPGi. Thank you for joining us today for "Shifting Further Left: Integrating Accessibility Into the Earliest Stages Of Development" with David Swallow. I'm gonna let David introduce himself, but first, I have a few housekeeping items I'd like to just go over. Remind everyone this session is being recorded, and we will email everyone the recording after the event. We also have captions available, so feel free to use them as needed. There will be time at the end of the presentation for live Q and A. Please use the Q and A box. We'll answer the questions, as many of the questions as we can at the end of the presentation. If we run out of time, we will take note of all the questions and make sure we get the answers to you. And lastly, just wanna mention if anyone needs any accessibility support, training, usability testing, kiosk regulations, consulting, we will send an email out with a link to schedule a time to speak with one of our experts after the webinar. And with that, I am going to let David get started and provide an introduction of himself. - Okay. Thanks, Stefani. Hi folks, my name is David Swallow, and I'm principal UX consultant at TPGi. Here I am responsible for our UX services, such as user research, usability testing, inclusive design reviews, AT user flow testing and consultancy. And we work with organizations to shift left and incorporate accessibility as early as possible into the development lifecycle, which, as the title suggest, is what I'm gonna be talking about today. Prior to this, I was an academic researcher in human-computer interaction at the University of York in the UK, and during my time at the University of York, I gained a PhD in computer science, investigating how to integrate accessibility into the workflows of web developers. And integrating accessibility into the workflows of not just web developers but everyone involved in building an accessible product is the focus of today's webinar. Now, I've called the webinar "Shifting Further Left: Integrating Accessibility Into the Earliest Stages of Development", however, a slightly more exciting name could be "The Accessibility Ripple Effect: How Going Back in Time Can Change the Future of Your Product". And the reason for this, as I alluded to on LinkedIn earlier this week, is because I had planned to draw upon classic time travel movies and shows to explore how early accessibility actions ripple through the development lifecycle. But goodness me, you would not believe what a hassle it has been to use imagery and concepts from those movies. So instead, welcome to my entirely generic, legally safe accessibility webinar, and join me as we travel to the past with absolutely no risk of copyright infringement. By the way, I don't live in a cave here. The winter sun is very low and it's not coming in, so I've sort of shut the blinds. But yeah. So time travel tales capture our imagination because they show how small actions in the past can ripple into significant changes for the future. So from "Back to the Future" to the "Terminator" series, "Harry Potter" to "Dr Who", these stories reveal a fascinating truth, that decisions made early on shape everything that follows. Now, this slide was intended to be a collection of images from various time travel movies, but after contacting the licensing departments of various movie companies, I was told not only would I need to pay a license fee, I would also need to secure clearance from the actors involved. So instead, you'll have to make do with a collection of time-travel inspired, copyright free clip art. Feel free to write in with which movies and shows they represent. We've got a clock there set to 10:04, some sunglasses with a red spot over one eye, a red monkey, a police box, a computer processor, an hourglass inside a circle, someone luxuriating in a hot tub and a purple tentacle thing. Anyway, in these narratives, the protagonists discover that their choices, whether intentional or accidental, have far-reaching consequences. So in "Back to the Future", which I was depressed to learn is 40 years old this year, Marty McFly's attempts to fix his family's future show how small changes in the past can transform relationships and outcomes. In the "Terminator" series, actions in the past are critical to preventing or enabling catastrophic futures. And in "Harry Potter and the Prisoner of Azkaban", which my wife argued would be more familiar than "Back to the Future" for most people watching this, Harry and Hermione use a time turner to revisit key moments, making small but crucial changes that ultimately save lives and ensure a better outcome. So across time travel stories, the recurring lesson is clear, early decisions ripple outwards, affecting everything that comes after. And we can think about accessibility in a similar way. So acting early by embedding accessibility into planning, design and development creates ripples that improve outcomes throughout the software development lifecycle. So much like time travel, small, intentional actions now can profoundly shape the future of your product. So what does shifting left mean? So in software development, we talk about shifting left when we address concerns like security and performance or accessibility earlier in the development process. So traditionally, accessibility is treated as a late stage task, often during testing or worse, after a product has launched. But retroactive fixes are costly and time-consuming and often incomplete. Shifting left means moving accessibility considerations into the earliest stages of the software development lifecycle and planning, design and development. And it's the hallmark of an accessibility-mature organization. So the earlier accessibility is introduced, the fewer barriers are created. Early choices ripple outwards, shaping what happens downstream. By proactively weeding out accessibility bugs before they've got chance to grow, mixing metaphors here, you save time and money, you'll avoid wasted effort and redundancy, and you'll free up time that can be used to develop new features, and you'll end up with a better, more accessible, more inclusive product. So today we're going to start at a chaotic product launch full of unresolved accessibility bugs, and then, like time travelers in countless stories that I won't, we'll journey back to earlier moments in the process. And at each stop, testing, development, design, planning, we'll explore how early decisions can create ripple effects that shape the future of your product. So get ready to step into the time machine and uncover how we can rewrite the story of accessibility in your workflows. Okay. Welcome to launch day. After months, hold on one sec, that's better, after months or maybe years of development, your product is finally live, but instead of celebration, there's chaos. So users are frustrated, feedback is pouring in, your customer support team is overwhelmed, and worst of all, people with disabilities are encountering barriers that simply make the product unusable. And the cost of fixing these problems will be sky high, both in terms of time and money, and it feels like we're in an alternative timeline, a bad future for your product. How did we get there? So let's take a look at some common accessibility issues that plague products at launch and trace them back through the software development lifecycle to see where things went wrong. So one common issue is missing or inadequate alt text or images. So the problem at launch is that screen reader users can't understand important content because images lack descriptive text. And the impact on the user is confusion, incomplete information or an inability to complete key tasks. Another issue might be inconsistent keyboard navigation. So the problem at launch is that users relying on keyboards can't navigate certain parts of the product. This blocks progress, it creates frustration and can make features just unusable. Poor color contrast. So the launch problem is that text and interface elements are hard to read for users with low vision or colorblindness. And the impact of this can range from, like, you know, eye strain through to an inability to read critical information or missed actions. Another one might be form validation errors which are not announced properly. So when a user submits a form with errors, there's no clear announcement of what went wrong. And the impact is that users may be stuck and might be unable to proceed, might be unable to submit the form and unsure how to fix the problems. And another issue is a lack of focus indicators. So users navigating with a keyboard can't tell where they are on the page, they might lose their place and can't effectively interact with the interface. Now, these issues didn't magically appear at launch. They started somewhere earlier in the software development lifecycle. So missing alt text, that might have started in design, where image assets weren't annotated for accessibility. Inconsistent keyboard navigation, that could have started in planning, when accessibility guidelines weren't prioritized in technical specifications and continued in development, where no one accounted for focus management. Poor color contrast, that might have started in design, when branding decisions weren't reviewed for accessibility. Validation errors not being announced, that could have been caught during testing, but accessibility tests weren't prioritized in planning, leaving no resources or time allocated for thorough QA. And missing focus indicators, that might have started in design and again in development, when they weren't implemented correct. So every barrier at launch stems from missed opportunities earlier in the process. Each overlooked detail creates ripples that grow until they become unmanageable. So let's step into our non-copyright infringing time machine, and we're gonna go back to critical stages in the software development lifecycle to uncover where things went wrong and how they could have been prevented. So are you ready to rewrite the future? We'll start our journey. Feel free to insert your own non-copyright-infringing sound effects as well. Okay, testing. So we arrived at our first stop, which is the testing phase. At this stage, the product is largely built and QA teams are combing through it to identify bugs. And ideally, this would include thorough accessibility testing. Often accessibility testing is inconsistent and it isn't part of every QA cycle, so issues slip through the cracks. It's often automated. So, as we know, automated tools are helpful but limited, they can't catch everything, especially issues that require context or manual validation. Testing with assisted technologies or actual users is rarely encouraged. And accessibility testing is often rushed. So there's pressure to hit deadlines, and accessibility gets pushed aside or risk accepted instead of resolved. So let's look at our recurring issues and see how they play out in testing. So missing or inadequate alt text for images. So all automated tests might flag some missing alt text, but not all cases are caught, especially if decorative images are misidentified or if alt text is inadequate. And the ripple effect of this is without alt text clearly flagged in testing, these problems will persist into production. What should happen should combine automated tools with manual reviews to ensure all images have meaningful context-appropriate descriptions. Inconsistent keyboard navigation. Testers may notice gaps in keyboard navigation if they know to look for them, but without specific accessibility test cases, these gaps might be missed. So then the ripple effect of that is that broken navigation persists and impacts users relying on keyboards. So what should happen is that there should be clear test scripts for keyboard navigation that are included in QA plans. Poor color contrast. So automated tools catch some low-contrast text, but testers might dismiss it as a design issue or assume that it's something that has been already signed off. And the ripple effect of that is that the contrast issues linger and cause usability challenges for people with low vision. So what should happen is that we should treat color contrast issues as high-priority defects, not aesthetic concerns, and flag and resolve them as part of the QA process. Form validations are not announced properly. So this issue requires manual testing with assisted technologies like screen readers, and without those checks, it will be missed. So the ripple effect is that users encounter barriers when submitting forms and can't proceed. What should happen is manual screen reader testing must be an integral part of QA cycles, including detailed validation error scenarios. And missing focus indicators. So testers might not be instructed to check focus states, especially if there's no written accessibility test cases. And the ripple effect is that users relying on keyboards will struggle to navigate and be unable to track their position. What should happen, QA teams should have explicit test cases for focus indicators across all interactive elements. Okay, so we've seen how our recurring issues can be addressed at the testing stage. Here are some practical steps to shift left in testing. So automate where possible. So include accessibility, automated accessibility testing tools, TPGi's ARC platform into your CI/CD pipeline, and run them regularly to catch common issues early, create comprehensive test plans, so train QA teams on manual testing techniques like keyboard navigation and screen reader compatibility, create accessibility-specific test plans and checklists for thorough coverage, involve people with disabilities, so include users with disabilities in usability testing sessions to gather real-world feedback and identify usability pain points, prioritize accessibility defects, so treat accessibility issues as critical defects, not nice-to-haves, encourage QA teams to report these issues with the same priorities, functional bugs, and establish clear triage processes based on severity and user impact, and report, learn and improve, so document test results, clearly share findings with developers and designers for fixes and track key performance indicators, KPIs, to demonstrate progress over time. So while testing is critical, it's not the ultimate solution. When accessibility isn't built into testing practices, accessibility issues make their way into the final product. Rework costs increase, and it leads to poor or inconsistent user experiences as barriers are uncovered by users leading to negative feedback or reputational damage ultimately. So testing can catch problems, but it can't go back and fix decisions made earlier in the timeline. We can. So to prevent barriers at launch, accessibility needs to be integrated earlier. So let's move on to our next destination, which is development. Okay, so welcome to the development phase, where code gets written, components get built, and the product begins to take shape. At this stage, accessibility can either be baked into the foundation or accidentally coded out, but the problem is that accessibility isn't always part of a developer's checklist. Deadlines and tight sprints create pressure to prioritize speed over inclusivity. And developers might not have the knowledge, the tools or support to build accessible components effectively. And when accessibility isn't considered here, problems really start to solidify. So let's revisit our recurring issues and see how they play out in development. So there we go, missing or inadequate alt text. So developers might hard code image elements without alt attributes or rely on the placeholder text, you know, alt equals image, or alt equals blah. And the ripple effect is without proper alt text at the code level, no amount of testing can fully address the issue. What should happen is that developers should follow accessible coding guidelines and integrate accessibility linters and automated tools into their workflows to catch missing alt text early. Inconsistent keyboard navigation. So focus management isn't built into components, and developers might rely on mouse interactions without accounting for keyboard users. And the ripple effect is that testing teams may encounter significant navigation gaps, and that requires issue logging and delays in validating the product's accessibility. What should happen, developers should test their work with keyboard-only navigation and ensure logical focus order is preserved across all components. Poor color contrast. So colors and styles might be hard coded without adhering to contrast requirements. And the ripple effect of that is that testing might catch it, but fixing it often requires significant rework of components and designs. So what should happen, developers could use design tokens and CSS variables with pre-approved accessible color palettes. Form validation errors not announced properly. So error messages might not be programmatically associated with their respective form fields or ARIA roles might be missing. And the ripple effect is that testing might uncover the problem, but fixes can be time-consuming and prone to further errors. So what should happen is that developers should use semantic HTML and ensure validation messages are properly tied to input fields in attributes like aria-describedby. And then a lack of focus indicators. So default browser focus indicators are often removed during styling or custom focused states aren't implemented or are implemented badly, such as, you know, they're lacking sufficient color contrast. The ripple effect is that testing teams might struggle to identify and validate accessible focused states, delaying issue resolution and increasing rework. So what should happen, developers should ensure custom focus states are clearly visible and consistently applied across all interactive elements. So that's how our recurring issues can be addressed at development, and here are some practical steps to shift left in development. So integrate accessibility into CI and CD pipelines, automated accessibility checks should be part of continuous integration workflows, provide developer training, ensure developers are equipped with knowledge of WCAG principles and accessible coding practices. There we go. Use accessible component libraries. So pre-built components should meet accessible standards out of the box. Code reviews could include accessibility. So accessibility can be part of pull request reviews, not just functionality or security. And debug with assistive technology. So encourage developers to test their work with screen readers, keyboard-only navigation, and then other assistive technologies during the development process. And that helps, you know, identify barriers early and also fosters a deeper understanding of how users actually interact with the product. So developers are incredibly skilled problem solvers, but they can't fix problems they aren't aware of or trained to prevent. So when accessibility isn't built into development practices, issues compound and become harder and more expensive to fix later. Accessibility testing at the QA stage becomes a game of catch up rather than validation. And poor practices just become embedded in reusable components, and then that spreads barriers throughout the product. So development is where accessibility takes shape, or where barriers become embedded into the product. By addressing accessibility proactively in development, we can prevent many downstream problems from ever occurring. But even development isn't the earliest opportunity to make a difference. So let's hop back in the time machine and head to our next stop, which is the design phase. Okay, welcome to the design phase, where ideas take shape on wire frames and prototypes and design tools. At this stage, accessibility barriers often sneak in as invisible assumptions. So designers and UI and UX specialists might prioritize aesthetics over usability. Accessibility guidelines are sometimes seen as limiting creativity, and user journeys might, unintentionally, exclude people with disabilities. But design choices create those ripples that cascade into development and testing and beyond. So let's revisit our recurring issues and see how they play out in design. So missing or inadequate alt text. So images and icons may lack clear, functional descriptions in annotations, or the intent, the decorative versus informative versus functional intent might not be clarified. The ripple effect is that developers are left guessing how to implement alt text leading to inconsistencies. But what should happen is designers should include explicit annotations for image purposes, so as I say, decorative, informative, functional, and provide suggested alt text. Inconsistent keyboard navigation. So interactive elements like modals and dropdowns might not account for keyboard focus states or navigation order. And the ripple effect of that is that developers won't have the clarity on the expected keyboard behavior. So what should happen is the design spec should explicitly address things like focus state and tab order and keyboard interactions for all components. Poor color contrast. So color palettes might not meet poor color contrast ratios or hover and focus states rely solely on color cues. The ripple effect is developers may then implement designs that fail color contrast requirements. So what should happen is designers should use accessible color palettes from the start and validate them with contrast-checking tools. Form validation errors not announced properly. So error states might not have clear visual and textual feedback. The ripple effects is that developers then lack clarity on how to implement validation feedback accessibly. So what should happen is designers should provide clear mockups for validation states, error messages and ARIA annotations. Basically, it's all about annotation at the design stage. And missing focus indicators. So designs may exclude visible focus indicators or may have removed them for whatever reason. And so the ripple effect is that focus indicators may get deprioritized or overlooked during development. So what should happen is designers should ensure focus indicators are part of the system design and document it explicitly in mockups. That's the recurring issues. Here are some practical steps to shift left in design. So use accessible design systems, ensure your design system ideas to accessibility standards, annotate accessibility requirements, so document things like alt text, focus order and keyboard navigation in design specs, run design accessibility reviews, so include accessibility checks as part of your design review process, leverage accessibility tools during design, so use tools like contrast checkers, colorblindness simulators, and screen reader simulations to identify and resolve accessibility issues early in the design process, and many of these can be found in plugins for design tools like Figma. And of course, test with real users. So run design prototypes past people with disabilities early on. When accessibility is overlooked during design, developers lack guidance and make assumptions. Testing becomes a scramble to retrofit fixes, and the cost of making changes then skyrockets 'cause redesigning components is expensive. So design is where the future starts to become visible, and every design choice creates ripples. By prioritizing accessibility here, we empower developers, simplify testing and reduce costly late-stage fixes. But let's go further back. Where do all these decisions start? So let's travel to the planning phase. Okay, here we are, at the planning phase, where the vision for a product is set, resources are allocated and requirements shape every downstream decision. But this is also where many accessibility issues are born. And that's because accessibility is often left out of these early requirements, setting the stage for inconsistencies and reworking barriers further down the line. So let's revisit our recurring accessibility issues one more time and see how laying down clear actionable requirements can prevent them. So missing or inadequate alt text for images. So user stories and acceptance criteria don't specify alt text requirements, leaving design and development without clear guidance. Ripple effect is that designers might omit image annotations, and developers may guess or implement inconsistent alt text. So what should happen, define requirements like all images must have appropriate alternative text. Inconsistent keyboard navigation. So the oversight here is keyboard navigation expectations are not included in user stories or definitions of done. And the ripple effect is that developers lack clarity on the expected keyboard interactions, leading to gaps in implementation. So what should happen, incorporate keyboard navigation requirements into acceptance criteria for individual components, and ensure the definition of done includes a commitment to testing and implementing accessible keyboard navigation. Poor color contrast. So accessibility requirements for color contrast may not be defined in brand style guides or project specifications, and then designers use non-compliant color palettes, and developers implement them without validation, and that requires costly redesigns later. So what should happen, include color contrast requirements in brand style guides and design system documentation. Form validation errors not announced properly. So error handling requirements are often vague, omitted or assumed to be handled later. And then developers lack clear guidance, leading to inaccessible or inconsistent error message implementations. So what should happen is user stories should specify that form validation must provide accessible feedback, and acceptance criteria should outline how error handling must work. And then the lack of focus indicators. So focus management and visible focus indicators are often overlooked in early requirements and design documentation. Ripple effect is without that clear guidance, focus indicators may be inconsistently applied or excluded entirely during design and development, requiring retroactive fixes. So what should happen should include requirements for visible focus states in user stories and acceptance criteria. Design systems should explicitly document focus indicators styles as a core component, ensuring that they're, you know, visually distinct and consistently applied. Okay, so that was our recurring issues and how they can be addressed at the planning stage. And here are some practical steps to shift left in planning. To incorporate accessibility into user stories and acceptance criteria. Define user stories that explicitly address accessibility needs, like as a keyboard user, I need logical focus orders so I can navigate the interface effectively. Include clear measurable acceptance criteria for accessibility. You know, all interactive elements must be operable via the keyboard. Make accessibility part of the definition of done. So establish that accessibility compliance is a non-negotiable part of the definition of done. And ensure that teams understand that accessibility checks are integral to marking tasks as complete. Include accessibility in research and personas, so plan user research sessions that include participants with disabilities, ensuring insights reflect diverse experiences, and create detailed personas that highlight specific accessibility needs, like a, you know, a persona who uses screen notification or a screen reader. Use research findings then to guide planning and prioritization and feature development. Allocate time and budget for accessibility work is the big one really. Dedicate resources for accessibility efforts, including tools and training and external consultations if needed. And you know where to go for that. Build the time into project plans for accessibility testing, iterative design updates and cross-functional collaboration. And prototype with accessibility in mind. So focus on testing things like structure and interactions and compatibility with screen readers, and gather early feedback on usability from people with disabilities and people who use assistive technologies to then inform, to inform further requirements. So the planning phase is where it all begins, the first ripple in the timeline. So by embedding accessibility into your user stories, research and definitions of done, you create a foundation that supports every phase to come. So now that we set the stage for an accessible product, it's time to go back to the future. Let's see how those early actions ripple forward to shape an inclusive successful product launch. And here we are, back in the future, but this time it's a better future, it's an accessible future. Because we shifted accessibility left at every stage of the timeline, these recurrent issues that we've seen, the disappearing alt text, the broken keyboard navigation, the poor color contrast, unhelpful error messages and the missing focus indicators have all been addressed. So if you look back at those key accessibility issues, alt text for images that was defined in user stories with clear acceptance criteria, it was annotated and designed to clarify intent, it was implemented with the appropriate attributes during development and it was checked for accuracy during testing. Keyboard navigation, it was included in definitions of done and documented in designs with logical focus order and interaction expectations. It was coded to support consistent navigation and tested with keyboard-only workflows. Poor color contrast, that was integrated into brand guidelines with measurable standards. It was checked against designs to ensure readability and validated in development with tools to maintain compliance. Validation errors were detailed in planning with specific requirements for accessible error message. It was designed to provide clear guidance to users. It was implemented with proper ARIA roles and live regions and tested to ensure usability across assistive technologies. And focus indicators were planned with clear specifications, visibility and usability and incorporated the design systems with consistent styling, developed with attention to browser and device compatibility and tested to confirm accessibility across various environments. So every small decision made early on created positive ripples throughout the software development lifecycle. Design decisions were clearer and more inclusive guided by those accessible requirements. Development was smoother because designs were accessible, testing uncovered fewer surprises because accessibility was built in, and the product launch was seamless with fewer critical accessibility bugs to patch post-release. So this is all to say early decisions lay the foundation for success. Small actions can lead to significant positive outcomes. And shifting left is about embedding accessibility from the start to create meaningful, lasting impact. So the future is in your hands. We've journeyed through the software development lifecycle, from a buggy, inaccessible product launch to a better future where accessibility is embedded at every stage, and each step of the way, we've seen how small, intentional actions create ripples that transform outcomes. And we've explored practical strategies for integrating accessibility into the very inception of your product. So the ripple effect starts with you. So every team member, whether products owner, designer, developer, tester, can drive accessibility forward. By embedding it early, you're not just fixing issues, you're preventing barriers before they exist. So what can you do? Start small. So begin by identifying one specific area where you can integrate accessibility earlier into your workflows. You know, add accessibility criteria to a single user story or conduct an accessibility review of a single design component. Small, targeted efforts can then build that momentum for broader change. Keep learning. So encourage continuous learning about accessibility within your organization. Offer training sessions, share resources and promote awareness to help your team stay informed about best practices, emerging tools and evolving standards. You become the, become the stone that creates the ripples. I think that's right. Collaborate. So foster strong collaboration between designers and developers and QA teams to create a unified approach to accessibility. Clear communication and shared accountability help to ensure that accessibility is considered at every stage of development. Don't just chuck things over the wall from one phase to the next. Use tools. So use a combination of automated tools and manual testing to ensure comprehensive accessibility checks. Automated tools can quickly identify common technical issues while manual testing helps uncover more complex accessibility barriers. And of course, testing with people with disabilities will provide invaluable insights and help identify real-world accessibility bugs that tools or simulations might miss. So accessibility isn't just about compliance, it's about creating better products for everyone. So start early, build habits and watch the ripple effect of your efforts grow. So create your own accessibility ripple effects. And to end on a cheesy but hopeful note, the future isn't written yet. It's up to us to make it accessible. So thank you for listening. I'm David Swallow. Thanks to the copyright issues this isn't quite the webinar that I had envisaged, but thanks for sticking with me, and I hope there was something useful in there. I think we've got time for few questions. - [Stefani] Yeah, Dave, that was great, David. Thank you so much. There are quite a few questions in the Q and A, and I also have a few on my end from the chat. So start from there, I guess. - Okay. Having a look. Krista, thank you. Yes, it's up there somewhere. Marshmallow man. Danny, thank you, yeah. Mark Maloney, would you agree the ultimate shift left is the requirement phase of the development process? Yes, I would, Mark. Yeah. Yes. And I hope that, I hope that came through. Absolutely. Yeah, get it into the very start, yeah. Product inception's absolutely where, yeah, shifting to the left, the furthest left, yeah. Anonymous attendee. I would argue that automation is best for regression testing, and new functionality must be tested manually. Do you agree? Possibly. I'm curious, you know, what you're thinking there. As I say, automated testing's good for that first pass, that technical accessibility really, and then follow up with manual. But you're saying new functionality must be tested manually. Yeah, I mean... Yeah. That might work. I'm curious to know what your thinking is there, yeah. But yeah, it sounds reasonable. Sorry, I'm rubbish at answering questions Development of an ICT most often is an agile process. How could one identify the scope of possible accessibility criterions prior to the actual production started, especially when the team does not have much accessibility experience? So thinking about that pipeline stage, just very in the early stages of the development. You're saying how can one identify the scope- - They elaborate in the next, did you see the- - Oh, right. - connection? - Yeah, yeah. Okay, meaning, asking to follow an entire list of look at items, ARIA entry 1349 in Europe will create a lot of confusion, but the file interface may be very different from what was set in business task. QA might test what was specified and scope was designed but not written in technical task. Yeah. I mean, that is true, that it is gonna be hard to anticipate the finished thing at that stage, but there will be certain, what do you call them, common items that are going to be in the product. So if you're putting down requirements around images, you know, that's likely that that will be in the finished product. It's gonna have to be navigated with a keyboard, for example. It's gonna have to work with a screen reader. So yeah, there will be commonalities to that. I mean, yeah, you might not put in requirements around captions if the product isn't gonna have captions and audio description and things like that. Yeah, there will be certain project-dependent requirements, but ultimately, there will be a core of common accessibility requirements that I think you can put in place early on. Hope that answers your question. Jean, Jean, any suggestions on stakeholders posting to social media and posts are not accessible? Mine love to post images from what, pose on my wall with no text. Yeah. I mean, that's just an educational thing really, I suppose, a knowledge thing, an awareness thing of making social media accessible. I mean, it's not helped by certain platforms removing or degrading their accessibility provision so that does make it difficult. And there's certain behaviors that people have picked up, like, you know, like taking photos of the text document on social media, certain, yeah. Those sort of things that have developed, which is quite frustrating. But, you know, the main social media can be made accessible. There are techniques for that, you know, at least there is usually a text alternative provision and caption provision. So yeah. I guess it's just about raising awareness with stakeholders there. I'm not sure what pose on my wall, pose on my wall is, but yeah, maybe not. Rick Gordon, can you elaborate on the role of the Scrum master product owner in making the process work? Not really, Rick. Great knowledge of those processes and how they work. But yeah, it comes back to defining those requirements really, and making sure they're built in from the start, yeah. Yeah, I don't know, really, on that one. I can come back to you with a more complete answer there. Do you have recommendations for assistive technology tools, from Alicia, technology tools that are best when testing? Yes. Well, so for automated testing, I feel obliged to mention ARC platform, TPGi's ARC platform for your testing needs. Manual testing, utilities like TPGi's ARC Toolkit, Color Contrast Analyzer, utilities like that. I'd also recommend testing with a screen reader if possible. So Jaws, NVDA, VoiceOver on the Mac. Yeah. Yeah, you actually said assistive technologies, so that's, yeah. So yeah, definitely the main screen readers there. ZoomText, that might be worth considering and also, you know, screen magnification software and browser screen magnification. And testing with a keyboard, of course, the ultimate assistive technology. How can we convince designers to consider accessibility reviews and add annotations? Yeah, I didn't know what to say about this one 'cause, you know, in my experience, designers are often pretty good, pretty switched on to this. Hasn't been too much of a battle, and I didn't want to slur them too much by, you know, saying that accessibility is neglected at that stage. I don't know. You could stress it, stress the design challenges rather than the constraints that accessibility provides. Oh, there's a, Leonie Watson has a quote. Oh, I've forgotten it now. Hold on. There we go. "Accessibility is a creative challenge, not a challenge to creativity", which I think sums it up. So yeah, I think if you can put it in those terms, that might encourage designers to get on board with accessibility. But yeah, as I say, generally I find that, yeah, pretty, pretty good at that stage. Any suggestions? Anonymous attendee says any suggestions regarding mobile app accessibility? Oh, where to start there. That's probably a whole new talk in itself, and well, we have had those sort of talks from TPGi. My colleague, Laurie Pagano, recently did one on testing mobile accessibility. I have no insight really on developing mobile apps. So yeah. I would refer you to our other TPGi webinars for that one. Jean, all right, yeah, Jean. Thank you, yeah. Lily, what's accessible design system examples? What's accessibility tools examples, what's brand guidelines personas? Do we need to include personas that's already covered by the accessibility guidelines? Goodness me. Accessible design systems. I mean, I was thinking the design systems you build, make them accessible. Yeah. I don't know if the question is about what they are or what they, what they should be. Accessibility tools. I've mentioned some of those. At the design stage, the tools at the design stage, you know, there's lots of plugins and things that go into things like design tools like Figma and Sketch, and they largely test color contrast, typography, things like that. But yeah, they can be useful at the design stage. And maybe get some vision simulators. Sometimes screen reader output approximations. And with design, sorry, design tools, you have to get annotation kits. It's quite popular at the moment, accessibility annotation kits, essentially just stickers and ways of formalizing accessibility annotation on designs, and yeah. They won't check your designs, but it will communicate accessibility more easily between teams. That's another way, to the other caller person, about convincing designers. Using tools like that may help, you know, streamline the process a bit. Brand guidelines. Just the sets of guidelines around the brand, you know, and how, the color schemes that need to be used, you know, things like how logos have to be presented in the space around them and heading levels, those sort of things about how a company's brand is communicated. So if you can get accessibility in in that stage, it's really, you know, there at the root. That's what I meant by that. For personas, do we need to include personas that's already covered by the accessibility guidelines? Yeah, yeah. Well, yeah, the personas illustrate your archetypal users of your product, so yeah, you know, you, I mean, we typically not make it, you know, the screen reader user or, you know, the dyslexic user, but incorporate those kind of attributes into fully fleshed out personas. But yeah, there's no either or with the accessibility guidelines there. Okay, Mitchell. No, nothing there. Okay, I think that's it. - [Stefani] I have a couple, David. There was one in the chat. Thank you for this wonderful session. I had a question for images. How should we tackle SVG infographic images with machine readable text? What can be done to make them accessible? - Oh my goodness. Let me just- - Harika. - It's up at the beginning- - Harika. - [Stefani] in the chat. - How should we tackle the SVG infographic images with machine readable text? What could be done to make them accessible? Hmm. I'm not really sure what you're getting at there, Noyrika. Do you mean- - [Stefani] Oh, we have a couple of inputs from other folks on the webinar. - Oh, that'd be good. Yeah, please. - SVGs can include the title tags, I believe, which might help or hide the text from screen readers and add alt text with a question. - Oh. So actually, how to give the text alternatives. Yes, yes. These are the solutions mentioned. That's technically how you would provide it, yes. Either through the SVG component itself, the title, title element or from screen-reader-only text that would be visually hidden, that would be approach to doing it. I was thinking you were coming back from what should they be for an infographic and, you know, what should the content of the text alternative be, but no. Technically, that's exactly right, what the other callers said. Yeah. - And also a little add-on. Do we also need a long description in this case? - Oh, I don't know. It depends what the content is. I mean, are you stuffing an entire infographic into a single text alternative? - [Stefani] Right. - I don't know if that would be a wise approach really. Perhaps it can be if it can be broken down into smaller parts. Yeah, not totally sure on that one. - [Stefani] I don't know if you saw this other question from Lily. For personas, do we need to include personas that- - Yeah, I've covered that. - You've covered that? - Well, tried to. - Okay. I think we've covered most. A lot of positive feedback. I don't see any other questions, I don't think. - Okay. - [Stefani] And we're just at the top of the hour, so thank you, everyone, for joining us today. We will be sending out the recorded session after we review it. And if you have any additional questions or need some accessibility guidance, feel free to reach out to info@tpgi.com, and I'll put that in the chat. Thanks, everyone. Have a great day, evening. - Thanks a lot. Bye-bye. - Bye.