- [Kari] Hello, everyone. Just give us a few minutes. We're gonna let people keep rolling into the room and we will get started here shortly. Again, thanks everyone for joining us today. We've still got a lot of people coming into the room right now, so I wanna give us another minute before we begin. All right, good morning, good afternoon, everyone. My name is Kari Kernen. I'm the Senior Manager of Sales Development here at TPGi. I wanna give one more minute 'cause it looks like we still have quite a few folks joining. So just hang tight with us, okay? All right, again, just wanna thank everybody for joining us today. I'm just gonna go through a few housekeeping items before we start. This session is being recorded and we will email everyone the recording usually about two business days after the event. We have captions available, so feel free to use those as needed. We will leave some time for live Q&A at the end. Please use the Q&A box for any questions that you have and we'll answer as many as we can at the end of the presentation. Sometimes we tend to miss questions if they get put into the chat, so please try to stick to putting questions into the Q&A box. And then lastly, I wanna mention, if anyone needs any accessibility support, training, usability testing, et cetera, I will send out an email after with a link where you can schedule a time to meet with one of our experts. With that, I will let our presenters get started and provide themselves a couple introductions.

- Hey, everyone, thank you for joining us. Super excited to present with David Sloan and Kristina on this topic, which is "Enhancing the Patient Experience: Digital Accessibility Legal Requirements in Healthcare." Go to the next slide for me, David. There we go. Okay, so I'm just gonna quickly go over, well, before I go over the agenda, I'm sorry, David, why don't you introduce yourself, and then Kristina.

- Sure, so I'm David Sloan. I'm Chief Accessibility Officer at Vispero, including TPGi. I also manage our user experience service delivery team.

- And hi, there, I'm Kristina Launey, I am an attorney with Seyfarth Shaw. I am based in Sacramento. And you know, we're all coming fresh off CSUN just south of Sacramento here, quite a bit south, and in Anaheim. And we're excited to be able to do sort of this focused webinar for you on digital accessibility requirements under Section 1557 of the Affordable Care Act in the digital accessibility, disability space. And I'm a disability access specialist. I'm a non-discrimination attorney. I advise and counsel companies, as well as litigate when necessary, but you know, the fund stuff is compliance and keeping up with all of these changes in the law that constantly keep happening. So happy to talk to you about this today.

- Great, thank you, Kristina. So we're gonna go over, we're gonna do a little reintroduction of Section 1557 of the Affordable Care Act, who's covered and what are the requirements. What Section 15, I said four, I meant what Section 1557 means for digital accessibility, strategies for meeting Section 1557 accessibility requirements. And we're gonna get started with, well, first of all, I wanna just quick disclaimer here. So Kristina, do you wanna go over this disclaimer since I think it's primarily yours and then you can start us off?

- Yep, this is the legal stuff we're required to put up here. The disclaimer essentially says that this presentation is for informational purposes only. As an attorney, I can't give legal advice other than in a privileged attorney-client relationship. And we don't have one of those here. So this is purely information. If you have specific questions, you should consult an attorney. So there you go.

- Good job.

