Accessibility for Complex Components and Interfaces

Speaker 1: All right folks, and we're back. Ready to get going with another talk in Wagtail Space I'm more than thrilled to introduce one of our speakers from University of Pennsylvania today. Kara Garrup is the Senior Web Accessibility Analyst here at the University of Pennsylvania, and she's going to talk to us about accessibility for complex components and interfaces.

Speaker 2: Hi everybody. Thank you so much for having me. So I'm Kara Gorep, I'm the Senior Web Accessibility Analyst here at UPenn Some of the things that I do in my role is I evaluate all of our different types of websites and web applications for accessibility. A lot of times I also hop into remediation work and I also work directly with our vendors to evaluate both their tools and services that they may be supplying or To I order review any documents that they may send over, less things like feed pads in order to ensure that anything that we buy is accessible Uh this is all a really kind of long way of saying that I spend a lot of time uh looking at how code is implemented This is on websites and applications, pretty much anything that we put out on the internet

Speaker 2: here at the University of Pennsylvania, I have to make sure it's accessible to all different types of users. When we start thinking about more of these more complex uh interfaces, so less like brochure sites, right? Like if I'm just spinning up a marketing site, those are more static pages, uh, you know, not as dynamic content, uh, you know. But when we start looking at, let's say, you know, process or a workflow for, you know, how does a student add or drop a class? How does somebody go in and update their financial information? What do our HR systems look like? These are now asking a lot more of a user both to input information, get information out of it, but also a lot of times that content is changing dynamically. So anytime that we are working with those types of interfaces, we need to make sure that we're paying extra attention for accessibility for this type of advanced functionality.

Speaker 2: One of the main reasons for that is is because it is incredibly hard to uh remediate uh some uh some of these types of interfaces once they've already launched. When we get a ticket saying, hey, a screen reader user wasn't able to complete this whole process. You know, if we've never uh you know taken accessibility and consideration for that. That can be very time intensive and it can be really expensive to remediate. So before kind of going into uh you know the specifics of these complex components, want to give kind of a very high level um overview. of how assistive technology works in case uh it in case you are unaware. Um so some uh screen reader fast facts um uh The most popular if you are on desktop, most

Speaker 2: screen reader users are going to be using a Windows-based screen reader So that's going to be your uh like NVDA or your Jaws. About 78% of uh screen reader users will be using uh those tools. Now, however, if you're on a mobile device, chances are you're going to be using VoiceOver, which is iOS's or you know, or Apple's screen reader. And that's 91% of screen reader users on the mobile device. Screen readers are also highly customizable. And there are two main settings that a screen reader user is likely to change. The first one is going to be verbosity. So that is basically how much speech feedback that user needs. kind of mostly depends on the uh the severity of uh your visual impairment.

Speaker 2: So as an example, if you have uh partial sight or uh or dyslexia you may have your verbosity settings turned all the way uh down because you only really need it for the content that's on the page because you still have some site you know so you can see if things are buttons or not Uh but on the other hand, if you are let's say fully blight or hat or fully blind or have a more severe visual impairment, you're likely to have those verbosity levels uh turned all the way up. So that way you can get all the additional um descriptions and metadata from those elements So if, for example, if I'm going through a table, if my verbosity settings are turned all the way down low, you know, I'm probably not going to hear the column or the header date being repeated. But if I have those that setting turned up, I'm going to hear a lot more information.

Speaker 2: The second setting that screen reader users are likely to change is the reading speed. So in English, your typical reading speed is going to be in around like 120 to 150 words per minute. But advanced screen reader users can listen to words up to sometimes 450 words per minute. So that is in Incredibly, incredibly fast. There's also a myth out there that Java that screen reader users have JavaScript disabled, so you can't add uh dynamically add things via JavaScript, but that's no longer true Almost 100% of screen reader users will have JavaScript enabled. I have some resources on this slide. At the end of this presentation, I'll have a QR code and a link to get these slides so you can have these resources But I'm I'm always going to uh at least these top two sites under resources.

Speaker 2: The first one is the WebAIM screen reader survey. So uh WebAIM um is a subset of the W3 And they uh every year, every other year they put out a screen reader survey. So things about what are the most popular screen readers, what are some preferences screen reader users have And then also really importantly is what types of combinations between screen readers and browsers do screen do typical users use? The second one is caniuse. com. So this will be if you put in different HTML or CSS attributes or roles into can I use it'll pull up a nice little graph of uh you know any type of known issues that uh that are out there.

