 Greetings, everyone. So glad that you've joined us today for our chat about accessibility, video accessibility plug-in block. And so we look forward to chatting with you guys, especially since you've stayed after the NASA crew has left. So my name is Vaja Parker. I work at WDG. We work with open-source content management systems. WordPress is one of the open-source content management systems that we use. We're actually DC-based right across the River Arlington, and we've had the opportunity to build enterprise WordPress implementations for years now. And so really excited to share some of that experience with you today. I don't live in the area. I'm from Jersey City. So for all of you who are in the northeast in New York City and in that area, really excited to represent from there. And I love biking and hanging out, looking at the view. I'm with you today with our technical director, Curtis, who will be co-presenting with me. Hi, Curtis as well. Like Vaja said, we are DC-based, but half of us are not in DC anymore. I'm actually from the West Coast in the Washington State area. And yes, this is me from a previous life. I no longer do that on the regular, but yes. Code, catching fish, you know. Yes, exactly. But yeah, one of the particular things we want to talk about today is having a client that wants to contribute. And that's one of the big things that we ran into with the Ford Foundation, who's a wonderful client of ours, who wanted, they were facing an end-of-life CMS system that came to us a little over a year ago, and they wanted to move to WordPress and really kind of embrace the whole community as a whole. So it's really nice when a client comes to you and says that and we're like, we want you to focus your work into not just helping us, but to helping the community as well. So having clients actually say that, you know, don't want to keep everything private is a real nice change for some kind. And it would be great to have an office like that, to have a arboretum inside your office, like they do in the Ford Foundation in New York. And that's actually why we decided to give this talk, because as members of the open-source community, we've always tried to challenge ourselves to contribute, but it's rarely initiated by a client. But what we realized is that there are opportunities left on the table. When you work on an individual website and it's not an open-source application or when you build it all custom, then it's just within that one implementation of your CMS. But when you build a plugin and you allow it to be submitted to the community, then it becomes more accessible to all. And the Ford Foundation understood that one of the reasons for moving from proprietary to open-source was so that the good that they coded into their build could be made available to more people. And so I would challenge all of us. The next time we sit down for a paid opportunity, you know, to have that conversation with your client, you know, you're going to an open-source platform. Do you want to contribute any part of it back to the community? And what does that mean for them? What does that mean for us? And how can we start that conversation early? On the Ford Foundation in its mission is about social justice and it's about improving the humanity for people all across the world. And so for them, accessibility and the web was mission-oriented. And so they wanted to take that to heart in everything that they did. And so we ended up coming into the project with this opportunity to build a video accessibility block. They understood that the accessibility that they were providing could serve as a foundation for something that could be used by more people. And so we want to talk a little bit about that process. We'll give a plug-in demo. And we'll talk a little bit about accessibility. We have some WDG devs in the room, too. So if you have technical questions, they'll be able to answer them with Curtis. And we can go ahead and move right along. The first thing is community influence. I think it's amazing how much WordPress has grown. We know all of the big statistics. But that means that we can come to the table and we can bring the improvements for accessibility that end up just trapped into one website. And we can start unlocking them and giving access to others to use them. Now, we all know the big 40%, right? WordPress powers almost 40% of sites on the internet. But what I didn't know was that for all sites that have a CMS, WordPress powers 64.1%. That's from Search Engine Journal. And the closest competitor to that is Shopify, which is powering 3.2% of the market. And so if you're in open source and in WordPress and you release something back out to the WordPress community for WordPress as a CMS, then your reach is amplified because of the reach of the platform. The next thing that was startling when I started looking about where WordPress is today, 30% of the top 1,000 sites use WordPress. And so it's definitely, the data speaks for itself. The transition from the small mom and pop blog site, which is still possible today to being able to power enterprise level experience, it's where we are. But with that, the dark side of platform popularity is that with great power comes great responsibility. And we know that we've been learning that all day today because we've been learning about how not to get hacked, right? And so the positive is that when you introduce something to the platform, its reach can be exponential. The negative is that you're developing on one of the most popular platforms. So the opportunity for you to get hacked ends up great too. Now, why do we bring this up specifically? Today, it's because plugins are the biggest source of WordPress security vulnerabilities. And so if you take out all of the people that didn't harden their passwords and then you leave the rest, it's usually a plugin, a plugin that has introduced a vulnerability. So we don't wanna take it lightly when you have the conversation about contributing a plugin to the community because you could be contributing to the vulnerabilities of the platform if you don't go through the due diligence and the process of making it right. And so it's really important to realize that. It's really important to understand that it's one thing to create your custom functionality and put it in a plugin and put it in your website. It's another thing to release that back out to the community. And you just wanna make sure that you're giving the community all the good and you're not opening it up to the bad. And that was huge for the Ford Foundation. And just so that you guys know, FordFoundation.org is a relaunched experience. You can see their new Gutenberg block implementation of WordPress. You'll also be able to go into their video sections and see the plugin that we're talking about today, which is actually the video accessibility block plugin. It's on that left side of the screen where you see justice by the numbers and we're going to get a little bit more deeper into what that means for us. And so some of the opening questions for you guys to consider are what websites are you migrating from proprietary to open source platforms? You know, think about that the next time you start a project. And if you're bringing something to open source, talk to the people that you're working with, see if there's any part of that that could become something released back out into the community. The second thing is think about the functionality that you're going to need to rebuild. Is that functionality that you're rebuilding because there isn't a popular plugin to support it? Is that an opportunity to introduce that plugin back into the ecosystem? That is something that you should consider from the very beginning. And of course, might the feature benefits that you are building for your clients benefit other people beyond your clients. And if you can think about that at the start of the project, then you can start setting aside the time and the resources toward the end of the project. So that once you launch it for your client, you can come back and refactor it for the community. All right. So let's get a little bit deeper into it. What is this plugin? What is it for? Why did they bring it to the table? All right. And so at the end of the day, the plugin is a video accessibility block. And it was brought to the table because ADA is required. The American Disability Act requires us to make sure that websites are publicly accessible. These are government websites and also other corporate websites that fall into categories that require them to have accessible content. In 1990 is when this act was released and the government will say that they've been suggesting that web content needed to be accessible since 1996. Now there have been revisions to ADA that cover a lot of what we do in the development of WCAG and all of the standards that have been published. A lot of those came out and started to formalize around 2015 and 16. But at the end of the day, if you work with government in the public sector or if you work with entertainment, banks, other parts of the private sector, then you are covered by this need for accessibility. Here's what happens. As soon as the government regulates something, it means that somebody can sue against that regulation. And I feel like accessibility got a bad rap over the last 10 or so years because people just started filing lawsuits to make websites more acceptable. And it became a challenge to the community to do better, mostly because the people were paying us did not want to be sued. It's important for us to realize that accessibility is more than not getting sued. And we will talk about that in just a moment. But there were 2,387 federal lawsuits filed in 2022. That's last year against companies for non-accessible websites. So people do care and it is their right to sue. So if you come to a website with a disability and you're not able to understand the content or operate the website, if it is to be supposed to be accessible under ADA, you can be sued for it. And many websites have accessibility errors. Now, one of those websites that got caught up in the mix was actually Beyonce.com. It was one of the lawsuits that popularized accessibility and problems. And it became this new effort, a new initiative to double back down on making things available. What happened with Beyonce.com? There was a blind fan that came to the website to purchase a ticket. And she could not navigate the experience because it was filled with visuals that did not have proper alt-text for her to appreciate the path for her to navigate towards her purchase. And so she did sue the entertainment company that was responsible for Beyonce.com for the things that we hear every time we talk about accessibility, lack of alt-text on graphics and navigation links, inaccessible, drop-down menus, inadequate, prompting and labeling, the denial of keyboard access, empty links that contain no text, redundant links where adjacent links go to the same URL address and mouse-only transactions. Literally textbook, it's like the top five or six things that you have to do before you launch a website and you know that it's accessible. Those were the things that this company got sued for. And so if nothing else we should be able to define what I will qualify as some of the lower-hanging fruit for our accessibility measures so that we can start making sure that people can use the web content that we post. The biggest takeaway here though is that of course you don't wanna be the agency that designs the website that gets their client sued, but let's get beyond that because it really isn't about the lawsuit, it is about access to content. And that is what Ford Foundation wanted us to understand. This is less about them getting sued because they have an inaccessible experience. This is more about them making sure that their great content is appreciated by as many people that can do that and they have been willing to make investments. Amanda Blade, one of the senior developers at WDG, the whole definition of accessibility is to break down those barriers. So everyone has the same functionality across the board and are able to do all the same things no matter what. That really is the goal, right? WCAG is gonna give us a checklist for compliance, but the goal is to make your content as accessible as possible. Now some of it starts and ends with us when we position a content management system, but other times you have to pick up with the client. So for the Ford Foundation, they came to us with content that was already accessible. So they came to us with videos that already had audio description narratives baked into them so that if you were unable to see the content of the video, then your screen reader, when it read the transcript or when you appreciated it through another tool, it would read to you the narration of the visual objects in the video that you could not see. And because they had that content already, we began to build plugins and things around that. Before we get specifically into the plugin itself, let's just talk about some web accessibility tips overall. Web and textability standards are broken down into three category, right? There's content and that's all the website parts and the code, all right? And so most of us, when we deal with WordPress and when we deal with web accessibility, we're really working on the content, but there are a couple other layers, right? There's the user agent, that's the browsers, that's the media players, that's the assistive technology to read the content on the experience and then there's software, that's the authoring tools. That's how we give people the power to make their content more accessible. All of these things matter when you're bringing accessibility to the table, right? So if you have an image and then that image needs alt text, that image needs alt text so that the browser or the screen reader can interpret it accordingly. And so you create that rich alt text with the source software tool and that's what makes your stack. So when we're working with WordPress, right? We have that WordPress admin layer, that's where you're going to add a lot of the accessibility alternatives for text alternates. You have your user agent, that's what's gonna rely on that metadata so that your content can actually be appreciated. It is so important that we understand that accessibility is about perceivable information. It is about operable interfaces. It's about understandable content and it's about robust compatibility because in order for some users to appreciate your content they're going to have to do it through tools that you had not already positioned. They're gonna bring their tools to the table to interpret your content. All right, quick question in the room. How many of you do develop with accessibility levels in mind? Excellent. How many of us are striving for level A to start? All right, and then double A? Okay, and then triple A. All right, that's usually the mix, right? A will leave you at some minimal accessibility but you're likely not to be compliant. And it's usually why nobody starts and ends there. Double A is where all of our projects start because that's where you can get compliance out of the project. That's likely what a lot of our tools are trying to get you to understand. And triple A for us comes up most specifically often in government context. And in government context when there's a specific disability in mind that they're trying to increase usability against. So for example, you might be in a context where your video is created but you need to include sign language. The recording of the sign language in your video in order for it to be triple A, okay? All right, so in working with the Ford Foundation we were trying to get to double A and we were bringing forward the accessibility principles. Why did I put these up here? All of us are working on accessibility and I can tell you that I've worked with and that I've sold accessibility and that I had not read through all the principles on WCAG. And if you have done the same things like use a color contrast tool in order for your designs to be correct but never actually read the documentation. I actually wanted to encourage you to do that. Do it while you're here, do it while you're bored in this presentation. It's actually really, really well written and straightforward. And it takes us out of the crud of compliance and lawsuits and it brings us back down to why we create websites anyway so that user information is easily and readily available. And so the accessibility principles are really well written and I'm going to go through all of them very quickly just so that you can say that you heard them and read them once, yeah? All right, one, text alternatives for non-text content. That is the most common thing that we need. It's often translated into captions and other alternatives for multimedia, right? And so those first two things can go the farthest. That means anytime you have image or video then you're going to need something else as an alternative for it for somebody that cannot hear or cannot see. And so those are the first two principles. Text alternatives, alternatives for multimedia. Number three, content can be adapted to be presented in different ways. You can't be so attached to your user interface design that you think that that is the only way and users will visualize your content or hear your content or consume your content. Your content has to be almost headless from the interface so to speak so that other assistive tools can pick it up and digest it for the end user that needs it in a different way. Four, content is easier to see and hear. This is usually the level that we never get to as designers and developers because the content layers when the client comes in and enriches their new CMS with everything that we have and we usually just back away slowly from that but it's always a good conversation to have with your client. How can this be made easier to appreciate? That's why we developed this plug-in for Ford Foundation. Five, users have enough time to read and use the content and that has a lot to do with what's going on with interaction and the screen with what's happening with the content and its accessibility to the end user so that it can actually be consumed and content cannot cause seizures and physical reactions and that will be in every accessibility principle that comes back to and there's a set of things that must be considered. Seven, users can easily navigate, find content and determine where they are. Did you use the last site you launched with your keyboard and not your mouse and make sure that it worked with your keyboard and not your mouse? Because if it doesn't work with your keyboard then you haven't made it easily navigable by those that have other means to engage with content. Eight, users can use different input modalities beyond the keyboard and so you have to make sure that you can help an end user get through the experience. I feel like about five years ago we felt really good about accessibility when we made sure we didn't exclude the skip link, right? For the navigation. It was like, all right, we did the one thing but we are so far beyond that and people need so much more from the internet that we have to keep pushing. Nine, text is readable and understandable. Ten, content appears and operates in predictable ways. Eleven, users are helped to avoid and correct mistakes. So, eleven is really interesting. Eleven is kind of like, if you're doing something and you're going through and you're providing text alternatives and then you don't provide it for a section, you don't want the end user to think that that section is empty. It's actually better to tell them that something's not done than for them to get to a part where they can interpret it with the alternative text. And so you help the end user from drawing the wrong conclusion as they navigate the experience. And lastly, content is compatible with current and future user tools and so that extending the compatibility of content is something that we're used to, right? Because cross browser experiences, challenge or compatibility, it's like that before accessibility. So don't forget the accessibility principles because they become really important when it's time to get down to what goes wrong. There is a project out, it's the web aim, a million project. It went through 100,000 home pages and it distilled some information from their check of those things. And these are the top six WCAG failures. And so, and they're not any surprise to us, right? One, low contrast text. Two, missing alternative text. Three, empty links. Four, missing form labels. Five, empty button. Six, missing document language. Ouch on six, yeah? But those six things, again, are the most popular ways in which accessibility does not come through to our end users that need them. The good thing is that these are probably the six things that are most easy to alleviate if we can empower our end users to do so. 96.1% of all errors detected from that survey of 100,000 home pages fell into these six mistakes. If you can make sure that what you launch for your clients is without these six mistakes and you've gone much farther than most. All right, so let's get beyond some of the most popular mistakes with accessibility. And let's talk a little bit more about video. We made a video accessibility block. And why did we do that? We did that because the Ford Foundation and creating its videos were creating two versions of their video. And so there was a version that was for people that could hear and see and it was completed. And then they create another version of the same video for those that cannot see the video. And in that video is what is called a narrative description. And the narrative description is there so that it can be read to somebody that cannot see the visual. So if you see the screenshot, right? It has text in the video. And it says location, Massachusetts. You know, it was one of those intros where you can hear the typewriter t-t-t-t-t-t. And it types in all the letters in the front, right? But if you cannot see that, then you've missed the context of location, right? And so the video has to narrate that there is text typing on the screen that says location, Massachusetts, right? And so they created another video that includes this narration. So now they have two videos for every one video. And so we created a plugin for them to switch between their videos. And in that plugin is the opportunity to have a transcript that includes the narration. And then you have the opportunity to also click into more accessibility information. Because at the end of the day, you want the screen reader to be able to read the description. A large blinking cursor on a screen, words appear in digital type, location, Massachusetts. That is from the audio described narrative in the second video. And so for every one video, the Ford Foundation invested in the audio described narrative for the second video to make it more accessible for those that had different needs. And so accessible video, yes, it's multi-media. So you need captions, you need descriptions, you need a transcript. It requires intentional workflows, right? And those workflows start before it's time to reference the video. You know, this is about content production and producing robust content. This is something that you have to come into the process with. Third, you do need an accessible media player. Know that our plugin is not a media player. The videos for the Ford Foundation are hosted and maintained on YouTube. And in Vimeo, our plugin works with YouTube and Vimeo APIs. The player itself is coming from YouTube and video. It's not a media player. But you know that you have to have an accessible media player when you're trying to offer accessible video. And then some videos also, like I said, need sign language for AAA. That wasn't the case for us. All right, and then there are variable requirements for video depending on if it's prerecorded or live. As you've seen, there is live video transcription happening right now because that is a great recommendation for live video. There are parameters for prerecorded video. And it also matters if your video is with audio or audio only. So your requirements for accessibility will change depending on those things. And then lastly, this audio description of visual information is required for prerecorded videos if there is important visual information. So it is required, okay? If there's important visual information, you should have audio described video. All right, so here we are, the plugin itself. And I'm going to go ahead and let Curtis talk directly to the plugin and to building the plugin into launching it. Thanks, excuse me, thanks Vaja. That was a great introduction and why we all want to do this. Ford Foundation in particular was an excellent client about having this really at their core. This is the principles that they believe that you can't tell your users they're doing it wrong. You based on some kind of disability that they have. They are, you can tell your admin users that you're doing it wrong, but you can't tell your end users that you're doing it wrong because they have no other option in that case. So a lot of clients used to not care about that. It's wonderful to see clients making this, not just their purpose, but part of their whole mission. And being a foundation like Ford is a great example of that. The other thing I would like to add, when you go through the plugin, like Vaja said, it's not a video player. I just want to make that very clear. We do work with YouTube, Vimeo and self-hosted videos for this, but it really is just kind of a framework for presenting, being able to switch between these videos at any given point. And so at that, what you do is you go in, you create a video or you embed your video, or you can upload your video directly into the spot. And then you have a few different options. There is some transcripts location and there's also this global accessibility statement that Ford came with that you wanted to tell people what they will expect from their accessibility. And that's always an option. So what we ended up doing, we created this kind of two column layout heavily inspired by YouTube. To really have the functionality right in line there. So we have the transcript available over here on the right by default. And then you have the accessibility statement that you can toggle to those buttons down below the player itself. Those are actually inspired, but those are just kind of a tab structure, if you will say. The first button is special because it actually swaps between the videos. And then the other ones are configurable where you can add multiple different types of things. You can have a transcript, you can upload it. If you have a text file or a VTT file from your video production, and that will automatically be imported here. And then you can also, if you don't have any of that available, you can actually just type out your transcript directly in that sidebar. So that's what this plugin was about. This came from their old CMS, they had that, and they really wanted to bring this forward to their new platform and reach out. One thing I wanna say about this plugin, it is we have not released it yet. Ford Foundation just relaunched their WordPress to build just a couple of weeks ago. Client work comes first, but then we were planning on releasing it to the plugin. Plus, we just went through a rename of the plugin, because there's two things that are hard in computer science, caching, naming things, and being off by one. But this will be available in the near future. And we encourage you, if you care about this, come help us build this, we'll have pull requests available on GitHub. We'll have comments, we'll have issues. We want people who care about this to really help us build this. And Ford Foundation is really also wanting to push this forward. So please come help us if you do care about this. So this is the dev site of the Ford Foundation, and we'll just do a quick demo here. The videos we have here, oh, no, no, put this down. Is this one on? Is this one on here? Can you turn that up? So I'm just gonna go into one of these videos here to start someone that's already created. We have a whole video content type for them. And so one of the things that we have, oh, full screen, yep. Not used to Mac. All right, so one of the things we have here, Vaja also has her computer scroll backwards, but I digress. So you can see here, it's a bit bare bones because we want this to kind of blend in with people's themes as well as possible. The button styles here are directly WP block button and WP block button link for the CSS selectors. So it should blend in. Now, of course you can override any CSS you want here if you want to customize it further. But that's what we thought would be the most sensible option as a default for people coming in here. Now, this is Gutenberg only. We don't have a short code version of this for anyone that's still using Classic Editor or things like that. So you can see here, we've got the video, I'll go ahead and add a new one here at the bottom. Just show a hand, how many people are building with custom Gutenberg block? All right, great. That was a big concern of mine. I was nervous because it doesn't have Classic Editor support yet. Yep, and I actually don't think that's in the plans. So I think that if the, and that's where the GitHub comes into play. If you do care about this in the Classic Editor support, that's not been our focus for Ford Foundation in particular, come in and help us build that. PRs are open, as we would say. So as you see here, it's very basic at the beginning. You have the embed URL, you have the video, the ability to switch between the two videos here. So you can click in here and I'm actually gonna go edit the secondary video now. And this is not, the primary use case for Ford is like Vajra mentioned, is switching between the audio version and the audio described video. And that's why it's currently called video switcher. Now we've kind of renamed it and we'll be going through that process to kind of update the code to reflect that before we release it openly. But you could also use this in other contexts. You can not just use this for audio descriptions. You could use this for multi-lingual videos. Say you have one in English, one in Spanish or any other language. You could use it for the exact same thing. And so here we have just kind of some tab structures. And then you have this accessibility statement that Ford has placed. And one of the things that we did with the accessibility statement in particular, that's not something you wanna edit on every post if you have a consistent one. So this is actually done in a settings page where you can go and where you can go and edit the, see it's currently called video switcher. I'll stay here for now. But the idea here is you have this accessibility statement across all of your video usage of that. We can disable this if you don't have an accessibility statement, but highly encouraged to let people know your commitment to making all of this accessible. So what we have then, you have your two URLs here. So if we go back to the other one, I'll just copy this URL. This is your standard embed block. This is nothing super fancy or technical here. The one thing that we did add to the core embed blocks looks like it's having an issue rendering at the moment. We did add all the video schema from the YouTube and Vimeo APIs. This also helps in letting screen readers in particular know more information about the video than just the video itself. So we actually go and grab the public information from the YouTube API and we also support an API key in order to get extended descriptions from YouTube. And it automatically adds this to every YouTube and video block even if it's not part of the video switcher or this particular block itself. And we also add it for the core WordPress videos as well. So it adds a schema data, metadata structure, kind of like H cards, the micro schema features of HTML. So you can see all of this data here. You can use this if you need to. And then you come in here, wrong one. So you can edit this one, this URL. We have an update to this where it'll make it a little bit easier to switch between the videos. Currently, you have to go down to this button here and then toggle between the two. We're actually gonna render it where you have both videos rendered on top of each other. There's always a debate in our development teams is do you make it exactly like the front end or do you make it easier for the editors? That's always to pick your poison on that one. So in the back end particular. So that's what we have here. So you can, I'll just embed the same video twice. Not what you would actually want to do. So then that's what you do. And then if you come back down to the transcript, you have the ability to upload a transcript. Currently, we're only supporting text and VTT files at the moment. We're debating whether we add more support for more formats, whether more that makes sense. We were thinking about, if you only have a PDF, is it okay if we grab that and put a download link to the PDF as opposed because you can't really render that in line. But that's really kind of going against what we're trying to do here where you're seeing it in the context of the video. So that's where we've landed at this point. Yeah, so this, and then if you go to the front end of this. So this is what it ends up looking like on the front end once YouTube renders itself. And we have this accessibility statement here shown by default and let's see. Apparently the Wi-Fi is not great today. Let's try a different video. No, there we go. So this one only has, so yeah, that's the other thing. This one only has one. This, you can use this video with or without, or this block with or without audio descriptions and get all of the additional transcript features that are kind of built into it. So let's see, let's find one that actually has two videos. What was the one you were working on? Yeah, so you can come in here and this is a much better example. So you can see here, we've got the videos here. We've got actually a download transcript button. That's the other thing we did on this sidebar. We don't know what we can limit you to. So we did make these kind of generic sidebar panels and you can create any block that you want in there. We created inner blocks to place within that panel so that you can really, if you have additional needs or you have additional blocks, you can integrate them well together just by placing them inside our panel. So you can see here, you have the transcript. You can download it. You can have the accessibility statement here as well and then you can switch between the versions. One thing that we have planned that is not available yet is that we will be able to synchronize the timestamps when you switch between the videos. Because currently when you switch between the videos it starts at the beginning because you know you're swapping embeds and that can get complicated. So an addition, one thing that we're targeting for the future is switching to that point in the video when you click to switch. So that's on our roadmap as well. So yeah, I think it's fairly, when you think about it and really boil down to it is really using it in an intelligent way and having a commitment to the process of building your video descriptions this way. Yeah, so at this point, I think it's a pretty good overview. We will have it on GitHub soon. Come join us if you care about this and wanna help us build a better version of this. So thanks. All right, before you guys leave, one, don't forget video accessibility block is what it will be called. And then two, just wanna close out with a few more considerations. If you are going to go ahead and bring something all the way through to the community. The goal about that first, let's jump into a couple of the other use cases. Because audio-described video isn't very popular in my experience. The four foundation creating these additional videos was an investment in accessibility. And so if you do end up having videos to switch between for language or for accessibility purposes, then that is the primary use case for this plugin, right? But just like her said, there are secondary use cases that you can get into. And so if you ever have a video and maybe you have a video in a behind the scenes, you could actually use it just switched between the behind the scenes. If you had a before and after video, like you're doing some kind of reveal, even if it's a website preview, you know, you can do a video before you can do a video of after. What will this allow you to do? It will allow you to pick to YouTube, to Vimeo, to self-hosted videos. It would allow you to serve them and toggle between them with a transcript that can be downloaded and an extra statement that we're leveraging as an accessibility statement. And so definitely look into it for the primary use case for accessibility as well as for the secondary use cases. At the end of the day though, we want you to know that once you launch something for the client, it's all about the relationship that you maintain with the client. When you launch something to the community, you are making a commitment to support what you've launched to the community for as long as you keep it in the repo. That is the biggest challenge when you choose to contribute a plugin, all of us know. And so if you go to do that, you know, you can't have your plugin being the forgotten one, right? Because then you end up vulnerable to introducing attack to the system through those that use your plugin. And so the biggest thing that we would just like leave you with is the commitment. You know, you have to go through your code quality, your documentation, your user experience, your testing, and then you have to plan for support and maintenance. And so we're grateful for an ongoing relationship with the Ford Foundation so that we can continue to maintain this plugin. But primarily once it's in the community, you know, it will be a community code base that will have to be maintained and updated separately than the code base that we're using for the client in the event that there are any differences in those changes. And so don't forget that if you're contributing to the community of plugin, you cannot abandon it because have you been there? We've been there. Have you relied on plugins that were no longer maintained? Uh-huh. Do you contribute to WordPress plugins? If so, then you know the time it takes to actually make a meaningful contribution. And then lastly, if you're currently maintaining a WordPress plugin, you have to plan to prioritize maintenance before. It will be transparent. You know, we're an agency. We have contributed plugins before. The biggest challenge is planning to support that plugin once it's introduced to the repo. All right, so we have like five minutes for questions. If you have any questions on accessibility, on the Video Accessibility plugin, or anything related to our work for the Ford Foundation. I don't believe so. Had not thought of that at this point. Right, you'd get just the straight up audio player. Yeah, no, that has not been a consideration at this point, but that would be a great, I think, suggestion going forward. I had a few questions. The first is, since it is a Gutenberg block, have you done any user testing with users that would be using screen readers? Because I mean, I know from my experience, it's very difficult to navigate Gutenberg. It absolutely is. And we were targeting the front end user first. We did do some extensive screen reader testing, since that's our primary use case for this video, or for this feature. We have a little block at the beginning for the screen reader only that says a audio described version of this video is available, so that you get to that video and you can switch to it before having to go through all of the videos of the, or all of the controls of the primary video. Does that make sense? Yeah, I'm more talking about from the editor. In the editor itself, yeah. The, we did follow Gutenberg best practices. We kind of kept it fairly simple as far as the block structure itself. And I think that's like a, there's six or seven blocks that we created that were all used in combination, but we didn't do extensive user testing of the admin. And so that would be a wonderful addition if you guys are able to help contribute that. All right, any other questions? Yep. Is Ford Foundation involved in the discussions of you open sourcing it and supporting it? They are actually the proponents of it. Yes. No, absolutely, it was their idea. We absolutely supported it. And they plan on keeping it going and it's gonna be part of their GitHub actually, their GitHub organization. And even if they no longer have a relationship with WDG at some point, they will keep that going as their commitment to WordPress in the long term. I got what you said. For anyone else that didn't hear is, were there any challenges bringing it over from the external CMS to the new WordPress one? They did a really good job of documenting the features that we needed to have. So we actually didn't need to dig into what the previous system had. We just had the requirements for the new one. And at that point, it was much easier to scaffold out and build everything that we needed to. So yeah, right up. Yeah, you spoke about making sure that the text content for accessibility, that text is readable and understandable. So I guess how do you make sure you do that in an accessible way? Like how do you take text and make sure that it's accessible and readable, so to speak, in an accessible way? You're talking about the text inside the video? Oh no, I'm just talking about accessibility in general. Oh, in general. Beyond just making sure that it's not up against a background that makes it harder to read. Like what's the actual process of doing it? Oh, absolutely. I mean, WordPress has some controls in some areas for text contrast ratios. But that goes into the full process of the design. You have to have color schemes that make sense as far as color schemes. Now, as far as making text understandable, nothing beats actually using a screen reader. And a lot of times the order of text may make sense in a visual format, but it doesn't make sense from a screen reader format. So document source order is important no matter what your designers tell you. All right, we are at time. We are really grateful for your questions and for your attention and look up the Video Accessibility plugin. It'll be released soon.