Don’t forget to subscribe to our YouTube to stay up-to-date. You can also leave a comment on individual videos. Please note, we review all comments before they’re posted. You can find out more at .
Website overlays: If it’s too good to be true, it probably is
Accessibility overlays are actually causing more harm than good for people with disabilities. This presentation looks at what accessibility overlays are and why we shouldn't use them.
Video sections
00:00 Introduction
00:41 GAAD
03:00 Definition of an accessibility overlay
04:44 What's included in an overlay
05:23 Why we shouldn't use them
22:58 Privacy concerns
24:19 Overlay fact sheet
26:12 Helpful websites
26:45 Questions
Transcript
>>Danielle Sheffler: Today, at least in Australia, tomorrow in the US and other places, it is Global Accessibility Awareness Day. There are obviously a lot of topics that we can talk about with accessibility, but one of the ones that has really been coming to the forefront is accessibility overlays.
We'll talk about what those are, but essentially the theme is if it's too good to be true, it probably is.
So I think most of you know me, but just in case you don't, I'm Danielle Sheffler. I'm the Accessibility Practice Lead. John Cloys also just joined us this week as an Accessibility Consultant. We're very excited to have him, and he's going to be jumping in in several places here as well to make sure that you all get the information that we want to share.
We have a lot uh to jam pack here into our agenda but really wanted to talk about what Global Accessibility Awareness Day even is. Because it's great to say that we have this topic, but if we don't even talk about the day itself, loses a little bit of its meaning.
We talk a lot about accessibility overlays but want to make sure like we do with most of the things that we do that we are all on the same page. We understand exactly what we're talking about.
We want to talk about what's generally included in these overlays, because there are a lot of companies now that are really getting into this space. They offer different things but just so you can kind of recognize what they are and what they look like, either in your personal browsing or just with clients as well.
We will go into, I think, we have 11 different reasons why we shouldn't use them and really 12 goes into privacy. I want to talk about a website called Overlay Fact Sheet and then helpful websites just to give you some links, because I'll be sharing this presentation and want to make sure that you all have resources if you want to dig in deeper. We'll do my best to try to leave time for questions. So I also don't want to speed through this. We'll see where we go, and we'll go ahead and get started.
So Global Accessibility Awareness Day, like I said, is today, the 20th of May, and it is the 10th year of the day. And I picked this language directly from the website but basically it "was created to get everyone talking, thinking, and learning about digital access and inclusion and the more than one billion people with disabilities and impairments."
So that is a very big number. I know we talk a lot about why we need to incorporate accessibility.
It really benefits everybody, but, again, if you really think about how many people there are in the world with a disability or some type of impairment, really important to recognise that and why they need to be included and just making sure that we're sharing the knowledge across the board.
That is my hope that as you attend this presentation that not only do you learn something new but then you're sort of able to be an accessibility advocate, especially in the ways of overlays.
So what is an accessibility overlay? So I have AI-powered. It's really just generally Javascript most of the time. An automated accessibility tool they say that they are able to make your entire site WCAG 2.0 or 2.1 AA compliant with a single line of code.
So I usually like to show and not tell, so I'm going to give a few examples. It's almost as if you were a developer, and somebody said, "Okay, well, you can just code an entire site using SDP or GovCMS or Drupal in one click of a button or one line of code."
As a developer, you'd be like, "Okay, that sounds great, but probably not true at all. I'll have to do a lot of testing. Really doesn't make sense." Same thing with you can't click a button and manage a project or if we think about leadership, you can't create a proposal click of a button or come up with strategy click of a button. Right? We know that these claims don't really make sense, so that's the first sign of why it's if it's too good to be true, it probably is.
But this is really what they're selling, and so there are a lot more companies than what I have listed here, but AccessiBe, UserWay, AudioEye. There is actually, in the Victorian Government, a [company] that's using recite.me, and there's more, so if you're not sure if you've seen one of these overlays or not, I have a few of these buttons here. So if you're clicking, you see a little icon at the bottom right generally of your screen or sometimes it's at the top right. That's generally how you know that there's going to be an overlay.
So what exactly is included in an overlay? Like i said before, they each have their own set of tools. So what we see here on the righthand side does not mean that this is what's going to pop up for every single one. But, at the same time, generally they say that they can fix your contrast or change your contrast, they can take care of your text sizing, your spacing, they can help create alt text for you if it's not there for images, they have their own screen reader. Again, they're really just trying to promise you the world and that they're able to meet accessibility very, very quickly.
So why should we not use them? The first thing is most of their taglines talk about how we can help reduce lawsuits. So in the US, there's something called ADA or the Americans with Disabilities Act. We can make sure that there's no lawsuits. Okay, first of all, that's great. Nobody wants to be sued. And at the same time, that means that you're really just focusing accessibility or on accessibility, because you don't want to get sued. There's no thought of the fact that there's one billion people with a disability or even the fact that we're all people in general, and we all deserve access to the same information.
If you remember some of my blog posts, I talk about empathy and how sometimes it's more than just about empathy. It's really just thinking about being in somebody else's shoes and understanding that they are just like the rest of us. Or you know I have an invisible disability. I'm just like the rest of you.
I want access to information and to be able to have that and be able to use a website or an app or whatever I'm trying to do from a digital perspective.
And so that's really the first part - is that they're focusing on this piece that isn't really what is at the heart of accessibility. It doesn't mean that they intentionally have bad motives. I don't want to think that somebody is doing things solely because they care about money. It happens, but we don't know their intent. But the focus really is not where the accessibility community would really like it to be. It really treats accessibility as an afterthought.
We know that, as we've been building this accessibility practice at Salsa, I know that Salsa cared about accessibility before I came onboard. It was very obvious with the work that had been done with Ripple, it was obvious in blog posts and writing about content and making sure content was accessible.
We all knew before I started this practice that accessibility was important, and it was something that we needed to think about in our coding and bringing people in. But at the same time, if you really just treat it as being able to just do it in one line, we know that that's not really possible, but the other piece is it's really saying that it's not important for people to understand the guidelines, for them to learn how to write accessible content, to write accessible code, to make sure that you're doing thorough testing. It really just goes out the window, because you're really being sold I should say this package dream of not really having to think about it at all.
The other piece, and we've talked about this a little bit, is it's impossible to fix all of the issues with an automated product. Is it great to be more efficient? Yes, right? We all know that efficiency is key.
We really like that, and whatever can be identified is helpful, but we also know that those tools are already on the market, and they don't really interfere or try to take over what you're doing.
It's something where we really try to focus on making sure that, yes, we do the automated piece, but that gets you roughly 20 to 25 percent of the way there. There's always manual testing for a reason, whether that's if you use a mouse, not using your mouse and solely using keyboard, whether that's listening using a screen reader or there are a lot of speech to text tools outside of sometimes people think Amazon et cetera.
There are a lot of other tools that people use for their regular use, and so it isn't something where we can just slap on a line of code, say that it's done, and just be finished with it. The other piece is that the majority of people who need these tools already have features. So, for example, with text sizing, people already have a way in their browser to do that. There are things, so there is a way to make sure that we have features that, we have screen readers already.
There are all of these pieces that are already in place, and then the other piece that I was referring to as well is that a lot of times, some of these widgets or overlays, they already have or they do have
screen readers built. And so if a user has a screen reader already, what will happen is that their screen reader will start on their computer and then, all of a sudden, the screen reader from the widget or the overlay will start on top of that. And so you then essentially have two screen readers talking to you at the same time or you already have tools or your screen readers already trying to navigate the site. And then, all of a sudden, you have this overlay, which you didn't really ask for, this widget that starts doing things for you that you didn't ask for, that is interfering with what you're trying to do and so instead of helping you, all of a sudden, you're finding yourself super confused, because maybe you don't know how to stop it.
Maybe if you're hearing two things at once, it's really unclear as to what's going on on the page or on the site. It really just does not help at all.
So I want to stop. John, did you have anything that you wanted to say from this piece before we move on?
>>John Cloys: Yeah, definitely. I can add something to that, Danielle. Thanks so much. With sort of a single line of code, so, again, these sort of accessibility widgets, they introduce stuff on the fly using client-side technologies like Javascript et cetera and, in a way, that could have an unnecessary extra step and a performance tax on your site if somebody's checking out or whatnot as well.
>>Danielle Sheffler: The other pieces is that, not surprisingly, when it tries to fix something for you, tries to be very helpful, right? It's not always correct or reliable. So that's fantastic that it tries to pull alt text, but what ends up happening a lot of times, let's say it identifies an image that doesn't have alt text. So we know that a lot of times when Google does this, for example, or even Facebook, they use AI to try to give you alt text about the image.
Well, that's not an actual human and so you might get something that Google decides is right but really isn't, and, so again, it's not very helpful to the actual user if they're getting information that doesn't describe the image or whatever it might be.
Another example could be error messages. It might try to figure out what the error message is supposed to be, but, again, not a human doing the actual work and so there could be an error message that makes absolutely no sense. So we as sighted users, for example, or there are also cognitive disabilities et cetera, it might not make sense to us, but we can look and say, "Okay, that doesn't really seem right, but I can tell right where the issue is." Generally somebody who does not, who might not be able to see, maybe somebody that has a cognitive disability or another type of disability, where if they don't have clear error messages, won't know what they're supposed to do, and then they'll be completely stuck.
And then the other thing is that, as we've stated, and I'm going to keep saying this, is that these services, they can't do everything. And, so for example, we know that there's a lot of interactivity on sites, and there's a lot of videos. So, yes, there might be captions through YouTube, but maybe people are using another service or maybe something's broken with that video.
A lot of times, we see people don't know that they need captions and transcripts. There's no way for those services to be able to tell. If you're using purely audio, so let's say you have a podcast or a click, sorry, quick audio clip. There we go. You might not have a description associated with it. Something that's automated is not going to be able to test that.
There are things like link context. So we talk a lot about these read more or learn more or something that's really not clear in terms of you what it's talking about. Not able to check those if there are things that are only describing, I should say based off of shape or location. So, for example, click two paragraphs below to go to the next page. Well, that's a violation of WCAG guidelines, but how is an automated tool going to be able to do this? And remember that these are not just things with overlays. These are also things with any automated accessibility tool. This is not new to overlays. But, again, most automated tools don't promise to make your entire site WCAG compliant.
The other things are keyboard traps. So for those of you who aren't aware, it is possible when you're using, for example, your keyboard, and you're using tab, you can get stuck in an area, and you're not able to move on. Automated tools can't test that.
And then another example is table formatting. So does the table read correctly? And these are not, that's not a full extensive list. There might be more, but it does go to show that something that talks about being this end-all be-all great use definitely isn't. So, John, is there anything that you wanted to add that maybe I missed?
>> John Cloys: No, this looks pretty good. I'll second that keyboard trap. I mean menus are the worst. Megamenus et cetera, so just be careful.
>> Greg Netsas: Sorry, Danielle. Maybe i phased out, but did you explain what sensory characteristics are?
>>Danielle Sheffler: Oh yeah, sorry. So, yeah, Greg, so sensory characteristics is if you use size, shape, location, or colour essentially to provide direction. So, even, for example, if you have an error on a field, and you only have that as, for example, you'll see some sites just have it in red, and there's no error message, that actually fails guidelines, because it's only showing somebody by colour. Or it might be click on the arrow to go to the next page. Well, if I'm not able to see the arrow, well, then how am I going to know that that's what I'm supposed to use? Does that help explain?
>> Greg Netsas: Yes, perfectly.
>> Danielle Sheffler: Okay, great. Okay, alright. So the other piece is doesn't support mobile. Guess what? We all use our phones a lot. And so do people with disabilities, so that I don't really need to say that much there. There's no overlay on accessibility, sorry on mobile, so if somebody's trying to say, "yes, our site is accessible, because we have this widget or this overlay on our site," guess what? You go there on mobile, and we know in general, I should restate we already know that the site that they're claiming is accessible is not, but, at the same time, we'll know that it's definitely, definitely not on mobile.
Other piece is that you pay to make your site accessible. Now, of course, we know that when we offer services, we write accessible code, but when we do audits and things like that, yes, of course, you know it's not always something that we give away for free. Let's be honest, because it does take a lot of time. It takes a lot to make sure that we are giving as many people as possible the right experience, and it's something that is absolutely worth doing right, because we want to be as inclusive as possible.
However, we know that once we do that, really, the next step is making sure that we're training our clients. We're making sure that we're doing what we're doing here, making sure that everybody's trained, has the opportunity to learn, ask questions. Yes, we might make some mistakes, but you know what? That's how we learn, right? Sometimes, you learn more from failing a little bit then succeeding right out of the gate. So we're all here to learn, and we know that through this education, we'll just take what we've built and then continue on that path. And making sure that for content creation, any new development et cetera is accessible.
Not the case here, because you're paying to make your site accessible through this widget, but only as long as you pay for that license. It's not like these businesses say, “Okay, you paid us once. Yes, we're very nice. We don't need your money anymore, and your site will always be accessible." That's not the case, so it really is only putting on that band-aid that doesn't even really work - only for a set amount of time. And, yeah, sorry, John.
>>John Cloys: And I should note too that those band-aids are not cheap. I mean, some people are paying thousands of dollars a month. You might as well correct the issue outright during the design process et cetera.
>>Danielle Sheffler: Yeah, great point. Thank you for stepping in there.
And then the other part that I wanted to go through before I pass it over to John is that they make these claims that they can make your site accessible, but then if you look at their terms of service, a lot of times they say, "Okay if you are basically sued at all, you have to let us know. It's something that needs to be done except we're not liable."
So which one is it, right? Are you going to make my site accessible or not? And so it's almost clear from their Terms of Service that they're saying "We know that there is a possibility that this could happen."
I mean, of course anything's a possibility. "But it's not our product. It's not our problem." And so it's just really not a great look, I should say, for these companies. And John had actually found a great statistic, speaking of lawsuits, and this is just from the US, that there were 3,350 digital accessibility lawsuits, I believe, last year. John, correct me if I'm wrong, and 250 of those were for widgets or overlays. That's a pretty substantial number, given that these overlays are really just starting to hit the market pretty big. And so it's not good.
And then, sorry, actually one more point before I hand over to John is that a lot of these companies' owners, obviously nobody wants to hear negative feedback about their product, but the accessibility community and people with disabilities et cetera have tried to have conversations with owners, CEOs, CTOs, marketing team members, whoever they can talk to about the concerns of these widgets and overlays. Again, it's not to attack them or say that they have bad intent. It's just, "Here's my experience. This is making it a lot harder for me. We know that you have a goal, you say to help, but it's not helping. Here's the reason why."
And it's essentially just been a fair bit of an attack, honestly, back or downplaying or saying, "No you're just not using our widget correctly." And so it's just been a little, I'm not even going to say a little. It's been very contentious to say the least, because there's proof that these tools are not doing what they're supposed to be doing, and yet there's really no acknowledgment of that. And so that whole principle of doing the right thing, unfortunately, is not really being seen. So, John, did you want to cover the last one for us?
>>John Cloys: Sure. You know, as Danielle mentioned too, overall these widgets, they ultimately create a really frustrating user experience and add that extra step, because every one of these widgets have different customisations, configurations et cetera, so you may be on one site that uses AccessiBe or the other one that uses UserWay, and you have to configure them, every different site that you visit. Again, it's a much better user experience to rely on the native browser itself and fixing those accessibility issues outright to begin with.
>>Danielle Sheffler: Thanks, John. Okay, so just a few more things to cover.
So there are definitely privacy concerns too. A lot of overlays can automatically detect screen reader usage, and most of the time, screen reader usage equals somebody having a disability. So that's private information that people do not have to share. A lot of these overlay widgets and things of the like do what we see on the right hand side, where they ask specifically for what profile you want. Well, if I'm saying that I want a cognitive disability profile, I probably have a cognitive disability. I should not, in order to use some sort of assistive technology, have to tell someone and likely have that stored - to offer that information up.
And so there are several statutes or regulations. So CCPA, which is the California Consumer
Privacy Act. I think a lot of us have heard of GDPR, which is mostly out of the EU for General Data Protection Regulation. But, in general, there is a reason why a lot of us now, especially because of GDPR, have the ability to say "Yes, we accept all cookies or no." We get to decide if our data is stored or not. Or sometimes we're told that we can't move forward, but we should have that option. It shouldn't be, "If you want to use our tool, you must select this particular profile."
And so the last piece, and I do have the link to this in the next slide of helpful websites, but there is something called Overlay Fact Sheet. It does a really good job, it's actually a pretty short read, probably will only take you about 10 minutes or so, that has a section for people to sign that essentially is saying that we won't advocate, recommend, we won't put in an overlay, which says that it will do automated compliance, we'll make sure that we always advocate for remediating accessibility issues, so similar to what John was saying. Start with design. Go through the whole life cycle like we're doing on several of our projects now.
If vendors are using deception, sometimes, unfortunately there are things that are not really correct marketing, that we won't allow that to happen. And then we'll also advocate for removing these products on sites and make sure that people know that there are better ways and great ways to do these things.
So i wanted to note, that it's not just so you know about this website, but there are 427 of us, I have also signed, from across the world. So that is a lot of accessibility professionals that are really understanding that these overlays are not helping, that they are, I hate to say it, but dangerous for the accessibility community, in terms of them getting access. And that a lot of people don't know this, and so just wanted to make sure that you were all aware and to really put weight behind what John and I have presented today.
And so we do have some websites. So there's the Global Accessibility Awareness Day website. Lainey Feingold is a very great accessibility advocate and does a lot with accessibility law. So I have a link in here, and there's actually a lot of articles that you can then go out and read. And then there's the Overlay Fact Sheet website that I mentioned as well.
So I know that we went a little bit over but, definitely, if people have any questions, I want to make sure that we have time to answer. So just wanted to open it up and see if anybody had any comments or questions.
>>Kristen Pol: I have a related question, and maybe it's kind of taking a different direction, But these are trying to, you know the site's live, and it's you, you turn the thing on, and it's doing a bunch of stuff with Javascript and changing the site. Are there, and there probably are and I'm just ignorant, but are there tools that rather than do that, it's more of a developer's tool? It'll try to do similar things for you, and then you could kind of decide which are the good ones and not the good ones, and save and kind of as a shortcut on the automation, kind of on further up the chain?
>>Danielle Sheffler: Yeah, I love that question, and it's funny, because when John and I were talking before he came on - he knows the tools that I use for development - or when testing things, and he was like, "Oh, I use other tools. Is that okay?" So it is good, that, yes, there are absolutely other tools.
So there's one called ANDI that I really like. It's A-N-D-I that's actually out of Social Security Administration actually, and it's open source tool. There's one from Deque, which is called aXe, it's A-X-E, as well. I know level access has a lot of tools. John, I think you can speak to some of the ones that you use as well, correct?
>>John Cloys: Yeah, there's one that Microsoft uses, Accessibility Insights, that's pretty good. I'll throw some of these in the chat too.
>>Danielle Sheffler: So, yeah. So, Kristin, a great question and, yes, and that's the thing that makes this so hard is, because there are these tools that you can use during development where obviously the goal is to get everybody to do manual testing as well, but if you're using those automated tools during development, at least you'll find something, but they won't interfere with the actual user experience. And when I did my presentation for Drupal South in November, or I guess it was Drupal Gov, I made the point of would it be great to do everything? Yes. Am I going to say if you can only do automated testing is that bad? No.
However, in this case, I would say if you say accessibility widget or overlay or no accessibility effort, pains me to say it, but I'd actually say no accessibility effort, because you're actually making things so hard, and it's so much worse or a person with a disability, that it's actually better to not use those widgets and to not do anything. Obviously, that's not the recommendation, right? Please do automated testing or hire somebody. But if that's what it is, that's kind of where the recommendation lies. I do see, I know that John had put in a few items for chat.
Okay, is there, are there, any other questions?
>>Alfred Deeb: Yeah, you've got some hands up, Danielle. I think from Antoine and Greg. I can see they've got their hands up.
>>Danielle Sheffler: Alright, sorry. I have so many people. Antoine.
>>Antoine Osanz: Understanding, obviously, it's a pretty clear no-go zone at the moment I'm just wondering, obviously, a number of companies are putting a lot of stock into this space. Do you think there's a future state where something is actually usable and acceptable in this space?
>>Danielle Sheffler: The way that it is now? I don't believe so. And I say that similar to how, for example, if we're doing testing, we might write Behat scripts and that gets us a little bit of the way, but we're never going to take out any of the manual testing that's done or any of the automation that we're seeing in development. We know that that helps get us to a certain point, but it's not going to get us to where we really need to be. John, I don't know if you have any other thoughts on that.
>>John Cloys: Yeah, no, I agree. It's so hard to anticipate the intent of the user, and until the technology is there to do that, I think it's a no go.
>>Antoine Osanz: Thank you.
>>Danielle Sheffler: Yeah. Greg.
>>Greg Netsas: Yeah, hi. With regards to that, my understanding was it was a petition that the accessibility professionals have signed. Playing the devil's advocate here, one might say that you're losing job, work basically, or money out of those widget companies, so maybe that's why you're doing it. So if this is a petition, and it's sort of aiming to get somewhere, maybe what one of its goals should be to get the people that are actually affected by it or organisations that are representing it to sign on their behalf if they're frustrated. And basically these tools are not usable for them.
>>Danielle Sheffler: Yeah, so actually if you go to that particular page, there are, oh my gosh I might be misquoting, but at least 15 to 20 statements. They're shorter quotes, but they're statements, thanks John, from users with disabilities who talk about how difficult it is. They're also, and I mean of course because people don't always want to say when they have a disability, but a lot of the people who have signed, they do disability work, because they have a disability. And so they're also affected. And so there is a lot of information in there. So there's a fair bit of information. And then kind of the petition, as you say, is at the end, and, yeah there's just a lot there.
And I think the thing too about accessibility, and it's true, right, for a lot of people who do their jobs? People who get into dis- or, sorry, into accessibility are very, very passionate about the work. I mean, accessibility audits and just, unfortunately, having to fight for inclusion is sometimes a really thankless job, because people don't realise the importance. And there's so much empathy I feel like you have to have in order to keep kind of fighting against those issues that I think, or at least I feel that comes across in that site.
But, I mean, I'd be interested, Greg, if you take a look. If you feel differently, it would be really helpful, because we need to give that information, I feel like, back to the community. If we're not doing as strong of a job as we should in terms of explaining these things, then it would be good to know, so that we can change our language or add information et cetera. So would really be interested to hear what you have to say after you have a chance to take a look.
So yeah, Nic.
>>Nic Haase: Hey, Danielle, thanks. That was great. I probably won't go too far for this now, but I was wondering whether we could maybe have some sort of session separately about the workflow at Salsa. Maybe how accessibility goes into the development process. I've only been here for a couple of months or so. So probably still pick up a few things.
>>Alfred Deeb: That's a nice one, Nicolas.
>>Nic Haase: Yeah, but in terms of with different agencies and workplaces that I’ve been through, and it's been the range between zero and 90 percent of kind of really putting emphasis on that. Yeah, it's pretty wide, and, sometimes, in some agencies, I basically had to kind of fight for just having some extra time allocation or some sort of process or whatever for it.
But I was just wondering how it works here and also whether we can maybe stand for the developers. I know you will have your input on the final outcome or what during the process, but I think a lot of time can be saved also for everyone having a good sort of base understanding of at least the, I mean a lot of the things are common sense and aren't even really accessibility, because it's just good development practices, right? I think we all agree on that anyway, but just what tools in terms of process what to think about while when you're actually starting to save time rather than going through the whole pipeline and then at the end, you sort of do the whole checking and then you go back to refactor et cetera, which could have been probably avoided often by 50 percent or to have it already basically done and having an ongoing thing. And it's not this big sort of loop.
>>Danielle Sheffler: Yeah. And so I smiled when you first started talking, because I was trying to figure out at one point, I was like, "Okay, I want to talk about the project lifecycle, and I want to talk about accessibility overlays." And I was talking to somebody. I was like, "Which one do I do? They're both so important. Maybe I can do both." And I was like, "No, you'd be there for two hours. You can't do that, so, because Alfred can tell you. I will talk about accessibility forever." So yeah.
>>Alfred Deeb: Yes.
>>Danielle Sheffler: That's a confirmed....see, look. So i care a lot and so, yes, it is definitely on the radar. It's something that I really want to do very quickly. Something else that is starting to come up, it really in my mind had started with Ripple, but I think as i'm going through this process with the health.vic team, because really it's the first time that we've put accessibility into our Agile process.
Our whole project lifecycle is really making sure that we have a, I don't know if I want to say reference or encyclopedia or some way to put it, but solution direction essentially for most of the pieces that we can, of course, it'll be a little bit easier if we look at it say from Ripple, right?
Because we have all the components, but we know that we don't use SDP for every single site.
But a lot of those, for example, we're also writing acceptance criteria. Those acceptance criteria will still apply for every project right, even if we're not using Ripple, like the skip to main content links or if we're looking at something related to buttons or whatever. It might be we can definitely reuse things, so it's something that I'd say is maybe in the higher level of infancy, but it is definitely something that we're doing.
But it's absolutely like you said from a developer perspective, right? It would be great to get ideas, And I am hearing a lot of things from the health.vic team. I know that Antoine has given some thoughts as well, and Phillipa from the Engagement Manager role. Alan, of course, has been Alan Cole has been super helpful from the frontend perspective. So i do think it takes all of us to be able to do that. And I think it would be probably helpful for John and I to present, I guess, our ideas or our strategy and say, "This is what we're thinking about doing based off of our experience, but, you know, what do you think that we might be missing?"
Or right, of course, we start implementing things and then, as always, doing process improvement to say what it seems like. Maybe we missed something or actually this process doesn't really help us here. Can we change it, go back et cetera? So really, really open to thoughts and ideas and making sure this works for everybody.
>>Nic Haase: Yeah, yeah. Thanks. Totally agree. I don't want to drag it out too long, but one more thing is in terms of, what would be great would maybe be a hands-on presentation of actually using it, if that's possible. I mean, I've used screen readers and so on at some jobs where, which is great. There's no better way than actually having to navigate a site as you're simulating what you actually would have to do or go through to then actually be motivated to change how a site works in that context.
Yeah, you know to really have the hands-on feel of that and maybe if we can have a demo of that and maybe how we at least get a bit closer to how we easily can do that as developers locally. What you know to actually simulate that as a, and obviously not adding too much overhead on it, but just sort of catch the low-hanging fruit I guess early on. And also being more familiar.
>>Danielle Sheffler: Yeah, yeah absolutely. Those, I mean those are fantastic ideas, and I think, and that's really the name of the game, right? It's not just helping people with the education and the learning, but it is about the efficiency. Because we know it's just John and I. That we can't be on every project. But, I mean, again, Alfred and Paul and I have talked about this as well for a long time. I was a single point of failure. That's not good, right?
If i want to be helping so many people, and then that's kind of where it ends. It's great if all of us or as many people as possible have that. And, again, it's not just about having people being accessibility analysts. Again it's about the advocacy and about including what we can to make sure right that we're giving everybody what they need. So, yes, absolutely, we can find some time to do that and, again, I think making sure that we just get feedback from a few people to make sure that - I feel like it can get overwhelming pretty easily so just making sure that that's very targeted. If we need to have a set of sessions and figure out what that looks like, we can definitely move forward with that. So really great, really great suggestions. Alright, thank you.
Okay, I don't think I see any other hands raised, but I know that doesn't mean that no one else has questions or comments, so I wanted to keep it open and see if anybody had anything else.
>>Alfred Deeb: I might just make a final remark, Danielle, because we're obviously out of time. But I think, look, thank you for this presentation. I think it's a great contribution towards us, you know, working towards that authentic accessibility first culture, right? So this is, this has been awesome.
And yeah, thank you. Alright and John, sorry, you too, man. Alright.
>>Danielle Sheffler: Yeah, I definitely had John look over this presentation, and I was like, "Am I missing anything? Can you add?" So, yeah, really, really great again to have John on board. I'm very excited and looking forward to continuing to build the practice and especially for everyone. Thank you so much for coming. I know there is a lot of client work. There is a lot going on, and you took time out of your day, so I really appreciate that as well.
>>Kristen Pol: Thank you so much.
[Group chatter]