Speaker 2: Uh so you'll be able to see it's like, all right, well you know Let's say I want to add this attribute to my custom element. Well, it turns out that does not uh the latest version of Firefox doesn't support it. So this is also a good way to kind of validate what type of accessibility support your code may have. The third one is Power Mapper. They do a decent amount of screen reader tests. I do not recommend anybody who is not familiar or doesn't rather It's good to know how screen readers work, but you should not learn how to use a screen reader just for testing because the way that you use a screen reader may be different than or is likely to be different than somebody who actually uses it every day There's a very steep learning curve. So this website, uh

Speaker 2: PowerMapper, has a bunch of screen reader tests where it'll show you the different types of support for uh Code implementation and what is likely to be read out loud by screen readers at their factory default settings So a quick relationship overview of how code on a page gets to a screen reader. You have your HTML, so these are going to be your button, your button tags, paragraph tags, headings like that. The DOM represents that structure dynamically. And then the accessibility tree basically captures all of the accessibility information from that DOM. and pushes it out to an accessibility API. Accessibility API is a browsers have them, your operating systems have them, but it's basically just a way to uh let

Speaker 2: the information that's on a web page and assistive technology interact with each other. So once an assistive technology gets all of that information exposed to it, it can then interact with that website. So now we're going to go into some challenges of complex components and interfaces. So again, websites, you know, static content, you know, and sets of pages, usually limited sets of controls and interactions. more of a one-way information uh exchange. Web applications, more dynamic content, wide range of functionality, and it's highly interactive. And this is mostly where we're going to be focusing on today. So first challenge, HTML alone does not convey enough information to assistive tech

Speaker 2: about advanced UI controls Using native HTML and semantic HTML, you get so much accessibility for free. But when we do have more of these dynamic interactions just HTML alone isn't going to be able to cut it. So we have what's called Way ARIA. So Way ARIA stands for Web Accessibility Initiative, Accessible Rich Internet Applications. This extends HTML. So it's designed for these kind of complex web applications and provides the different types of techniques and best practices to make these very complex or intricate web components usable to all users. So for different types of content structures we can apply ARIA roles. So this will be things like dialogues, alerts,

Speaker 2: accordions, and tabs. We do have roles for them. It could also be for complex form elements, so list boxes or combo boxes, but then and also for more of application-based systems. So things like your toolbars, menu systems, tool tips. And this is something that goes right onto the HTML. So you'll, if you're ever dug around in code and you see a attribute that's prefixed with ARIA, that's what we're talking about here. Basically what ARIA does, it defines like three things. Role, what type of thing is this? So when I come across something like is it a, you know, is it a button? Is it a tab? What do, you know, what is this thing? The second one is what state is this thing in?

Speaker 2: So is it disabled? You know, does that keyboard focus? And then properties. What other um information on is crucial for a screen reader, you know, other assistive technology user to know. And so this could be, you know, does it have a live region or does it have relationships to other elements? A common one of the common Aurea attributes would be like Aurea labeled by where it's referencing a different element to give additional information about what's happening inside of these components So the first rule of rule uh the first rule of ARIA is never use it if you don't have to. And the reason for that is, again, because we get so much accessibility for free when we just use native HTML components.

Speaker 2: So for instance, let's say I have this, you know, I want to make a button. Well, if I have a span, I can technically add roll of button, but then you know I have to add a tab index. then probably have to add some JavaScript for you know handling different types of functionality. And then because just because I'm putting a roll of button on a span It's probably not going to get all of that nice browser default CSS for my focus states. So I'm probably going to have to do some CSS or SAS to make sure that those styles are available Or I could just use a button. So there are so when you are looking at like okay, how do I build this thing? I Highly recommend going to MozDocs, seeing what different types of patterns are already out there.

Speaker 2: Chances are there are there is an element. I think we have over a hundred HTML elements, but But there is likely something out there for you to use and you don't have to go again and add all this JavaScript and CSS just because you want your custom button. Challenge number two with complex interfaces is that assisted technologies may not be aware of content that has been updated after that initial page has loaded. So that follows up with our rule number two. Always use ARIA if you have to, because sometimes there's like no other way around that. Especially if you're on a page that's using Ajax, so it doesn't trigger that page reload. We'll want to use something that's called an ARIA live region. to make sure that a user is uh a user gets updated to any of that