- All right, reintroducing Section 1557 of the ACA. Why do we say reintroducing? We'll tell you that in a minute, but first we'll level set on what is Section 1557 anyway? Well, it is a regulation implementing part of the Affordable Care Act, which was enacted in to law under the Obama administration that prohibits health programs and activities that receive federal financial assistance, which we often call FFA, from discriminating on the basis of race, color, national origin, disability, age, or sex. So pretty much a large gambit of protected classes fall within the scope of Section 1557. We're only talking today about the specific provisions that apply to disability, but as you probably saw in the news somewhat recently, there are other parts of this regulation that have already been under attack, but today, we're just focused on disability and the requirements relating to effective communication, et cetera for individuals with disabilities under Section 1557. As you see in the first bullet, it's not just programs and activities of entities that receive federal financial assistance, which means, you know, it's not necessarily the federal government. It could be a private company or private healthcare entity. It is also though state-based health insurance exchanges and health programs and activities of the Federal Health and Human Services agency. All of those together are called covered entities for purposes of the regulation. So with that very broad overview of what Section 1557 does, we'll talk about why we're saying we are reintroducing it. Well, we're saying that because it's not new. As you can see, the Affordable Care Act was signed into law in 2010. And as happens with a lot of the laws we have, really seems like most of them, especially in the disability access space, you have a statute, which is what we think of traditionally as a law that has gone through Congress and been signed into law by the President of the United States. Title III of the Americans with Disabilities Act is one such example, Title II is an example. Really the Americans with Disabilities Act, the Rehabilitation Act, those are statutes. And then you have part of that statutory scheme often says, you know, we are empowering whatever, you know, fill in your executive branch administrative agency to promulgate regulations that basically set forth more detail about how the requirements of the statute are intended to be carried out. And with Title III, for example, of the ADA, those regulations are in the 2010 regulations, as it applies to physical accessibility or as it applies to Title II of the ADA, we've all talked about this before. It's the regulations that were enacted last year with respect to website accessibility. In this context, the regulations implementing Section 1557 of the Affordable Care Act were originally issued in 2016 by the Health and Human Services agency, the HHS, that is the administrative agency charged with enforcing the Affordable Care Act. So when we talk about the Section 1557 regulations or Section 1557, we're really talking about the implementing regulations of this part of the Affordable Care Act, which can sometimes be kind of confusing. And it's not that unusual, right? Law gets signed into law and then the administrative agency starts the process. To enact regulations, they have to go through a advanced notice of proposed rule of making, we call it an ANPRM, and then a notice of proposed rule making, an NRPM. And then they seek comments and then they finally issue the regulations. So that's why you see that six year difference between the law being signed into law and the regulations going into effect. So then administration changes. And the Trump administration Health and Human Services agency in 2019 began the process. So that's the notice of proposed rulemaking, advanced notice of proposed rulemaking process to rescind and replace a large portion or portions of the 2016 regulations, which the Trump administration contended exceeded the legislative authority. So the authority that Congress had given the administrative agency in the statute. Or that were unnecessary or duplicative. So in 2020, the Trump Health and Human Services agency's office for civil rights, that's what OCR is, published the revised Section 1557 final regulations. So as it says in the previous bullet, essentially those new regulations pulled back and replaced large portions of the 2016 rule. So a lot of US practitioners were looking at comparing the 2016 to the 2020 saying, okay, what's changed? And then Biden comes in, administration changes again, and he began the process, or his Health and Human Services agency began the process to restore and expand even further the 1557 regulations from what they had previously, pre-Trump, been. And that process finished in 2024. So as you can see, you know, in both administrations, they started the process fairly early on in their administration, but the regulatory process didn't really end until right about when they were going outta office. And then the new president comes into office and they start the process to change the regulations and it takes about their whole administration here. So in 2024, the Biden new Section 1557 regulations went into effect and they restored some of the repealed 2016 regulations and they added new provisions to enhance non-discrimination requirements to which the covered healthcare providers must adhere. So the big question that is raised by all of this before I, you know, in the next slide in a minute, will tell you the high-level overview of where we are now in terms of what is required under Section 1557. but the big, you know, question is, is what we're telling you today not gonna matter tomorrow? Now that the Trump administration is back in, are they gonna repeat what they started in 2019, 2020 to pull back all these regulations again? Well, based on what we've seen already from the Trump administration, I would not be surprised whatsoever. As I'm sure so many of you saw, you know, pulling down the White House accessibility information page right off the bat, the other actions they've been taking, and they've even attacked other parts of the Affordable Care Act already, we would not be surprised at all, but it'll probably take, because this is not just something he can do by executive order. He has to, like he did the prior term, go through the regulatory process again, which takes time by its very nature. So if he rolls back the regulations to what they were during his administration, it'll take some time, but again, just like he did the time before, he won't roll them back in their entirety. He might take away, you know, the accessibility coordinator provision, some notice provisions, et cetera, but until then we have what is still in the law, which is what I'm gonna give you a high-level overview of now and then Mark and David will go into more detail. Okay, here is your high-level overview of what Section 1557 requires, with a focus on disability access, since that's our focus today. And remembering, though, that this is not like Title III of the ADA, it's not like Title II of the ADA that's focused only on disability as a protected class. Other protected classes are covered under this law as well, but first of all, 1557 requires covered entities to take steps to ensure that communications with individuals with disabilities are as effective as communication with others. Really same effective communication requirements as under Title III and Title II and other laws as well. Provide auxiliary aids and services, such as alternative formats, sign language interpreters, where necessary for effective communication at no extra charge, of course. And as you can see in the fourth bullet here, make all programs and services provided through electronic and information technology accessible to individuals with disabilities, unless doing so would impose undue financial or administrative burdens or result in a fundamental alteration in the nature of the covered entity's health program or activity. Now, those exceptions really apply to all obligations, but those are quite often a difficult bar to meet in terms of exceptions. In the Title III context, electronic information technology is an auxiliary aid or service that might need to be provided at no extra charge to ensure effective communication. Under the 1557 regs, it's there as well. It's just, you know, stated in slightly different terms, but really with the same effect. 1557 also requires that a notice of individual's rights be posted, which provides information about communication assistance as well as other information. Also, this is something unique to 1557, the regulation clarifies that covered health programs and activities offered via telehealth must be accessible to individuals with disabilities as well as individuals with limited English proficiency. That specific provision is something that's unique to 1557. At the bottom of the slide, I have as stated by the HHS since 2016, and I have the, the website URL there. I put that in there because it's, you know, I just told you all the back and forth, right? And as I think we've mentioned in other webinars and presentations, there are some things that some administrations, namely the current administration, has done where they've tried to pull down, you know, from the DOJ or from OCR'S website prior guidance, but here's one that you Google it and it's still there and it says it's been there since 2016, essentially stating what the summary of the 1557 provisions are. So on the next slide, we have the last couple high-level points about what Section 1557 requires. And these are not effective communication provisions, but just to give you a flavor of the fact that the scope of 1557 is fairly broad. It's not just an effective communication regulation. It also requires compliance with the 2010 ADA standards for physical accessibility for new construction and alterations of buildings, although, you know, they even say almost all covered entities are already required to comply with these standards under Title III of the ADA or Title II. It also says, though, that there is a prohibition on using marketing practices or benefits designs that discriminate on the basis of disability. And finally, and again, not finally finally, but finally for our purposes today, because the regulations do have quite a bit of provisions in them, but finally for our purposes in the high-level overview here, 1557 requires reasonable changes to policies, practices and procedures where necessary to provide equal access to individuals with disabilities unless the covered entity can demonstrate it would constitute a fundamental alteration of the nature of the health program or activity. That's really an equivalent to the, you know, reasonable modification of a policy practice or procedure requirement of Title II and Title II of the ADA as well. So with that, Mark, shall we dig in a little deeper? Or David.

