Product Accessibility Updates – July 2023

Transcript

Speaker: Allison Lindberg VP of Product Strategy at Inclusively

Hello everyone, and welcome to our presentation around the Inclusively product accessibility updates for for Q3. My name is Alison Lindberg, and I am the head of the product team here at Inclusively. So my role is working with the engineering team, as well as the business and our user community to move the product forward and roll out new features and functionality, while also listening to user feedback to update things accordingly. For the next 20 minutes or so I’m going to focus on accessibility within our product. And we’ll walk through a few different areas of how we approach this. This space as we design develop and deploy makes the Inclusively platform and Inclusively, we believe that everyone should be able to access and use our platform with ease and without barriers. Accessibility is an ongoing journey within our product development. And we are committed to continuous improvement of our processes, education, and execution to break down those barriers for our users. In today’s session, we’ll go over a few different areas. First, we’ll start with the current state of accessibility within the Inclusively product and where we’re at today.

Allison Lindberg 1:21
Next, I’d like to cover what tooling we use to approach accessibility in all aspects of our product starting with design, all the way through to deploying our features and functionality to production. And third, I’d like to go over our future state. This will cover what commitments and milestones we have on our roadmap to achieve accessibility on consistently and continue to improve our platform to be accessible for all. Lastly, I’ll go over a couple of ways we can stay in touch on everything having to do with accessibility. And let’s get started with a review of wearing clothes is at today as we design, develop and deploy our product, keeping accessibility in mind and achieving various goals that we have for ourselves to keep our product accessible. First, when we start to design, design, our different screens and feature releases, we use a few different tools that our UX designer focuses on well, well he he executes on these different design phases. The first one is a figma contrast design plugin. We use figma to to write up our designs and mock them up accordingly. And we all always run them through a contrast checker. Secondly, we use a component library of proven tested accessible components as we build out the visuals that tie into these designs. Lastly, we we review past user feedback from our current platform, and always take note of areas that might have had blockers for accessibility. And we tie that into our future design so that we are remediating as we design and move forward. The next area is development. After our designs are signed off and approved, our front end engineering team takes those and begin to build. We use multiple tools to to make sure that we are pulling accessible accessible functionality into our platform as we build it out. The first one is called React-axe-core, it’s used on the front end the front end code base allowing developers to identify accessibility blockers during the development phase, and also reduces the escape of those blockers into release features. So it so we’re keeping in mind accessibility at the code level always. Secondly, we use other forms of dev tools within the Axe product suite. And one is called is a browser extension that each of our front end engineers plugs into their computers as they code and then build out the platform. This is this particular tool is not designed for front end developers as well as testers to run quick in browser tests at any time. The extension generates detailed information on accessibility defects and or violations and how to fix them quickly. Once the initial build is complete, and these tests have been run, we move over to our testing and feedback phase. We use different assistive technologies during this testing phase, as well as we utilize a group of testers who are part of various disability communities so that we are constantly testing real accessible user experience. From there we take that feedback of those testers and then we remediate according. After completing these three steps, we then release our product or our updated product. features and functionality to production.

Allison Lindberg 5:08
Next, I’d like to discuss what tooling we currently use. And some of this I covered in the last slide. But this goes into a little more detail. So what are all the tools that we use to make our platform accessible? As I mentioned, design tools, not only do we use the figma contrast plugin for all UX designs, but we also tap into that component library that I mentioned, that will come we always are continuing to build out our front end, our front end development team uses different coding tools, specifically the Axe tools I mentioned in the last slide. But also, we use a linting tool. And this ties into an a11y plugin, which is a static plugin for accessibility compliant rules within the code, and ensure we aren’t breaking those rules as we continue to develop. In addition to the a11y plugin, we use lighthouse in specifically in the Chrome browser. This is used to check accessibility rules within Web applications at the code level. The last two are a little more detail around those 2x tools that I mentioned in my last slide. The first is called react Axe core. This is used for front end code bases, allowing developers to identify those accessibility blockers during the development phase. And then again, making sure that we’re not we are not somehow escaping those blockers. And we are resolving them as we go. And additionally, that browser extension that I mentioned, that is again developed, it’s returning information on accessibility defects and how to fix them.