Speaker 2: types of change of content or context uh that's happened on that page RO Live regions have three values. First one is off, which says that I only give updates if I'm currently interacting with the component. There's also a polite setting, so give an update after I'm done interacting with any element, and then assertive. Interrupt me and give me these updates immediately. So you can think of you know polite as uh you know hey your kitchen timer is about to go off uh you know in about a minute and a half and assertive is your kitchen is on fire, get in here now kind of a good way to think about that. This content can be updated via JavaScript, so it's not uncommon to have a little div somewhere on your page that says ARIA Live Region, and then the content that goes into there is updated via JavaScript.

Speaker 2: And some roles act as a live region by default. I won't go into these in uh in detail just because of time commits, but uh You know, these are there are certain types of roles that will inherently come with this air aurelite property. So this type of stuff is, you know, think how important it is for somebody is, you know, let's say filling out a page or filling out a form. If they don't do that correctly, you know, do we what types of alerts do we have in there? Do those alerts tell me, you know, what exactly went wrong? Does those alerts tell me how I can fix it? Or do I just hit submit and a blank screen stays there and I don't hear anything, which is a very frustrating experience. So and then rule number three of Aria, if you have to use Aria, you have to use it right.

Speaker 2: Not using it correctly will actually make everything way worse. If you go to the screen reader survey that I had mentioned before, if you use ARIA on a web page, the likelihood of having other ARIA errors get flagged just kind of like skyrockets And a lot of that is due to uh misusing it. So uh some AURIA attributes will have uh child dependencies. So if you do have uh You know, if you put Aria on one thing and then not on those child elements, you're going to get some issues there because it hasn't been implemented correct. And then probably the biggest challenge of them all is I, you know, we heavily rely on third-party software, libraries, and frameworks to build these complex interfaces. So one of the I have some advice for you folks when you're going out there and evaluating different types of frameworks or libraries to pull into your

Speaker 2: projects, you have to ask yourself, well, what accessibility features does it already have? Does it, you know, do I know that it supports screen readers? Do I know that it's been tested with a keyboard? You know, has the vendor sent over anything, you know, telling me that it is accessible or isn't accessible? And there are some areas where, you know, and I've reviewed documentation from vendors before, you know, I won't name names, but a uh you know a popular quizzing software where they say, you know, hey, if you're going to be using this, you know, you can use these types of quizzes, but stay away from this component because, you know, we know that screen reader users can't interact with this. So some of those settings, you know, or some of those considerations may only be, you know, in the documentation the vendor provides.

Speaker 2: But it's good to know what is and isn't accessible before bringing it into your project. And in some cases, you have to enable settings in order to better support some users with disabilities. For example, HiCharts is a data visualization library. And there are, and if you want to provide the raw data for a screen reader user. That's a setting that you have to enable. So it's also good to you know dig through again the you know any type of documentation that you can find to see if there's anything that you need to do on the admin side to better support your users. with disabilities. And then if you're doing something where work for more of an open source package, take a look at the issue queue. It's very common for me to, especially in like different types of like slider or carousel libraries.

Speaker 2: uh you know go to their github repo and uh you know type in screen reader keyboard accessibility and just to see what pops up. It's also a good way to see too. It's like, well, you know, has somebody reported this issue, let's say like four years ago, and it hasn't gotten any activity since then, you know. So kind of like a good uh way to gauge the uh how accessible a library may be. And some of these, you know, some of these uh services, they may also provide a demo page too of like how these components may render on the front end. So if they do provide one of those, I recommend checking it out, running the Wave browser extension, and keyboard testing just to see uh just to see what happens. Data visualizations do present a really interesting problem

Speaker 2: because we're, you know, we're using these data visualizations to make complex information. way easier to understand. But since they are inherently ocular-centric in nature, and that is a relatively new term for me, visualizations can make just getting that data really impossible for assistive technology users. So some of the things that we can to better support these users is make sure that one, that it's uh that uh it is keyboard users are able to get through this, especially if Let's say we are we have a data visualization that allows somebody to like navigate through a chart, you know, pop open tooltips to get more information. you know go through the go through it with the keyboard can I do everything with the keyboard that I can do with the mouse