- Take over this part, yes. Thanks, Kristina, for setting the scene. This next section is really kind of focusing on, if you're working in digital accessibility, what does Section 1557 mean in terms of requirements? Well, firstly, Section 1557 specifically references a range of technologies covered under this umbrella term, information and communication technology, ICT, which is defined to include, amongst other technologies, websites and mobile apps, video, electronic documents, kiosks, information-providing kiosks and transactional kiosks where you might be paying for something or providing information and receiving something else in return, telehealth services, as Kristina said, and decision support tools that physicians might be using to help make decisions in providing healthcare. So all of these are specifically named in the definition of information communication technology. The requirements are covered in Section 92.204, Accessibility of Information and Communication Technology for Individuals with Disabilities. And they're presented in two e-clauses. Firstly, as we've heard already, health programs and activities provided through information and communication technology, any of those technologies that I mentioned a couple minutes ago, any of those health programs and activities provided through ICT must be accessible to individuals with disabilities. So that's a very general requirement that's open to some interpretation depending what it is you're providing and through which kind of technology, but then a more specific technology requirement, health programs and activities provided through websites and mobile applications must comply with corresponding requirements of Section 504 of the Rehabilitation Act. And we'll uncover what that means in this slide. So essentially the web and mobile app requirements are more specific and they are defined in another rule, which is subpart one or I web, mobile, and kiosk accessibility of the Section 504 non-discrimination rule. This is the non-discrimination on the basis of disability in programs or activities receiving federal financial assistance, which was published in May of last year. And essentially, in other words, if we boil down this entire presentation to one bullet point, this means that web and mobile apps providing healthcare programs and services must conform to level AA of the Web Content Accessibility Guidelines Version 2.1. This may sound like a very familiar requirement, and it is. It's harmonized with this equivalent rule from ADA Title II on web content and mobile app accessibility. So we have harmonization between the Section 1557 requirements, the Section 504 HHS requirements and the ADA Title II rule requirements, which could hopefully make it easier for technology, certainly web and mobile app content and service providers who might be working with healthcare providers and other providers who are subject to ADA Title II, the same technical requirements apply across the board there, which certainly an accessibility harmonization of requirements, at least from a technical standpoint, can help make it easier to understand what to do and to implement processes for meeting those requirements. The deadline for conformance for this technical requirement is set by the size of the covered organization. So May 11th in 2026 for organizations with 15 or more employees and May 10th, 2027 for smaller organizations. And again, that reflects a general trend to give smaller organizations more time to meet the requirements on the assumption that they may have less resources to attend to the technical requirements that need to be met. As Kristina mentioned earlier, there are some exceptions to the ICT accessibility requirements. Those familiar two clauses that are present in many disability rights are non-discrimination laws and rules. The undue burden exception, where meeting requirements would be considered to create an undue burden from a financial or administrative perspective. And the fundamental alteration exception, where implementing the requirements would so significantly change the functionality or purpose of the technology that it would be considered a fundamental alteration. Both of those are exceptions that could be claimed potentially by organizations otherwise who would be required to meet the accessibility requirements. There are also exemptions defined in the Section 504 rule that Section 1557 references. And these exemptions are the same as for the Title II rule for web content and mobile apps for the ADA. So archived web content, pre-existing documents, content posted by a third party, typically social media messages and other information that was unsolicited by a third party but is present in a covered entity's website or mobile app, individual password-protected documents, and pre-existing social media content. Now, the individual password-protected documents exception or exemption is one that's a potential point of debate given that it could apply to individual electronic health records or other sensitive information that's password protected. Potentially it could be interpreted that accessibility requirements don't apply to that password-protected personal information that might be present in an application that's providing access to healthcare programs and services. And that might be something that we come back to at the end of the presentation, Kristina, to talk more about the interpretation and implications of that exemption. Other exemptions that are mentioned, including, again, mirroring the ADA Title II rule, when a conforming alternative version is available. This seems to be a bit of an edge case where a particular website or mobile app does not meet technical requirements, but another version of it exists that allows people, or that meets those technical requirements and allows people to access the same programs or services. And then the final exemption, when non-conformance has minimal impact on access. So this is essentially to say, well, if the technical requirements, in other words WCAG 2.1 AA, are not met, but it is determined that despite that, person with a disability can access the same information as people without disabilities, engage in the same interaction as people without disabilities, conduct the same transactions as people without disabilities or otherwise participate and benefit from the same programs and activities as people without disabilities, then that's considered minimal impact. And again, that's open to interpretation in a given situation, whether non-conformance has minimal impact or whether in fact there is impact and therefore the exemption would not apply.