Allison Lindberg 6:44
So those reports are extremely valuable to our developers, because it not only calls out the any blockers or violations, but it also tells them how to fix them, which helps us build a foundation of knowledge for future builds. And lastly, we use a couple of tools that are testing phase as well. One is called play right with the Axe Core plugin. And this is installed to run final automated accessibility tests. And then we also all of our testers, including myself, use various assistive technologies to test the UX from an accessibility vantage point. Next, I’d like to move into our future state. And this is perhaps one of the most important slides in this presentation. Accessibility is always going to be an ongoing journey with no defined finish line, we will always be striving to be more and more accessible as be live on through this platform. That being said, I’d like to call out a couple of things that are on our roadmap and commitments we’ve made to to achieve certain milestones to continue to build out the most accessible platform possible. The first is the continued development of our accessible component library and building out our design system based on that library. So further enhancements to how we design are in the pipeline, and they’re going to be executed over the next within this quarter. Secondly, we have an adoption of an axe core plugin. As we mentioned, Axe is the product suite we use primarily for automated accessibility testing. But we want to add that at the design level as well into figma, which is again the software we use to build out our designs. Within the development phase, we have a few tooling commitments that we have coming up. The implementation of the following tools are to two achievements we’d like to tackle within the next month or so. The first is Axe Core and continuous integration. This takes our automation even further with one final check prior to code deployment and add adding more end to end testing. So this test the whole process, after we’ve tested the individual pieces that make up a feature release. Additionally, we want to add Axe Dev Tools intelligent guided tests in our quality assurance phase. So this means before releasing new features to our customers a final quality assurance process using that dev tool, called intelligent guided tests will take place. Again, this will further ensure the overall access overall accessibility of larger features using a consistent framework for accessibility testing. So taking those smaller tests and then overlaying a larger holistic test for bigger releases is something very important to us. And it again helps us catch any violations or blockers that we may have missed during the smaller iterative build. A couple more areas I want to cover in terms of what we’re looking to looking to achieve in the in the near future is committed. We’re committed to training all front end developers, designers and product managers on accessibility standards and practice through online training and certification. For this education we’ve chose, we’ve chosen Deque University  University, which will get signed up for those courses in the coming month. From there, we’d also continue to like to train our developers on these specific tools that we have. So, for example, in the Axe Dev tool suite, we can always be signing up for more training courses as accessibility moves forward and progresses. Accessibility tooling testing, development is an evolution. And we want to stay on top of that and stay in the now by keeping ourselves educated updated on the latest and best practices. In addition, we always are looking for ways to improve our testing and feedback phase one, one way that we can do that is with you the user community, we’ve updated our Contact Us form within the marketing page to report on accessibility issues, questions or suggestions, which we are always looking for. And that transparency is very important to us at Inclusively. Secondly, we will now have an enhanced accessibility page on the Inclusively web page, which means will now include one shared space public to all of our users, which will show the status updates around accessibility tooling, education, testing, development, and any advances that we’ve made, in addition to anywhere where we might be seeing, seeing room for improvement. So be sure to check that out. In my next slide, I’m going to just point out where these two items live to stay in contact about accessibility. The first one is our contact form. And I have the link here in the deck which will be accessible to everybody. This link will open up a contact form. And we want to be sure that if you are submitting anything around accessibility to select the contacting technical support accessibility category, when filling out the form, and this will be routed directly to our support team. And then my team, which is the product and engineering team will be will be pulled in to review and respond. The second way we want to stay in touch with our users, as I mentioned is that updated accessibility page that lives on the Inclusively website. This is access accessible through our main URL, and then accessibility statement at the bottom of the page. We encourage users to continue to visit this page for updates, again on our current status on accessibility within our product, upcoming events, new tool adoption and any updates to certify patients and trainings we’d like to share with our community. So please be sure to check out that page. So that’s all I have for today. And I will definitely be checking in with more regular webinars and presentations to continue to update you all on our progress. As I mentioned, accessibility is an ongoing journey that we’re never, never going to put a pin in because it’s a continued evolution with no finish line that we want to stay on top of. So please join me in checking out this page as well as submitting any questions, concerns or suggestions through that contact form. Have a great day and we’ll talk soon.