Speaker 2: that's always a really good first place to start and if it doesn't work with the keyboard I don't even bother testing it with a screen reader because a lot of the way keyboards work and the way screen readers work, there's a lot of overlap. So if I can't toggle something with my keyboard, the likelihood of it toggling with my screen reader is really, really low. The next is evaluate screen reader verbosity. So this is a good one too to make sure that you're not just like putting in, let's say, an Oreo live region on your entire table. because then any update that triggers in there will force a screen reader user to read that whole table again. So you know see what is being read out loud when where possible. You know, I highly encourage testing with users who actually have a disability and use assistive technology in their everyday life.

Speaker 2: And then let's say I, you know, you have these data visualizations or you have this data table and just whatever you're putting into it just can't make it accessible. a fallback option is always providing that raw data you know either in like a CSV file or you can dump it out as just a a regular table if you are more the data visualization side In the interest of time, I won't play this for you, but I highly recommend uh checking out uh this high charts demo. Especially if you've never heard a screen reader user go through a data visualization before, but it'll give you a really good idea of the types of things that screen reader users hear And then also the different types of

Speaker 2: functionality or support that you may be able to pull into your own websites to better support these users. So uh and you can always go the extra mile too. There's been a recent trend in data visualization called the sonification of data, uh which will actually allow users to you know hear changes in the data to better interpret um the different types of patterns. HiChart has a a lot of great uh examples of this if you are Hitchworks user. Um, but also NASA has been using it for some of the uh in order to communicate different types of information coming out of their uh it's really cool, like their pictures of like galaxies and black holes and all of that type stuff.

Speaker 2: And this gives a way, this gives users more context too for the uh for the information that they're interacting with. So you think about it, you know, we don't want to look at just like rows and rows and rows of like you know data in a table. And we like these visualizations because they're fun, easier to understand. we should give that same type of enjoyment to our users who have disabilities. So highly recommend checking out the high charts demos and NASA 's sonification on their um on their space images. So I am here for any questions. You're also able to get these slides so you have all of the links in there by scanning that QR code or going to bit. ly backslash W

Speaker 2: S U S A11Y. So if we have time here to answer any questions that you folks may have. Sure.

Speaker 3: Um you had mentioned a tool that lets you uh maybe misunderstood, but um basically idea was is once you set up your RF attributes was either validated or to test it. I guess one of the questions I have is that my team can follow best practices but they don't need to know necessarily

Speaker 2: So there is an uh for on the way Aureo website. They have a great area for the different types of patterns. So some of you know some of the way is just uh you know kind of comparing what the thing you're making is to over to best practices. The second way that you could do it too is um you know depending on you know the implementation you might be able to just run the WAVE browser extension So if you have like a broken ARIA reference, those are the types of things that in that it can flag. So if you're misusing it and there are issues in that Wave would likely be able to tell you. But if like let's say you're using, you know, roll

Speaker 2: slash button instead of button , you know, that's not something that, you know, wave is going to tell you about. So part of it is, you know going over your own code and maybe uh going and then referencing that to established practices, seeing if everything's wrong. And then there may be some tests too that you can run either through WAVE. Axe Core does a pretty good job at flagging things too. Um I um so I would say those are probably like kind of your two best uh bets uh there.

Speaker 3: Sounds like it's still a field where having a human actually test is probably

Speaker 2: Yeah, so if you're scared of the robots taking over, I highly recommend a um uh a career in accessibility because there are some, you know, that's a There are, you know, that's a, you know, especially too when you're like when you are thinking about um a, you know, because people are interacting with this stuff too. Um and like And when it comes to like accessi uh accessibility in like AI, you know, a lot of these cult coding tools um uh you know that are powered by AI You know, it's like trained off of like millions of line uh or millions of websites of inaccessible code. So like trillions of lines of inaccessible code. So yeah, we're very uh safe here in the accessibility profession uh from the robot hostile takeover. Question?

Speaker 3: Yeah, so um coming from the uh government space where accessibility is technically a legal requirement, we have some sort of um Following a letterable on spirit issues and what I'm particularly interested in is you were talking about data biz. This is going to be a really uh sad variant of the version you showed of how this could work. Uh we tend to put a lot of data biz and it's just static images. on some of our content. This is a kind of a lot of reasons that we are sometimes just under control. Um often the way we try to handle this is with alt text. And I am never sure when to when Too much detail is too much. And I'm curious what um here we talked about like what the kindest way is to present conflict like