- Real quick before you move on from those, just one quick note, which we can talk about later perhaps as well, which is, I've received questions from clients saying, well, don't we fall within the exception, you know, neither 504 or Section 1557? And especially if it's in the context of a lawsuit that they're facing under Title III of the ADA, for example, if they're a private entity that's also subject to that law, you know, the answer is not clear. I mean, and often we can say that you can refer to those exemptions and say that they should apply in this context as well, but because we don't have Title III regs yet that say this specifically, you can't say this absolutely applies. Instead you just have to make the argument by analogy. So it's important to remember that you might be subject to multiple different disability access laws, not all of which have the exact same requirements and protections.

- Sure, and in whatever case, claiming an exception or an exemption doesn't necessarily mean it's okay to sit back and do nothing. You still have to justify that exception or exemption and take all action that you can take to improve access to programs or services for people with disabilities. So it's not essentially an, you know, a reason to do absolutely nothing. I wanna talk briefly about kiosk requirements. We heard earlier that kiosks are specifically covered in the definition of information and communication technology and kiosks are becoming increasingly present in healthcare situations to provide programs and services, you know, whether it's checking in at, you know, before an appointment or making payments or whatever. So kiosks are explicitly called out in the related Section 504 HHS rule, in Section 84.83, no qualified individual with a disability shall, on the basis of disability, be excluded from participation in, be denied the benefits of, or otherwise be subjected to discrimination under any program or activity of a recipient provided through kiosks. So that's a pretty broad and vague requirement. And again, we can probably tease apart just exactly what it means from a technical perspective, but what we do know is that there are no specific technical requirements that mirror or that stand alongside the web content and mobile app accessibility requirements that I mentioned a few minutes ago. And in the description that HHS provided when putting together this rule, there was an assumption or an apparent assumption that we would see some technical accessibility requirements for kiosks expressed in a rule towards the end of last year. That rulemaking process was withdrawn earlier this year, and it's unlikely that we'll see a specific rule on kiosk accessibility anytime soon. So in the absence of that more specific technical requirements definition, the best practice really for kiosk accessibility is to take whatever steps possible to ensure that people with disabilities can use them independently and without loss of privacy. And that might be referencing existing hardware and software accessibility guidance that are provided in standards such as the Section 508 ICT standards, the 2010 ADA accessibility standards, and also the European standard EN 301 549. None of these standards are specifically mentioned in the Section 504 rule or in Section 1557, but they exist as information to guide kiosk manufacturers to include accessibility in hardware and software design. EN 301 549 is of particular interest because of its relationship to the European Accessibility Act. For any kiosk manufacturer, whether it's hardware or software or combination of both, who will be selling to other entities under Section 1557 and also organizations who operate in the European Union, then following the AA requirements for kiosk accessibility or self-service terminal accessibility will ensure that the kiosk meets a high level of accessibility, and hence will help to serve patients with disabilities in the US as well.

