Enabling an Accessible SDLC – People, Process and Technologies
Thank you for joining the webinar today, we will begin momentarily as people sign in. All right, good morning, good afternoon, everyone. My name is Mike Mooney, the digital marketing manager at TPGi. I'm excited for you to join us for today's webinar, Enabling an Accessible SDLC, People, Process and Technologies with our speakers, Chase Aucoin and Mark Miller.
I'll let them introduce themselves in a moment, but before we get started, I just wanna cover a couple of housekeeping items. First off, this session is being recorded and we will email everyone the recording after the event. We have captions available, feel free to use those as needed.
And lastly, if we have time for live Q and A, our speakers will respond to those questions at the end of the session. Please use the Q and A box in your dashboard, and they'll get to as many of those as they can. And lastly, if anyone needs any accessibility support or training or has any questions, feel free to reach out to us and our expert can help assist you and your team. And with that, I will let Mark and Chase get started, Mark? Mike, thank you very much and thank all of you for being here, we're super excited to present for you guys today. This is a fantastic topic, one that Chase and I are both very passionate about, so we appreciate everybody joining.
First of all, I'm gonna turn it over to Chase. Chase, can you introduce yourself to the wonderful folks? I can and will, hi, everybody, my name's Chase Aucoin. I am the chief architect for TPGi, my team's handle creating all software, et cetera, for our platform. I've got over 15 years of enterprise development experience with Fortune 50, Fortune 500 companies. I am passionate about systems level design, so systems of systems and how we think of things at an all the other level.
You can me on GitHub, LinkedIn, or Twitter at Chase Aucoin. Thanks, Chase. And I am Mark Miller, I have my own slide here if I can get to it. I'm director of emerging accounts and platform here at TPGi as well. I've been in accessibility for around eight years, maybe a little more at this point.
I host the "Real People, Real Stories," podcast, which you can find on our website. My big passion in accessibility is really about organizational strategy. And you'll find that my passion and Chase's passion sort of blend well together in this topic for you all. So what we're gonna go over today is we're gonna discuss what digital accessibility is. And then we're gonna go into continuous accessibility. Accessibility, a lot of people sort of think of it as something that they have to go do and they'll be an into that task.
And we're gonna talk about how you treat accessibility when you realize it is something that is ongoing. Organizational changes that are necessary, the tooling that can support that, how automation can support that and what best practices around that look like. So let's start with what is digital accessibility.
So what is digital accessibility? Disabilities change the way that people consume digital content. So if you think about somebody who's blind or low vision, they rely on a particular technology called a screen reader to read the content aloud, or they use something called a screen magnifier which really magnifies the screen to the point where somebody with low vision can see it. And some people are in a place where they actually use a combination of the two technologies. If you think about somebody with limited mobility, much like a person who is blind, they can't use a mouse, or they might not be able to use a mouse.
So they rely on the keyboard to navigate through content on the web that some of us might use a keyboard and mouse for. And those with cognitive disorders may only be able to focus on a disparate pieces of content rather than the entire page. Cognitive is interesting, I actually would consider myself in this category of people with cognitive disabilities because I have dyslexia and ADHD, both, which is a whole lot of fun. But I don't necessarily need to accommodate the way that somebody who's on the autistic spectrum very deeply might need to. So I certainly appreciate it when things are a little less distracting.
And then a person with a hearing disability, somebody who's deaf, they may not be able to hear, or they won't be able to hear any of the auditory content. So they very much rely on things like captions and transcripts to understand the content that's being conveyed auditorily. So what then makes websites and documents accessible? And remember, we're thinking about this in a digital sense. So the web documents, applications you might use, all those sorts sorts of things. An accessible website is one that enables people with disabilities, so any one of, we sort of covered four categories, cognitive, motor, visual, and auditory.
It enables them to have a comparable experience to those without a disability. And this idea of an equivalent or comparible experience is very important. Keep that in the back of your mind, as Chase and I continue to kind of go through the content, that is really the goal that we're always trying to achieve. Every user who comes to your site should at least be able to accomplish key tasks. If there's a form they need to submit, they should be able to do that.
If there's information or content they need to consume or read, they should be able to do that. If there's a document that they should need to open up, they should be able to do that. Watching videos, logging into a portal, all these actions that you would expect to be able to do, when you go on the site, should be able to be done by people with disabilities.
And if people are unable to complete these tasks due to their assistive technology not working the way it needs to, to interact properly with the website, then it's not accessible, that's a really easy way to think about it. And it could be their assistive technology, or it could be their method of interaction. So somebody who just uses a keyboard, he needs to work with just the keyboard, so there may not even be a specific technology in play.
So there's a few different reasons why you might think about accessibility. Why you might, as an organization, especially want to take on accessibility is a mandate, or is something that you're going to do when it comes to creating your digital content. The first one is what we kind of have under this category that we're calling moral implications. You can think about it as sort of social responsibility or your corporate social responsibility.
So corporate social responsibility is a critical factor and it ties into brand perception. And we'll go into that a little bit. Corporate responsibility nurtures, grows and protects brand and reputation value, potentially up to 11% of the total perceived value of that company. It's not just an outward perception, employees feel more positive towards employers that foster a sense of inclusivity. And inclusivity is another great word and way, and think about when we think about accessibility.
Now, Mark, are you seeing on the moral applications of this? I know one of the things I've noticed and I've heard from executives and from business leaders and technology leaders that there's a big focus on DNI, diversity and inclusion in organizations. Do you think that's playing a factor of what we're seeing in these organizations or do you it's motivated elsewhere? So that's a great question and a great thought. I'm really glad you brought it up because I do see, so I'm on the front lines and talking to organizations all the time, and I do see an uptick in that being the, or one of the reasons why organizations are focused on accessibility. It comes from all sorts of different places, so it's not not a single driving factor, but as they're thinking about their diversity, equity and inclusion, that includes people with disabilities.
And it's also, I see it with organizations that have been trying to evangelize for accessibility and now a diversity equity and inclusion program comes in and they have something to tie that to. So it becomes a better vehicle for them to evangelize. Go ahead, Chase. No, that makes sense.
That was my only question on that and I think I'm seeing the same things by and large, and it's been a really good boom to getting people thinking more broadly within their organizations about how they help people. So, yeah. For sure, thanks, great point. All right, so the business implications is the other thing that I wanted to talk about. So what does this matter to the business? And this is an important concept to understand because when you want to use a program like this, or when a program like this surfaces, the businesses kind of have that natural question, they ask, "What's in it for us? How is this gonna help the business improve?" Well, good news is there's quite a decent ROI on it.
So a couple of the factors here is that a substantial segment of the world's population, somewhere around 15%, according to the World Bank, and the US population, 61 million identify with having a disability. That's a lot of people. Total after tax disposable income of working age people with disabilities is estimated to be around about 490 billion and that's according to the American Institute for Research. So there's significant customers out there that have disabilities and they got money.
Inaccessible job applications portals and organizational intranets prevent companies from employing a truly diverse workforce. And if you look at the statistics around diversity in the workforce, it's unbelievable the value that people with disabilities really contribute to an organization. And then there's also Title III implications where you're supposed to be hiring people with disabilities. But more than that, they're an incredibly valuable group to add to the bank of employees.
People with disabilities tend to be the most loyal customers. And I can tell you this firsthand, because Chase and I both work with a lot of people who have disabilities. And when they have a successful interaction on an e-commerce site, for example, they continue to go back. For lots of reasons. One, they appreciate the fact that somebody took the time to make a site inclusive, and inclusive to them. And also it just works, why are they gonna fool around with something else that doesn't doesn't work? I mean, I do the same thing.
Technically, I'm a person with a disability, but I do the same thing in areas that I wouldn't consider to be accommodating or accessible. I do it just because I like the way one site works better than the other. Once they find a product or service that satisfies their needs is often more trouble than it's worth for them to switch. So if I could paraphrase some of this, so it sounds to me like, outside of just like caring because it's the right thing to do from a person perspective, it sounds like from a business perspective makes a lot of financial sense to care deeply about accessibility within your organization.
And that there is quite a lot of money available from the aging population and just from the population generally as it relates to disabilities, as well as lifetime customers and great employees that you might be missing opportunities on, especially in a labor market right now where it's sometimes difficult to find good people for your organization. Yeah, great points, Chase. I'm really glad that you brought up the aging population. A lot of people think of people with disabilities as that person who was born blind or was in the military and saw action and came back with some sort of a disability. And really, it's my parents, it's your parents.
As we get older these things start to creep up on us. And these are people who are currently customers, they want to continue to do business the way they always have. So there's also legal implications out there.
And I don't wanna spend too much time on this. The bottom line is I think we're all aware that there's a level of legal risk and there's there's action out there, especially in the US. Disability lawsuits are super real, and they increase the risk for companies of all sizes. The Department of Justice has continually stated that websites fall under what's called public accommodations. So Title III, the ADA, there's a section of it that basically says places of public accommodation and typically that would be your bank, a library, the local park, the town hall, these physical places of public accommodation.
Well, guess what? Somewhere around 2000 and beyond, we all started banking, shopping, I registered my car online and I didn't walk into the town office anymore. So the internet and the Department of Justice is saying, "Hey, guys, stop arguing, this isn't the case. The internet is for falling under this public accommodation." Website accessibility lawsuits tripled from 2017 to 2018. I know we're past 2019, but they kept going up in 2019. There's a lot of data on that, I didn't wanna pour too much of that outta here.
But the point being is that there is a trend of lawsuits increasing on both federal and in some state levels, so there's risk out there. So a lot of people, when you take these three things, especially the last one, and you end up with this big kind of question mark at the end of it, it says, "Well, what do we do? And there's this concept that you can't be perfect. Technology changes, it evolves. So as soon as you fix as much as you can, you're gonna change that technology.
And just like, that might introduce bugs. And just like, you need a process for finding those bugs and addressing them. And technology is bugs that affect people with disabilities.
So that same phenomenon is occurring and guidelines are guidelines. There's no hard and fast, do these 10 things and you're all set. So the question becomes like, how do we satisfy all these things that you're talking about, Mark? I was talking to the third person.
And one of the ways that we can think about that is through something called substantial conformance. And really what substantial conformance means is that we're looking at Title III, the ADA that says public accommodation, places a public accommodation need to be accessible. People need to be able to get into a building.
Think of it as simple as that. So if you've have a wheelchair and there's a set of stairs, you're gonna need a ramp. The web is the same thing.
So one of the things that we look at is we look at what are the critical user journeys on the site? What are the main areas of a site that is really the intention of that site? For example, an e-commerce site, find a product, get it in the shopping cart and check out. You should be able to do that at minimum, to have an equivalent experience. You also probably should be able to reset your password because we all know we lose those passwords and if we can't reset a password, it can really be a barrier to our ability to engage in the core function of that website or access core content on that website. So the action here or the thought here is that you wanna make sure that the significant barriers, the things that would stop somebody, the big walls that might be in the way of somebody completing those tasks, we wanna make sure that those aren't there. And this is not a concept of perfect.
It doesn't mean every little image is tagged in this particular situation or has alt text associated with it. It doesn't mean everything works perfectly or every single guideline is met. It means that when a person with a disability tries to do something, they're successfully can complete it. So go ahead, Chase.
So from that, what I'm gathering out of this. So there's a need for organizations and individuals to make sure that they are enabling other people to be able to do the same things as themselves, like at a core level, like that's really what we're saying here, everybody should be able to have access to do and live the same life as it comes to getting food, managing trips, going to the doctor, et cetera, et cetera, et cetera. And so whenever your field is individually, you wanna make sure that you are creating accommodations so that individuals aren't in a position to be less than or othered as a result of that and unavailable to leverage what you're offering, that is important from a moral perspective, that is important from a business perspective, and that is important from a legal perspective.
But then we get into the problem of what do you do about it? How do you actually, if you're not on that path, if you're trying to figure out how do you get your head around that, where do you start? If you could hit the next slide. So systemic problems require systemic solutions. And whenever we think about accessibility and we think about accommodations as a whole or DNI as a whole, these are generally not isolated issues to one thing within an organization or a system. And oftentimes what we will see is that organizations try to pin responsibility on one person's shoulders or a group of people's shoulders within that organization, but it is everybody's job. You can't solve these problems in an organization. You can't create diversity, equity and inclusion in an organization if you're not involving everyone in making changes at all levels and that put those needs forward.
But in doing so, there are rewards for everyone involved. And so it doesn't just make sense because it is the right thing to do. It also makes sense from a business perspective holistically.
Next slide, please. So that brings us into this idea of like what continuous accessibility is, and really it goes back to that idea that it is a systemic problem. So we wanna work into all of our thinking from a business perspective, from a development perspective, from an execution perspective how do we bake accessibility in to what we do as a part of our software development life cycle? And as a part of that life cycle we can see that we start with our business idea, we go to requirement gatherings, mock ups, code, review, commit, unit testing, deployment, integration testing, functional testing, delivery and feedback, those are all the parts that make up a deployment cycle.
Now, whether or not organization is calling each of those steps out individually, they are in some capacity happening. And so if we think a step further and we think about this a little more granularly, next slide, please, we can really break this into four phases, idea, development, testing, and delivery. So our entire software development life cycle, all those individual pieces can really just be thought of as four main moving parts, the idea phase, the development phase, the testing phase and the delivery phase. Next slide, please. So in phase one, whenever we're thinking about ideas, this is really where accessibility starts. If we're not thinking about accessibility all the way from the point of inception of an idea, we're putting a lot of burden on a lot of the rest of the system to try and figure out how to make it happen later.
And ultimately that puts a lot of strain on the system, a lot of strain on individuals, a lot of having to redo things because you weren't putting accessibility in mind from the get go. But what you will find is that if you start with accessibility at the onset, you will make decisions downstream from that, that accommodate that and ultimately simplify everybody's role from their forward. So our idea phase can really be thought of as three main parts, the business idea, the requirements gathering and the mock ups. And so this is where you want to incorporate, I have this idea, is this idea going to be difficult for someone with a cognitive impairment to use, is this idea going to be difficult for someone who's using a screen reader to use, is this idea going to be usable by other people and make sense? And so as a part of the requirements gathering process and your mock ups, you can be baking those things in. And what's awesome is that the net result of that, if you put in that little bit of effort here, fulfilling on that effort becomes so much easier. Any thoughts or questions on that, Mark? Yeah, the one thing I really wanted to point out here, Chase, I think this is such an important concept.
And this phase, which I would kind of loosely throw out there sort of the design phase. Yep. Oftentimes people when they initially sort of decide to cross over and start thinking about accessibility, it's too late for this in a lot of cases, they have an existing website or they have something that's existing. And the fact of the matter is it's pretty arduous to remediate or improve that website in the ways that need to be done for accessibility because they weren't clearly thinking about that in the beginning. So when that same organization then says, "Wow, that was tough."
We better start thinking about this, shifting left and thinking about this from the beginning, that process, that end process with that final code base is being looked at and short up for accessibility becomes so much easier. And it's so much easier and cheaper to put it in the beginning. So I just think it's very, very important. Most people don't have the luxury of starting here the first time they cross over, but boy, should you try and head here? And there are ways that we as an organization can help with that as well. If you go to the next slide. Mark, if you'd like to talk about some of the things that we do.
So some of the things that we do are strategy and program management. So this would be annual program management, this would be strategic consulting in program direction, prioritization and sustainability. So to Chase's point, this is really helping you look at your software development life cycle, looking at process areas in the organization that influence that life cycle and making sure that everybody understands their responsibilities around it and make sure that you've got this inclusion in all aspects of it.
You wanna talk about phase two, chase? Yeah, I do. So once we get past that kind of design phase and that ideation phase, we move into the actual creation and the development process. So this is where you get your engineers involved. This is where you get your UX teams involved, et cetera, and really start creating what you're trying to drive value from the business.
Because ultimately you as a business are there to create some form of value. What is your value proposition? What are you trying to deliver? So this is where you're actually executing on that vision. But if you as an organization are trying to take accessibility seriously, people will do what is easiest to do by and large, people wanna do the right things, but at the same time, most engineering firms, most engineering departments within organizations are grossly understaffed, grossly overworked. And so adding new requirements, adding new burdens onto those, are already tenuous and strained relationships can be very difficult.
And so that's where you want to incorporate tooling and functionality into those processes and make investments into the way that the development life cycle is handled so that you can limit those burdens or remove them all together. That's really the only way that you're gonna get traction in a large scale, meaningful way. Now, again, what's great on greenfield projects, if we've done a good job on the design phase. And if we're thinking about this kind of holistically, that actually gets easier and easier over time, rather than harder and harder over time. So you may have a big investment or a commitment up front that does require a little bit of effort, but if you're doing it in the best way possible (laughs), but I'll put it that way or in a really good way, because there's no right way necessarily. But there are better ways.
And if you are incorporating some of these ideas, it should feel easy and pretty much self-regulating over time. Next slide, please. I bring this into part three. So we go from the development phase into testing and testing can really be thought of as four different parts, unit testing, deployment, integration testing, and functional testing.
Unit testing being, does the code work? The deployment being, let's get it out somewhere. Integration, now, that it's out somewhere, does it still work? And then functional tests, okay, we know that from a technical level it all works, but can a person use it? Like those are kind of those four different areas there. And having robust testing and having robust ability to incorporate accessibility into those testing, helps to facilitate that easier over time thing, because if you've got good regression tests in, and if they can mostly be automated, then if you make a change and it's small, but it's impactful from an accessibility perspective and you catch it early and often, well, it's okay to make mistakes. I'm a big fan of trying to create environments where it's okay to fail, it's okay to be wrong, it's okay to make a mistake so long as you can catch it early, often and resolve it and remediate it in a prompt fashion, it doesn't really change the net result of things and still makes it easy to do from a process and procedure perspective.
Next slide, please. So there's some things that we do as an organization to help facilitate this, the big one being our ARC Platform. So our ARC Platform is used by a lot of Fortune 50, a lot of Fortune 500 companies to help them manage their accessibility process throughout their entire organization. So there is sometimes a want to have an isolated accessibility department and that is important for advocacy and for management, and especially as it comes to risk management and et cetera.
But as we stated earlier, it really takes the whole system and everyone being involved to create meaningful change. And so to that end, our customers track their progress through the ARC Platform, which gives them a couple of really interesting advantages. One, lots of automation built in. Two, the ability to enter our enterprise platform, push those directly out into the development workflows.
So getting those out into Azure, DevOps, or JIRA, or Trello, or wherever it is that your development team is managing their workflow, as well as help desk, tickets and resources that can be utilized directly by the development staff. So if they say, "Hey, it's good that I know that I need to do this, but what do I do? Like I know you've told me that this is broken, but I'm not even really sure where I start." We've got some awesome utilities as it comes to learning both from an article's perspective, targeted training, and then just direct help desk tickets, a developer can reach out to us and say, "Hey, how do I do this? I know I need to do this, but how do I do this?" And we can give them solid answers on that. And then lastly, our free toolkit that's available in the Chrome Store, putting this in front of developers so that as they are creating new features, as they're creating new usage for your product, as they're testing that, they can actually do that directly at their workstation and make sure that things are accessible as a part of that initial development process. So that way, all the way from the developer who is live coding and trying to create features all the way into your development CI/CD process pipelines, and then up into your QA and functional testing, that whole realm of phase three and phase four, or phase two and phase three getting compass with some of the tools that we have available. Excellent.
So that brings us into phase four, which is the delivery process. And you would think that if you're already at delivery, you're kind of done thinking about accessibility at that point, but it doesn't stop just because you've pushed something out. In fact that's really where the rubber meets the road, so to speak. It's easy to miss opportunities for success, and it happens. And it's not something to beat yourself up about, but it's something to be aware of and to be able to address. So having the ability for users to report issues about accessibility and having a process in place that automatically prioritizes those issues, really helps to make sure that users are heard and happy.
So as an example, within our organization, our prioritization process, our top two priorities, our top priority, our critical failures. If we don't do this thing, nobody can use the platform anymore. Those are our number one priorities 'cause if we don't fix those or if we don't address those, then nobody can see the platform anymore. Directly after that, is accessibility. Is it able to be used by everyone? And so codifying those kinds of priorities into your engagement process are hugely valuable in making sure that these types of things actually get addressed from a feedback perspective.
Last year we introduced this notion of JAWS Connect. So JAWS was the largest used screen reader in the world. And we have directly tied that feedback mechanism from that into ARC and into your systems and your processes so that you can get feedback direct from screen reader users. It's an opt-in thing. It's free for websites. And then if you've got Windows applications, we can embed it into those as well for you.
So that does have a charge associated with it though. Next slide, please. Aside from those services, we also have, as I mentioned earlier, our help desk support, instructor-led training. And one of the exciting things that we've got with Dr. David Sloan is accessible UX services. So we can really help you work at all levels around how to have inclusive designs within the features that you're trying to promote and create that will drive value into your business.
So lots of really cool stuff that we have available for you from that perspective. Yeah, a couple of points, I wanna just drive home here, Chase, first of all, I think you really made a great point about ARC in terms of its overall center for managing all these different aspects of accessibility. And that would include, like a lot of people will use an organization like us to do expert manual testing. All of that is integrated into the platform as well.
So all of the automated testing that Chase is talking about, you also wanna make sure that only covers, if you're looking at it as a pure test, that only covers 30 to 40% of the actual errors. So this idea of manual testing through experts like us is super important to really understand in much greater detail where you stand and having that be an integrated part of the whole process. And we can do that on a complete code base, which is sort of the traditional way that you can see it, but through the ARC Platform and by componentizing that effort, we also can fend that into a sprint cycle. So we can fit right inside of your software development life cycle just like connecting to your CI/CD pipeline, fits early into the process. And the other thing is I wanted to circle back around to this concept of ARC, that Chase talked about this capture, ARC Connect, where, I'm sorry, JAWS Connect.
Where we're actually connecting directly with JAWS users and allowing them through the technology that they use to give real time usability feedback. This is very important because traditional usability testing can be very expensive and it happens, how often can you do it? You would do a test every so often, but when you connect to the population into your platform, you are now getting this feedback in real time all the time. So when you look at all three of those earlier points from a social responsibility standpoint, you are showing that group of people that you care. From a business standpoint, you've got a continuous ready made way to take what you're doing beyond technical conformance and really making sure it's useful for your users and build that loyalty that we talk about. And then from a legal perspective, I'm not a lawyer, but we see in a lot of these settlements that feedback from people that are actually people with disabilities using technologies is a huge component of that, it can potentially satisfy that as well.
So it's sort of a very simple concept to think about, give screen reader users the ability to provide feedback, but it hits on so many important points. And then likewise, one of the things I'll hit on real quick with this is if you're a mature organization, if you take accessibility really seriously and like you've gone pretty far down that tunnel, we also have some advanced tools available that more and more of our enterprise customers are taking advantage of, if you want to take some of that manual testing process and QA process in house, we've got some pretty interesting offers around that and feel free to reach out to us if you feel like you're at a level of maturity where you really want to incorporate more of that deeply in house. We talked through this next slide pretty much, Chase. Yeah, we pretty much talked through most of this. Got excited.
Well, it jumps the gun a little, that's okay though. So we'll talk a little bit about the pipeline, what's on the screen currently is a timeline left to right with some symbols that show the continuous accessibility process starting with development, going to saving code, packaging code to be delivered, deliver, build, to staging, or running the tests, checking the test outcome, and then delivering that build to production. If you'll hit the next thing. Overlaid are the, what parts of our platform helping each of those segments. So in the development phase our toolkit and our ARC API for unit tests, next. For delivering to stage and running tests, our ARC API test initiatives.
Next, if there is a pass, we can continue going forward to pushing to production. If not, we can go back to our development phase. There's a flow chart that shows that flow, next. And then at the end of the pipeline, once we've delivered our ARC domain or user flow monitoring, we'll help let you see in your live production environment at whatever cadence makes sense for you.
Are we making progress as a business on our accessibility goals? Next slide, please. So couple best practices to keep in mind. The big one is investing for success. If everything as a business, if you want to be successful with it, you have to align yourself for an investment. An investment doesn't just mean financial. That means time, that means effort.
And it might also mean a financial investment as well, but that depends on what you wanna do. Like all things time or money, if you've got a lot of time, then there's a lot of ways to do it. So it doesn't really cost you anything. If you're in append for time and you need a lot of effort done quickly, well, it's probably going to cost more money, that's the nature of, that's not even accessibility, that's just business in general (laughs). As far as additional best practices, we really wanna strive for inclusivity in all of your business processes and decisions.
So good example of that, we talked about these different areas of the software development life cycle. If you're not incorporating the people who are actually challenged by these things into those decision and processes, you're not actually talking to people who face these concerns, you're not really setting up for success. And so you wanna be inclusive in your hiring. You wanna be inclusive in the way that you deal with your customers. Just really try to incorporate people into what you're doing. Lean on experts, you probably have some in your organization, so I'm not just talking about us.
I mean, lean on people in your organization that care deeply about this and can offer you some good sound advice. It's often easier as a business to take the advice of the outsider, but you will find many people within your organization have some really good ideas and can be incredibly helpful in pushing forward a path towards accessibility within your business. Ask lots of questions and listen.
And then lastly, this is big for me, automate as much as you can. You want to make this process one that is enjoyable. One that doesn't feel like a burden on top of the things that you're doing. And the easiest way to create a long term investment is to invest in automation so that you don't have to tack on a lot of additional workload to your teams. Next slide.
And then I'll let Mark kind of recap on that. So to recap on sort of how we as an organization help our customers implement and achieve a lot of the different things that we've talked about today, the major categories of help that we're giving is with audits and reviews and this is that concept of us coming in looking against the technical standards for accessibility issues, as a set of experts that understand those standards and then advising on how to remediate analytics and automation. So this is a lot of what Chase has been talking about within the ARC Platform, within the monitoring and the analytics that you do around that data. UX design, so this could be looking at design comps and annotating them for best practices and issues from a technical conformance standpoint, could be testing the UX itself and then QA and verification.
So first phase, planning, integrate insights into planning using stories and code. Second, analytics, audits, this is accessible audits manual in machine detectable. The third is design, this is the prioritization of inputs in the design phase. And again, the design is not all about technical conformance, sometimes it's about best practice, it's about setting yourself up to be able to successfully include the things that you need to for accessibility. Implementation, this is, think about new features, functionalities and the builds.
We have knowledge base, we have education, we have code annotations within both of those things. We also have our toolkit that can really help that developer who's trying to include accessibility in the way they're coding, have the information, the education and the tools they need to do that. The API is open, we have a restful open API for ARC.
So you're able to integrate those checks anywhere you need to. And so at the beginning of your CI/CD pipeline, when your developers are checking code in and running that code against all sorts of other checks, you can include accessibility in that. You also wanna think about how you represent that accessibility.
Do you need something like VPAT? Do you need to look at the statement on your public facing website? Do you need an accessibility conformance statement? There's different ways that you can represent what you've achieved there. And then to Chase's earlier point, once all this stuff is done, you wanna look at it on production. You wanna make sure that everything is reaching production and in the way that you've intended and use the success you're having in that final production output to inform changes throughout that whole life cycle. Awesome.
Next slide. I think the next slide. So the thing I wanna close on is this, we're all, mostly technical people, business people, et cetera, that are here, but what I don't want to be lost on any of us is that you're dealing with human beings. These are real people with thoughts, feelings, emotions, wants and needs. And so as we're thinking about accessibility, try not to get lost in the numbers, try not to get lost in the business aspect of this and really try to remember that you're dealing with people, real people and really try to provide an inclusive experience within everything that you do within your organization.
You will be amazingly well served by it. Any closing thoughts, Mark? Yeah, the one thing that I really wanna point out here, we went over a lot of stuff, we looked at the entire software development life cycle and we introduced a lot of concepts. And some of you may be looking at that going, "Wow, you really gonna do all that?" Remember that what's important is that you take the next step. There's no light switch here. You can't go back to your organization tomorrow, do something and have all this implemented the way that we talked about today.
It's important that you understand where you're headed. That's why this discussion is super important, but it's the analogy of how do you eat an elephant? One bite at a time. So when you go back and you think about this, don't think about all of these things that you need to do. Think about the next step that's gonna start to progress you towards those end goals and to don't let this overwhelm you.
And to that end, if you ever need us to help in those conversations, if you are trying to help your leadership or business teams, et cetera, understand the importance of accessibility within your organization, reach out, we're happy to help. We're happy to guide those conversations in a way that really resonates and make sense from a business perspective 'cause sometimes they will get lost in that, and so, please reach out. And do us a favor, don't feel like you have to have a pending engagement or about to be doing business with us or anything like that. I talk every day to people and help them out without it ever turning into an engagement. Or I shouldn't say without it ever turning into an engagement. One day it may, but to Chase's point, we've seen this over and over again, don't reinvent the wheel, just give us a ring, let us chat with you a little bit and we can sort of help you think about this, even if you're not ready to make big moves yet.
Awesome. So with that, we would love to take questions. We had one question come in which I think we've answered along the way and that was one of the best tools to automate 508 testing. So there's a lot of them out there, we talked about a lot of the ones that we use.
Go take a look at our toolkit, which is free, it's a Chrome extension. That can be a great first sort of dipping your toe in the water, look at it. And then certainly if you'd like to see demos and really some of the other tools that we talked about in action, you can let me know. And I'd like to add one thing to that, we've got two major things on the automation side and that's our domain monitoring tool and our user flow tool. The best way to think about those is one's a shotgun, one is like, "Okay, I don't even know really where I need to start at, so I'm gonna look at everything," and that's our domain scanner. And then on the other end is like, "Okay, I found some areas and this section seems like it's got a lot of issues," a good example might be, if you're a hotelier signing up, booking a night, booking a flight, an e-commerce store checking out, stuff like that.
And that's where our user flows come in and those are much more of a scalpel approach, so you wanna really isolate and look at individual things and then that pipeline then feeds action. So that says, "Okay, well, I now know that there are these things wrong, I want to create action on those," and then you do it again. And then so you create a kind of circuit there, so, yeah. Yeah, the other thing I would add is that there's tools out there too that can help with the manual testing process, a lot of what we've talked about is sort of automated scanning, but when you're doing manual things like screen reader testing, obviously those assistive technologies like JAWS, you definitely wanna think about pulling JAWS in house if you're gonna do your own testing. And then we have other things like JAWS Inspect, which is very similar to JAWS, but the output is in text, so it's much more appropriate.
It's not a complete replacement for JAWS testing, but for a lot of the things that you're trying to do with JAWS testing, it can make it much easier, just simply from the fact that the output is in text, it eliminates that need to sit there and transcribe, but it presents things in a lot of other ways. So there's certainly a lot of tools to think about and we could spend another hour talking about all of them, but. Absolutely, doesn't seem like we have any other questions. Is there anybody else that has any, so we either did an amazing job or a terrible job of answering people's questions as a part of the (mumbles).
It was amazing, Chase. That's me too, that's where I'm leaning. So I tell my friends about this, I'm gonna say, "Amazing." (Chase laughing) Please let us know if you have other questions, I think, I don't know if we can open the mic up to other people. I don't think that we can. But if not, there's a Q and A in the Zoom that you can use.
Thanks, Anne. Anne says, "Thank you for, much for the great information." Have a great day. Thank you very much.
A few more minutes. Anybody has any other questions? This was great for everyone, really appreciate the time. If anyone else has any questions, feel free to send them to ida@tpgi.com and I can pass those along to Mark or Chase to answer, but thanks for your time guys and have a great day.
All right, thank you so much. Thank you. All right, bye.
2022-12-06 18:06