Speaker 3: that speakers You know, understanding that they can't parse a long set of alternate effects the way one could parse tabular data represented by data that is

Speaker 2: Yeah, that's a um you are you know unfortunately you're not unique uh you know in that situ you know we have the you know we kind of have the same problem too and then a lot of times you know We get the information, let's say, from a subject matter expert, but the person posting it online is not the subject matter expert. So then they're like, uh, like I, you know How do I write alternative text for, you know, the erosion of like, you know, beachfronts? Like you know what I mean? It's like I'm not the expert. So um I, you know, in Cases like that, uh, you know, kind of context is key. Um so for instance, if you're like putting out like a blog post and the, you know, what is the intent of that image? Is it to give like an overall trend? Um, you know, or is it important for them to have all of those data points?

Speaker 2: If it's more of like the spirit of the trend, you know, that's a little bit easier. So you're like, you know uh you know x raised to you know y over you know these amount of years or something like that. But when it is, you know, let's say in the surrounding content, you know, it's not like those data points aren't explained and like uh the audience is let's say a research-based audience, you know, that's when uh you know that's when it gets a little bit trickier. So you can always do a, you know, in your alt text, you can give the location of the longer description if you're able to get a longer description and put that data in some type of table But you know, it is a you know it is a challenge especially too, again, if like you're not that subject matter expert and you have to and you have to write it.

Speaker 2: In regards to what a uh you know kind of like balancing um screen reader needs, um I you know, it's I always say when it comes to alternative text, um especially for anything that's graph related. Put your most important point right at the front because you're not guaranteed that somebody's going to even listen to your whole thing of alternative text. uh screen reader users they can just you know they can skip to the next element so if there's a huge takeaway that you need that user to get make sure that it's in that kind of like first sentence or that first bit. And then the user can decide if they want more information or not from there. Then there is a uh and then it's also, you know, there are uh you know again humans have preferences too.

Speaker 2: There are always going to be people who like more detail and there are going to be more people who like to keep it a little bit more high level. So as long as you know you're putting in what you want your takeaway to be, you know, anything else can be a benefit for those users to do as they see. fit would. Any other questions?

Speaker 4: Got one from Josh.

Speaker 5: Something something that I uh that I have heard a bunch of times uh during web devs in the last few years is That a lot of you know a lot of web development takes place on Mac or on Linux, and typically using on Mac at least a built-in voiceover screen reader. Most people who use assistive tech are going to be using uh Windows and Apps because those are the options that have been around this table for the longest Is that still true? And if so, what kind of problems, like have you seen that create a lot of problems? And what kind of

Speaker 2: Yeah, so the um yeah most desktop users um if they're gonna be using a screen reader, they're going to be using some type of like Windows-based screen reader. Um and that does do and that flips for um mobile because and I think it's just because Apple has way better uh assisted technology support for mobile devices than like you know uh Android does. Um so you know there are uh One of the I linked to it earlier in the presentation, but there's a whole section about screen reader and like browser combinations. And it's Really important to to you know look at those types of statistics because you know you don't want to do all of your testing on like you know let's say a MacBook

Speaker 2: pro using voiceover when like you know 90% of your users are gonna be like Chrome users on Windows base so it kind of helps you like prioritize like where to like focus your testing efforts. And then for like you know an added like you know level of fun too, like for the front-end developers in the room, like remember what like a nightmare it was to support Internet Explorer So like screen reader uh screen readers also have bugs in them, um and sometimes they only have bugs with like specific browser combinations. So that's where like using that like can Iuse. com too is like a good reference because you might find that there's like uh you might have to change the way something's coded because uh of the browser like the browser support for like a specific uh you know

Speaker 2: element attribute you know css thing whatever it is like isn't just as supported um enough so um So yeah, it's a, you know, I've seen issues that are, you know, everything from like, hey, this works perfectly, you know, in voiceover, but it doesn't work in voiceover and Chrome. And then in Jaws and Chrome it's fine, but Jaws and Firefox it doesn't. So I would say on a You know, but I say if you are going to be like testing anything, like, you know, test it with factory defaults, uh, or rather, like, you know, test it with your factory settings. And then go for like widest amount of coverage too. So again, use that like caniuse. com because it'll show you kind of the browser breakdowns between versions and so you know where the issue is, where it was resolved, things like that.