- David, I have a quick comment here. In 1557, it says that information kiosk and transactional machines, right? So one of the things, if you're looking at this and you're thinking about your own scenario, broaden your definition of what traditionally, at least I would think of as a kiosk. When I think of a kiosk, I kind of think of like, you know, a large machine that you might walk up to and interact with, but it could be something, and this is me editorializing a little bit because it's not more defined than what I just said, but I would think about any, what we would call enclosed system. So it could be a tablet that's handed to you that you complete a transaction on. It could actually be a dedicated PC that's sitting on a countertop that is specific for filling out a form or something like that, but you don't think of it as a kiosk because it looks like the computer that you have at home. So as you're thinking through that, just think about enclosed systems, so they have a dedicated hardware-software combination that provides a service to you, because that might be covered.

- Yeah, absolutely, I think computing technology is one of the examples given of in information and communication technology, and yeah, a PC that's sitting at a front desk that people can come in and use independently to check in, but as you say, it's locked down. There's no way for somebody to install a screen reader on it or connect an input device, a switch or some other voice input. That piece of information communication technology would need to provide the necessary accessibility support to allow somebody with a disability to be able to use it independently. Some of the other applicable requirements in the Section 1557 rule, you know, have connections with digital accessibility, depending on whether they may need to mention accessibility or may need to be implemented in an accessible way. So for example, there are specific requirements for the duties of an organization's Section 1557 coordinator. And that might include coordinating digital accessibility policy or program management to make sure that the covered entity's digital accessibility efforts are aligned with its Section 1557 responsibilities. The policies and procedures that are defined in Section 92.8 in Section 1557 may, you know, include a non-discrimination policy, a grievance procedure that would need to be implemented if somebody made a complaint about an instance of digital inaccessibility. So that grievance procedure needs to recognize that instances of potential discrimination may apply in the digital world as well as the physical world and the effective communication procedure that is required needs to consider how that applies digitally and, you know, take into account what it means to provide effective communication through digital means, and whether digital means can also support communication in the physical world. Staff training is is defined in 92.9 of Section 1557 rule, staff training may also need to include digital accessibility responsibilities, what knowledge and skills and supporting tools does staff need to have in order to make sure that digital accessibility requirements are met in the course of their duties. And then in 92.10 of Section 1557 rule, providing a notice of non-discrimination on a health program or activity website, well, that's making sure that the content includes this notice of non-discrimination, obviously that notice of non-discrimination must itself be presented in an accessible way. So that kind of summarizes the digital accessibility requirements of Section 1557. I'm now going to hand over to Mark to talk us through some strategies that can help covered entities and their suppliers in meeting Section 1557's requirements.

- Thank you, David, and thank you, Kristina. So really what we're gonna get into now is we've learned about 1557 and you may be thinking like, this is all well and good, but what actions do I need to take to actually start to conform to the regulation? And what I would say is, first off, is that, you know, there's no light switch here. You're not gonna turn around and in a very short amount of time, in most situations, shore up everything that you would need to. So the actions that you can take are, first of all, start off with inventorying your existing digital resources to establish what you have in scope. You know, just like we talked about with the kiosk example, you might not even quite realize everything that's out there that you may have that's covered. So an activity to discover that becomes super important and as you are doing that activity, thinking about areas of prioritization. So what is used most versus what may not be used as much, because you're not gonna be able to do them all at once, right? You're gonna have to move through this like any other thing that you do. Once you have that, it's really auditing existing resources to identify those barriers. And as David talked about it, there's a reference to the WCAG 2.1 level AA guidelines. So one of the places a lot of folks start is with what we would call a manual technical audit against those guidelines. So that is an audit that is specifically searching for the variances to those guidelines. And a good audit in that way will also help prioritize the issues so that you understand which issues, which variances are actually creating more significant barriers versus things that might be creating inconveniences, so that you can start with those more severe issues as a way of prioritization as well. So when we say prioritize remediation efforts, that's really what we're talking about. What is gonna, in the shortest amount of time, have the largest impact on people with disabilities' ability to access whatever asset you're talking about. And then further applying that prioritization to your list of assets overall. And then in the interim, you really want to think about how are we gonna support people affected by known barriers during this period of time when those barriers are being remediated? Just because you don't have something fixed yet, it still becomes important for you to have a way for individuals to get access to the information or whatever it is that they're looking for that they need.

