 I would also like to give a shout out to Christian Hemphling who is a extremely valuable member of the community, does so much work on plasma accessibility and has so much passion for it and who proposed the first accessibility goal in 2019 and it's great to have the accessibility goal elected as one of our goals for the coming few years. And with that in mind, if you're in this room right now, I imagine you're someone who cares about the growth of KDE as an organization, the spread and adoption of free software by people everywhere and that's what I'm going to talk about today through the lens of accessibility and compliance specifically. So I am David Collane. I've been a KDE contributor since 2018, starting in promo and communications, also doing some builds and packaging. And I am a cloud and infrastructure engineer at Bixel. Bixel is a contractor who works pretty much exclusively with the United States federal government. So accessibility is a hot topic there. It's highly important and we're going to get into some of those regulations today at least at a high level. And in terms of my duties and job, I do a lot of DevOps and infrastructure operations. And let's actually get started. So what is accessibility in the first place? That word gets thrown around a lot, but let's just make sure we know what we're talking about. And what it really is fundamentally is just to make a product usable for as many people as possible. And that's regardless of any physical or cognitive disability or any kind of other impairment that they might have or even according to some definitions, socioeconomic status, which at least on that front KDE I think does very well. And this includes not just physical and cognitive, but also as a further example, vision problems hearing problems, limitations with motor skills and cognitive and neurological issues. According to the CDC, 26% of Americans self-identify as having some sort of disability at least in a minor capacity, for example, that includes needing eyeglasses. That still is an important consideration of vision when you are designing software or a graphical interface that people need to work with on a daily basis. So accessibility, why is it so important for KDE? Well, there's a number of reasons. Accessibility sits at the nexus of several of the proposed KDE goals that came up in the last couple months. First, professionalism becoming an enterprise grade organization that can deliver enterprise grade software. In order to actually get our software adopted at a wider and broader level in major institutions, we're going to need really good or passable and functional and highly rated accessibility and compliance. And this is also just fundamental to human-centered design and the principles of human-centered design because accessibility in many respects determines if big enterprises, public or private, can legally use the software. And this has a knock-on effect that because of that, down the road, this also impacts how many people are going to be exposed to KDE software or free software in general. We all know that since the early days of Linux user groups, the free software movement and community has targeted public institutions as the center of our growth and evangelism efforts. And KDE is no exception to that. For example, some of the history here, Brazil in 2008, KDE software was deployed to school computers serving up to 52 million students based on the activity in the computer labs there. We have active contributors today who discovered KDE and discovered free software through that initiative. Valencia in Spain, long-standing relationship with KDE, 120,000 or more school computers in their system are running a plasma-based distribution, LIREX. And in fact, Valencia has no budget for proprietary software in the schools except for 10 schools with special needs. Now you can see where this is going. This is a highly important issue, but also I want to highlight that we do continue to have success in the education sector more recently in Kerala, India. That's a state in India where a plasma-based and KDE software using distribution is deployed in their schools and the government there announced a plan to train and teach 38,000 teachers to use KDE software. And this is a major, major, major push in terms of how we get KDE in front of people. And it's extremely important that we keep up with the evolving standards of accessibility and compliance and KDE, it's fundamental to our growth as an organization to keep the pace and maintain a high level of accessibility in our software. Now in terms of some of the regulations, the most widespread standard for accessibility in any type of software is in fact WCAG that stands for Web Content Accessibility Guidelines. This is a standard from the World Wide Web Consortium and even for desktop software. This is referenced in law in United States law, in European law in many countries, WCAG is the standard even for desktop software. Now WCAG organizes itself into, it describes itself in a matter of principles, the most important part of understanding these principles is in general the idea that anyone with an impairment should be able to assess content using an alternative sense. So if someone has a hearing impairment, they can use their vision. If someone has a vision impairment, they can use their hearing to aid in their comprehension and understanding of the material. Also important is the ability for people with mobility constraints to use their preferred input methods. This can be a keyboard driven navigation or mouse exclusive or alternative devices altogether. And in the United States, who was a pioneer in this respect in terms of digital accessibility law, one of the most fundamental pieces of legislation was Section 508, which was a 1998 amendment to the Rehabilitation Act of 1973. This functionally puts WCAG 2.0 into law in the United States and government institutions must have a WCAG compliance for not just their websites, but their desktop software and there are even significant regulations on devices and hardware as well. Another important law to consider here is the Americans with Disability Act, which was passed in 1990. This is broader in scope. It's meant to be a holistic protection of the rights of disabled people in society. It's also important for our purposes for understanding the fact that the ADA applies to public and private enterprises and that anybody who is an employee of a company or a citizen who is trying to receive some sort of service from the government has a right to request an alternative tool or device or what have you if the device that was granted to them or their working conditions are not accessible to them. So there's a degree of personalized guarantee in terms of what needs to be delivered. And this comes into play when companies or government entities are considering what vendor are they going to go with for their operating system or a certain application. Are they going to go with an application which is not accessible by default and then they would have to budget for an alternative in the event that they have disabled employees or disabled customers. And so this is why it's very important in terms of adoption that we maintain a competitive level of providing accessibility options. And in terms of the European Union, the European Union first set out to create a European wide standard with the Riga Declaration in 2006, which cited Section 508 as something to be influenced by or aspire to as a model for what they were trying to do. And eventually this culminated in the excitingly named standard EN301549. So this current version of this European standard is based on WCAG 2.1 as a baseline level of accessibility 2.1 is a substantial improvement over 2.0 in the sense that it provides additional measures for people with neurological issues, photosensitivity, I think memory problems and cognitive issues of that nature. In addition EN301549 applies not just to public websites, but like Section 508 also has regulations in place for desktop software, hardware, and mobile applications for government entities. And some of the national laws are important to consider as well because up until fairly recently there was no European wide standard in Germany. Some of the most important laws here are BITV, which was passed in 2002. That stands for Barrier Free IT Declaration. Now in its current form, updated in 2019, this essentially just matches the EN301549. There is also the BGG or the Disability Equality Act passed in 2002, which like the ADA is broader in scope and meant to provide certain guarantees to disabled people in society. In Spain there is Law 34 of 2002. Now this is since 2012 a WCAG 2.0 compliant, so that's not yet matching the European guidelines, but it does match at least the Section 508 standard. And in Belgium also there's a law called the Law of July 19, 2018. This now of course also matches the EN301549 standard. But important to note here is that for public websites in Belgium, if the website is not fully compliant with WCAG standards, they must include a list of all WCAG criteria which are not fully met and cite the WCAG criteria annotation that they are missing. So there must be a list present of not missing or inaccessible WCAG criteria. And that's important to note as we get into this next topic, which is the topic of VPAT and ACRs. Okay, so what is this stuff? So this actually is highly relevant to KDE because last year we received a request for VPAT from NASA. So somebody from NASA actually wanted to use Labplot at work for their purposes, whatever these crazy people at NASA are doing. So the initial KDE response was a bit lacking. People didn't know what a VPAT was. They just saw an email come in from a US government agency that had a lot of legalese in it and it was talking about some government document. So understandably, I can understand many people in that situation would have a desire to rage against the machine. But what we actually do want to cooperate on this type of thing because the VPAT is the Voluntary Product Accessibility Template, which is essentially an extremely thorough accessibility checklist that works the same way as the Belgian law. It is a list, a self-assessment of WCAG compliance and you need to itemize the different criteria for WCAG and see where you are strong and where you may fall short based on your own recognition. This is important because the VPAT is essentially the first step towards getting an Accessibility Conformance Report or an ACR. An ACR is a US government requirement that any software that needs to be used by the government requires this ACR. So without it, it's going to be difficult to get permission to actually adopt at least on more than a personal level, certain applications. Now, in terms of the accessibility goal, which I'm very happy just was announced earlier this morning, I think this would be worthwhile to maybe consider going through and doing a VPAT for specific applications that we know are targeting enterprise customers or users. That would be a lab plot, for instance, G-Compre is a highly successful education-based software. We just had earlier this year a Belgian educators conference where there was a good reception for G-Compre. And I think Ocular would be a good candidate for that as well. We do know that one of our newspaper, there's a newspaper in India that our KDE-India folks helped get onboarded and using KDE software, including Ocular, in the business of their newspaper. And so as far as I want to briefly go back a little bit in time so we can highlight just how significant the work is that KDE contributors in the accessibility department have been doing for a number of years and show some appreciation for those folks. When Plasma 5 first shipped, it was not the most accessible thing in the world. And Frederick Gladhorn and a few other people spent a lot of time going back through the code base and doing what is essentially labeling. So this is going through individual objects in the code base and saying like, oh, we're going to add focus true here so individual elements can be focused. And accessible.name also important. These are labels that are applied to facilitate keyboard navigation, create grabable elements. And this is important not just for people who are dependent on keyboard, but it's also essential for how Orca functions. Orca is the speech of the screen reader on Linux. This is a GNOME program and this is vital, absolutely 100% vital for blind people and people with serious vision impairments. This is how they use the computer. A device is reading the screen out to them and this depends on the grabable elements and it also depends on the labeling to some extent. And this is important because even though a number of years have gone by and we've made significant improvements in this area, just because of the scale and size of KDE software, there's still lots of this kind of labeling that can be done to improve further our accessibility. Now in 2019, Christian Hemfling dropped an accessibility goal proposal with the goal of raising awareness for what was going on in accessibility and putting a spotlight on these issues. We didn't get the goal then, but what did happen was that accessibility was added to the HIG shortly thereafter. So our human interface guidelines, there was an accessibility section which was added to that, that was a very important milestone. And in 2020, Carl wrote an accessibility checklist and also added that and that was a significant step forward. And we can see I asked Christian to put together a sort of review for the changes in accessibility from that initial proposal in 2019 and on through today. And some of you, many of you may have seen that. He actually posted a blog post to two parter that went over some of these issues just very briefly, maybe running low on time here. One of the great highlights was the new kickoff. The new kickoff is one of the things that was built after these other things that I just mentioned like the accessibility checklist and so on. So this was a vast improvement. There was a lot of, this shows the benefit of accessibility being part of the development process from the beginning. And then we can have a strong, robust level of accessibility. Instead of the alternative to that, of course, is people trying to go back after the fact and fix things up. Of course kickoff was a rewrite and it was only after the rewrite was finished that we were able to close bugs from 2018. So there are limitations to what can be fixed after the fact. It's essential that developers are really working with accessibility folks in the process. And I think kickoff was an example of that showing and yielding great results. And there's still a lot of work to be done. For example, SDDM can't even start ORCA while SDDM is up before the actual plasma session begins. So that's a difficult problem. There's, of course, various issues with adding and arranging widgets and specific plasmoids. However, even since Christian posted his blog up, people responded very well to that. And there have been improvements on, for example, the network manager plasmoid and the volume control plasmoid. So that's great to see that level of enthusiasm and work being put in there. One thing that labeling can help with still is there are still lots of elements not being spoken by ORCA when it's trying to read what is present. So I think labeling can help there with things like context menu entries and various missing elements in plasmoids and other places. So to wrap things up here so we can maybe have a little bit of a Q&A, it's great to see more interest than ever in accessibility. And this is absolutely fantastic. But I'm very pleased that we got that goal. I'm looking forward to seeing what can happen there. And Carl and Christian have been building up a new accessibility team. There's a lot of new people in the last year or two. And from a developer standpoint, I think it's important to consider reaching out to accessibility people, having accessibility testing integrated into the development cycle, that's really the number one issue. And use the accessibility checklist. Another thing I would point out is I think we would benefit greatly from a closer relationship with the ORCA developers. I know the maintainer, Joan Marie Diggs, has been active in KDE spaces on and off whenever usually there's activity on the KDE side. So I think there's a lot of potential there that would be beneficial as well. And despite the focus of this talk really being on the impact of accessibility on enterprise and how important it is in the enterprise world, the main motivation for trying to raise the profile for accessibility is ultimately just so we can live up to our KDE manifesto, create an operating system and suite of applications that is free and available for people to use and for anybody to use. We do have, waiting in the wings, a certain community of people who are very happy anytime new accessibility improvement gets merged. And it's important to remember those people, those are the users who are even more than typical users, in many cases dependent upon their computer systems and their electronic devices for their quality of life. And it's always a pleasure, anything that we can do to empower people through the power of free software and our KDE software. So thank you everyone for being here with me this afternoon, if you're in Spain. And if we have any time for Q&A, go ahead and field any questions you've got. All right, let me check for online questions as well. So Victoria asks, one of our new KDE goals is having better internal processes. KDE isn't inaccessible by random chance, but because devs aren't great at it. What dev processes would you change or what dev processes changes would reverse that, would improve it? Well, I think I showed earlier, maybe like a few years ago, it was fairly common it seemed that accessibility folks were not included during development of like Plasma 5, especially when it was first being really the transition from 4 to 5. But I feel like we are moving in the right direction with that. That's why I wanted to stress that having accessibility testing during the development process, that is the number one thing that can make improvements there. And we saw those improvements in real time with, for example, again, the kickoff rewrite. And Harold, I know, has recently been working on trying to get some sort of automated testing for accessibility and compliance issues. If we can pull that off, that would be a very significant achievement as well. So I think we're on the right track. We do have some ideas of where we're going to go. So we just need to be able to execute on those and I think we'll have a major improvement overall. As well as closer relationship with the known folks and the Orca developers and other members of the accessibility community in the Linux sphere who are not internal to KDE as an organization. All right, Harold is right here. And there's one other question or more of a comment coming in from Ingo who writes, I spent months improving the accessibility of Cleopatra, the GPG key manager, which is used by German and other European government agencies. I'd really like to share my experience with Qt. I guess that's more of a comment about how things could be better. So that's something for later. I imagine we will have some kind of sprint or get together to talk more about accessibility and specific projects. But Andy has a question. I'm not sure if we've met before, David, but this is Andy. And I was going to say, if you haven't had a chance to talk to visual design developers, you're welcome to always join the Telegram channel that we have for that. It's I think I'd like to make a little bit of an excuse for the non-inclusion of some of these standards. And I think it's not because there is no desire among visual designers to get this done is that sometimes it's simply not on the table. And because of the nomenclature of people that we have, we have a lot of junior developers, a lot of seasoned developers that simply this is not a focus. What they what they aim for is to get their code out. You know, this is exciting, this is cool. I would love somebody can adopt it. But in that, I think we definitely can do a better job of saying, you know, before we merge any of this, let's make sure that you are, you know, compliant in some of these areas. I personally have worked in my professional life with some accessibility and building VPAT, I mean, making sure the VPAT is completed properly for my work. But I don't think we've formally had discussions like that here. But those discussions are welcome. And those discussions are always on the table. And so if you want to like have a more focused kind of access to the group in that regard, the visual design group is generally a good place to go. I doubt Carl and others, you know, have seen any negative feedback from requests like that. So I think we're very open to, you know, let's go with it. We're all about integration. So just kind of a heads up for you there. Well, thank you for that. And I agree. I think the visual design group actually does a good job with concern for accessibility issues. I think that we have improved a lot. Some of the worst examples that I gave there are maybe a couple of years old now. My intention I suppose was to show the improvement. I think we're on the right track. I do think that you're right that some developers don't even think about accessibility which is not in a negative sense, but they just don't consider it. And that's part of the reason why we have talks like this, why we have like the goal proposal, which was very well received. And I think communication is important on this front communication and education and showing people the benefits not just to disabled users or what have you, but to KDE as an organization and to our future growth. That's kind of the intent is try to get people maybe a little more excited or start thinking about accessibility and its place in software development. So thank you for your remarks. And I do appreciate the work that people put in on trying to improve the situation as well. And I think we are on the right track for sure. All right. Thank you, David. We are on the right track, but we can get better. With this, I would like to wrap up this talk and this session. We've got a couple of minutes of changeover before the next talk. So thank you again, David.