Speaker 4: All right. Anything else? One more over there. Yeah, I vote for uh successful. university library and one of the big issues that we're kind of grappling with is that we have a lot of legacy content in of media so documents map

Speaker 5: images, audio, you know, anything, anything.

Speaker 3: I just wanted to ask if that's you know something that you're also grappling with in Pan and what 's been your approach? trying to bring legacy content into compliance.

Speaker 2: Yes, always. So we do we definitely do have that same um that same struggle. Um that you know The I would say kind of like the first thing that I always recommend to people is like do you like how content inventory and do you because you have to you know know how big your the animal you're up against is. Um so you know It's like let's say like PDFs if you know that that's going to be like your pain point. All right, what PDFs do we have on the site? You know, and that may not be an easy test, depending, you know, you said you're from like a library, but for when you were looking at this like legacy content, is there any of this stuff that we can just get rid of? Like this doesn't need to live anywhere online. It's you know doesn't need to serve like a historical purpose or like you know over record we can just get rid of it And

Speaker 2: the next kind of then the next set is is all right, well is this content something that can just live as an HTML page? Or does it have to be a PDF? Because if it doesn't have to be a PDF, but it still needs to be online Let's just find a home for it on like one of a web page and turn it into HTML content. And then there are certain circumstances where like something absolutely has to live as a PDF and has to stay like that and then that's where you can focus like your PDF remediation efforts on. So it's like first can I delete it? If so I'm deleting it. The second is can I convert it? Then if I can awesome and if I can't then I remediate a PDF So, you know, and then a something that I I always recommend too is if like let's say you have a website that you just know has a lot of inaccessible content.

Speaker 2: somewhere on like every single page or that's really easy to find, tell people like, hey, if you have issue, you know, like it's called an accessibility statement. They even have accessibility statement generators online but it provides information to uh users saying like hey we know that this it we have xyz issues if you uh come across these and you need this in a different format here is who you contact and that contact shouldn't be like info ad it should be like you know accessibility ad or like a named person um so it just doesn't get lost in an inbox. So you know usually a combination of yeah content content inventory and purging. And then making sure users know who to contact if they come across that horribly inaccessible PDF document we posted online 15 years ago, who to contact if they need it in a different format.

Speaker 3: Good question from uh Mike Sullivan online who wanted to know when should I describe a a logo in Halt text?

Speaker 2: Uh when or how?

Speaker 5: When?

Speaker 2: So if it's like in the if it's in the header, um I you know you would I usually would I just have it named as like you know home or my uh you know or my button but like if you're talking about like the element order, you know, I have it usually as my I guess second element because everyone has skip links as their first focusable element on their web pages, correct? So the uh so our logo would be the s usually the second item if you're looking at the source order Is that kind of what they were asking?

Speaker 5: I think so.

Speaker 2: Yes.

Speaker 3: Uh I'm just curious what what remaining repeating

Speaker 2: A nightmare, usually. It is my least favorite thing to do in accessibility is remediate PDFs in a the the big reason for that is is that the the tooling to do so is not quite where it should be. And is and that and it gets a lot harder the more complex your layout is. So if you just have like your standard kind of, you know, Times New Roman documents where we have some like headers, bullet lists, links, like Something like that, that's not gonna that, you know, that's not a huge lift. You know, you can usually get away with like auto-tagging through Acrobat, that's you know, not horrible experience. But when you start getting into more like kind of magazine layouts or like you know reports where we have like columns and stuff, that can be a um that could be a real nightmare, um

Speaker 2: especially too depending on like where that source document was So because you know every time we convert something, let's say a Word document, and then we convert it to a PDF, sometimes we just lose, you know things get lost in that uh you know that export process. So um you can't always fix things in the source file, but um and then you have to go into Acrobat and remediate it. But um You know, if you do ever get into PDF remediation , you'll become best friends with tags, which is the like HTML equivalent in a PDF document structure. But uh yes, if uh and that's why I say like you know you're if you have to remediate a bunch of PDFs, if it doesn't have to live as a PDF, like don't you know convert it to web content because that way you can at least

Speaker 2: If you have to make one fix, you can just like you know fix it in your like HTML code, push it up, and then that template goes everywhere as opposed to doing it like on the document level, you know, however many times. So

Speaker 4: Looks like they finally have gone quiet.

Speaker 1: Thank you so much, Cara.