- Yeah, and I think I would just add, Mark, that this is a very pragmatic strategy. You know, ideally you fix everything and you demonstrate that your covered digital resources, your ICTs meet the applicable accessibility requirements. So web and mobile apps meet WCAG 2.1 level AA. The reality is that many organizations who are covered by Section 1557 will have limited resources and capacity to fix everything immediately. And it's much more practical to take a prioritized remediation approach based on factors such as the severity of the issue. You know, how severely does it affect people who are affected by that barrier? And also how complicated is it to fix that barrier? So something that's easy to fix and has a high impact on accessibility is something you're good at the top of the priority list. And once you fix that, then sort of develop momentum, then you can move on to the other barriers identified in the list. And having that documented progress helps you understand where you lie in terms of improving access.

- Do you have something to add, Kristina?

- I was just thinking about David's comment about a lot of entities having limited resources and I think really this point is spot on, but almost more accurately stated that they don't have unlimited resources because not sometimes, quite often, especially when we're talking about this broad of scope and you're talking about a healthcare entity that might have checking kiosks 'cause it might use iPads for things, it has various websites and telehealth. And you know, that's a lot and it's takes a ton of time, a ton of money, a ton of personnel and, you know, requires working with vendors too because sometimes the technology's totally out of the healthcare entity's control. So it can sometimes be a much, much larger task than anybody could possibly imagine.

- Excellent, thank you, both. All right, so building capacity to provide accessible digital resources. So how do you increase your organization's capability around doing this? One of the things that we saw early on in accessibility were organizations who, you know, coming in doing, something like we mentioned before, like an audit and sort of moving on after that. And most folks now understand that that's not a great strategy because you fail to maintain what you've achieved and you, over time, start to reintroduce risk of non-compliance with things like what we're talking about today. So some of the things that you can do to start to ensure that your organization really is equipped to handle all this is, first of all, provide your content creators, right? People who are creating that digital content with role-based accessibility training. And what we mean by role-based accessibility training is, are you a developer? Are you a designer? Are you contributing, you know, are you a content contributor? Are you in management? Are you managing folks that are responsible for producing ICT digital content? Each one of those different roles is really gonna have a separate, or not completely distinct, but a role-based set of knowledge that they're gonna need to have in order to continue to deliver and maintain the accessibility of the assets. Integrate accessibility into process for creating new digital resources. If there's anybody here that's in the technical side of things that's listening, you guys will understand this as shifting left. And what that basically means is that change your cell, change your situation from continually looking at the production version of things. So the website that you have out on the web or the application that you've deployed. Shift from looking at that and fixing that to building into the process of creating and updating those things' accessibility so when you release that new website, when you release that new application, it's as close to accessible as it can possibly be and it doesn't introduce itself into the public or introduce itself client, customer, patient facing with accessibility issues or as many accessibility issues. Invest in and make use of automated testing and scanning tools. Many of you may understand that automated technology cannot find all of the variances to the guidelines that we've been talking about today. So WCAG 2.1 AA is the relevant guideline here today, but they are very, very good benchmarking tools. So they can help you understand your state of accessibility. So are you increasing the accessibility over time of this asset or is the accessibility being maintained? Or did something occur? Was there new features, functionalities, content introduced into something that was accessible that has now decreased that accessibility? And you can scan through automation relatively easy and often and it tends to be a real budget friendly thing to do. So it's a great kind of early warning system, if you will, or measure of progress that can be used to make sure that you're on track, staying on track and alert you if you've fallen off track. The final thing here, we've talked a lot about the regulations and it tends to be where we, in guidelines, like the WCAG guidelines, and that tends to be where we head when we start to think about these things. What are the set of criteria, what are the set of things I can do, I can check off, like when you go get your car inspected, that says, Hey, I've done this thing and I'm all set. And we don't really have a perfect way to do that in scenarios like this, but one of the things you wanna start thinking about is once you have addressed everything you can related to the guidelines, is bringing people with disabilities in to do actual user research, right? In my opinion, I think, you know, a technical performance against the guidelines is a great first step because it ensures a general level of usability. I always say it's kind of like having a car looked over, making sure that the tires are inflated and the engine runs reasonably well and that it does the basic functions of a car before you put a driver in it to tell you how well it drives, right? But if you really wanna understand if that car is performing the way it should, you need that driver to say, oh, you know, the brakes stick or you know, it shimmies when I try to turn to the left or something like that. So involving people with disabilities, the people, nothing about us without us, right? Involving the people who are actually going to need to use the software. And the accommodations you're trying to make for them and getting feedback from them is very important and it's an extremely positive and good next step to ensure that you're meeting the requirements and the requirement for those people to be able to access the ICT. And then the other place to start to look is in the procurement process of your organization. So are you purchasing, do you have a way to evaluate tools and things that you're purchasing that may be part of that ICT and to ensure or to open up dialogue with those vendors that you're purchasing it with around accessibility so that you're creating a more consistent experience regardless of how that ICT is entering the organization?

- Yeah, I think it's important to, you know, to recognize that there may be people in this webinar who work for covered entities and also people who work for organizations that supply healthcare providers with digital technology. The law applies to the healthcare program and service provider as the covered entity. So ultimately even if you are outsourcing ICT product development to a third party, you have the responsibility to make sure it's accessible, which means managing that relationship in your supplier agreements and understanding what happens if you are given a technology by a third party that you've contracted and it contains accessibility issues, how do you manage that scenario? And on the other side of the fence, if you are a supplier to the healthcare sector and you provide technologies, it's in your business interests to focus on accessibility, reassure your customers that you are providing ICTs that meet the technical requirements of Section 1557. And you know, that provides added value to the attractiveness of your products that you're helping your customers meet their obligations. So accessibility and procurement is such an important part of this jigsaw puzzle, of digital accessibility strategy. So I think we're almost at time. We will finish with a conclusion. And really, you know, Section 1557 of the Affordable Care Act is a general non-discrimination rule that provides healthcare providers with requirements for, amongst many other things, disability inclusion, and that includes digital accessibility. The technical requirements specifically for web content and mobile app accessibility are the same as for the ADA Title II requirements, that is WCAG 2.1 level AA. For those of you who are familiar with web accessibility, that is not the latest version of WCAG. We are currently at version 2.2. So by all means adopt WCAG 2.2 and go further than the Section 1557 rule requires, but certainly focusing on, at a minimum, meeting WCAG 2.1 level AA will help you meet the requirements of the rUle. And as we've just heard from Mark, implementing a strategy to, firstly, assess and remediate existing resources and secondly, to build organizational digital accessibility capacity can help you meet the requirements of Section 1557 and ultimately provide more accessible, useful and usable healthcare programs and services for people with disabilities. So at this point I think we can move to taking any questions that may have come in.

- Yeah, it looks like we had a couple of really good ones here.

- Yeah, and Kristina, why don't you start? I think a couple of these are for you.

- Yeah, that sounds great. So the first two here, the first one, the first two are great, and the third one is not a question but is actually a comment that is equally great. So we'll we'll make sure to mention it to the crowd also, but the first question, "do accessibility standards for ATMs and/or airport kiosks exist? And if so, are they useful guidance for the planning and design of accessible healthcare kiosks?" So first of all, yes, there are some standards for ATM and/or airport kiosks, but they are in very specific contexts. So the Air Carrier Access Act is another industry-specific act that applies to the airline industry. And within the Air Carrier Access Act, there are requirements for airport checking kiosks that have been in place for a couple years now. And that is a good place to look for guidance on designing kiosks that are accessible. There are ATM standards in California regulations, but to my knowledge offhand, and I have to go back and check my notes, I don't believe there are anywhere else, but there are in California. And we look to all of the really analogous accessibility provisions when we are advising clients on how to really scope an accessible self-service technology or as Mark said, you know, a closed device. We call 'em any sort of self-service technology, right? I mean you can look at what the different components are of that technology that might require someone with various types of disabilities to need different functionalities of it so that they can use it. So physical accessibility requirements, web accessibility requirements, both for hearing related disabilities and vision related disabilities, dexterity requirements, all sorts of different things. We pull in different requirements from either the Title III regulations or the ACA 1557 regs, or if there's nothing in there, other specific regulations that might be analogous, or then you just go to best practices. Here's where I say that Mark didn't plant this question with me on purpose, but we also always call up Matt Ater at TPGi because he is really the guru on everything self-service technologies and kiosks and does an amazing job in helping companies and covered entities who are deploying those sorts of technologies to make sure they meet all requirements that are applicable and are accessible. I also have a guide, and Mark and David, I don't know if have this, but a couple years ago now, I mean might have been 2020 or so, at CSUN, a team from HP did a presentation and they made available to everyone this guide that they had put out on accessible technologies. And it's a great summary of some of the requirements that might apply. I don't know if they've updated it since then, but I often refer to that also. So that's the first question. David and Mark, any comments on that before we move on to the second one?

- Yeah, I think I'll just echo that, you know, there's definitely convergence in standards to some extent around the world. I mentioned the EN 301 549 standard and the European Accessibility Act. There's also the Canadian standards have produced a standard for self-service terminal accessibility as well. And generally there's alignment, there may be slight adjustments. So for example, in Canada, the standard requires, you know, specific provisions for being able to choose which language, English or French in an accessible way, but generally there's good alignment. And we definitely encourage people to check out those standards and follow 'em as far as possible.

- Great, and the second question here is a request for a clarification. It says that "what you said to the effect that there is an exception to the requirement if a conforming alternative version is available. Conforming alternate versions are generally prohibited because they are, in essence, a separate but equal approach to accessibility. Rather conforming alternate versions are only permitted when it is not possible to make web content directly accessible due to technical or legal limitations." I'll let David speak to the specifics of the point he was making, but I will say generally, and this goes to the point I made about even if you can rely on an exception in theory under Section 1557 or another law, you do also quite often have other laws that apply as well, like Title III of the ADA. And you're right that you do need to think about that consideration. Is the alternate conforming version one that is something that would be considered separate but equal? Or is it right next to and equal to the other version? 'Cause sometimes there is not a way to make version number one accessible. I know that's a less and less happening now, but it does still happen sometimes, where version one just can't be made accessible. So the best you can do is provide an accessible alternate conforming version that's easily accessible right next to it, but it is absolutely an excellent point that you gotta make sure that if you update version one, version two is always updated contemporaneously with it, because you know, one of the fears that is noted in the Air Carrier Access Act where it specifically prohibits any sort of separate but equal website is that the separate accessible website will not be updated, while the primary website will, and then it's not equal at all. So David, other points on that?

- Yeah, no, I agree with you and I also agree with the request for the clarification and I just want to emphasize that the conforming alternate version is only, you know, there are only very, very specific situations where it would be an appropriate and justifiable approach to take a real edge case situation, where, as the David Kingsbury, who made the question there, said, you know, when it's not possible to make the content directly accessible, directly meet the requirements due to technical or legal limitations. Yes, it's an edge case exception and in most case would not be applicable. In the vast majority of cases, it's appropriate and required that the main resources remediated to reduce any accessibility barriers and ensure conformance.

- Okay, and the last point. Mark, did you wanna comment on that one before we wrap up?

- And this is another sort of point of clarification or probably more accurately, just additional context around something here. And it says integrating accessibility from the design phase where designers can prioritize accessible Figma or UI/UX design and automated accessibility during CI/CD pipeline, which is continuous integration, continuous development pipeline, so early on, will also decrease lots of manual audit efforts and you'll get less issues over webs, get less issues over websites and applications. So you'll create websites and applications with less issues. And it's a good point. And the term shift left mean, you know, if you're in the design world, that's essentially what it means. And all the way left is design or actually more accurate requirements, which would be the next, like, it'll show up in design if in your requirements, you're including accessibility. So I think it's a great additional detail and clarification and it just drives home the point that you can't, you know, you can't be too inclusive of accessibility in any part of the process, that the more you include it, the more likely it's gonna be included and it's gonna end up in the production version of whatever you're building, the less expensive it will be. That's something that we didn't really talk about, but there's some great numbers by IBM in terms of, if you think about accessibility issue like a bug that affects people with disabilities. So in terms of where you find bugs in the software development life cycle, the earlier on, so finding it in the design phase is much less expensive to fix it there than if it persists all away to the actual production. And it's also easier, so it just takes less time. It's usually avoid a lot of unnecessary remediation, as this person pointed out. So thank you for that. And I think it's the end of our questions, right?

- End of our questions and end of our time.

- Time, we're one minute over. So thank you, everyone, I really appreciate it. Like we said in the beginning, if you need help with any of this, TPGi is here to help you. If you have any further questions, please feel free to submit 'em in writing and we will be happy to answer those.

- Thanks, everybody.

- Thank you, everyone.