Change Details

(still a draft subject to changes) == Motivation == In the KDE community, we are creating amazing software, but unfortunately, not everyone can make use of it. For example, if you are blind, you won't be able to use Plasma to its full extent because some parts of the UI aren't accessible with the keyboard, or your screen reader can't read the content of a widget, or you can't type and instead need voice control, ... And it is a much bigger topic than just screen readers and keyboard navigation. We need to improve our focus handling, add special input methods (Voice, Braille, ...), improve the color contrast of UI elements have a way to zoom inside the UI (magnification), ... And while these changes are targeted at user groups with some disabilities, this will also help users without disabilities since better contrasts and keyboards are something normal users also beneficts. This would also help with the adoption of Plasma in the public and private sector since compliance with accessibility standards is now required in the EU and USA. == Plan == From an accessibility point of view, I think it would be good to first look at the current state of Plasma and KDE software in general when using it with a screenreader and how Wayland and containers (Flatpak) change the situation. This is important because we need to exactly know where we are and in which direction we are moving. I believe it would also be a good idea to invite some interested members to an accessibility training workshop ideally targetted at Qt application developers, but even one for web developers can be helpful to learn to identify issues. == Community == Accessibility is not something that can be solved in one place but needs involvement in many parts of KDE. Some part of the issue needs to be solved inside our libraries (KDE Frameworks) or Qt. Other parts need to be solved inside Plasma and finally, each app also needs to be checked to see if they behave correctly. There is also some completely independent topic, that can be worked on by different teams. e.g. fixing the keyboard navigation in apps doesn't involve deep knowledge of how the AT-SPI protocol works and can be handled by two different team And more importantly, this is something that also needs to be solved in the greater Linux and Free Software community and this is an occasion to work closely with our friends at Qt and GNOME. == Risks and needs == The primary risk that could happen with this goal is that after it is voted, nothing really happens and nobody is motivated to work on it. This is due to the fact that working on the accessibility topic is a bit of a thankless task with not a lot of visibility for most of the users. I hope the KDE goal will help make this work more visible and additionally accessibility is actually a good reason to ask for funds. I know that NLNet for example is doing accessibility audits and we might also want to look in the Prototype Fund. Even if we don't achieve everything we wanted in the 2 years period, it will still be a net improvement to the status quo. And since there are various areas to work on, I'm not expecting a blocking issue on one area to block other parts of the work. We mostly need people with disabilities who can serve as guinea pigs and give us feedback and developers working on this feedback :) But having people who blog about the improvements, and write documentation is also important and generally any help is more than welcome :) == Champion == I'm Carl and I'm part of the community since 2018. I was involved with various parts of the community first documentation, then web and now mostly Kirigami app development (Kalendar, Tokodon and NeoChat). I'm a bit familiar with the accessibility topic. I developed [Konstrat](https://invent.kde.org/accessibility/kontrast/) 2 years ago and did various changes to improve keyboard navigation in KDE apps and I'm generally interested in this topic and I want to dig deeper into it. == Interest == This section is intended for people other than the Champion to sign up and show support for the Goal. If you are interested to actively joining the effort and doing the work, add your name below (this does not count as voting for the Goal):

(still a draft subject to changes) == Motivation == In the KDE community, we are creating amazing software, but unfortunately, not everyone can make use of it. For example, if you are blind, you won't be able to use Plasma to its full extent because some parts of the UI aren't accessible with the keyboard, or your screen reader can't read the content of a widget, or you can't type and instead need voice control, ... And it is a much bigger topic than just screen readers and keyboard navigation. We need to improve our focus handling, add special input methods (Voice, Braille, ...), improve the color contrast of UI elements have a way to zoom inside the UI (magnification), ... And while these changes are targeted at user groups with some disabilities, this will also help users without disabilities since better contrasts and keyboards are things that benefit everyone. This would also help with the adoption of Plasma in the public and private sector since compliance with accessibility standards is now required in the EU and USA. == Plan == From an accessibility point of view, I think it would be good to first look at the current state of Plasma and KDE software in general when using it with a screenreader and how Wayland and containers (Flatpak) change the situation. This is important because we need to exactly know where we are and in which direction we are moving. I believe it would also be a good idea to invite some interested members to an accessibility training workshop ideally targetted at Qt application developers, but even one for web developers can be helpful to learn to identify issues. == Community == Accessibility is not something that can be solved in one place but needs involvement in many parts of KDE. Some part of the issue needs to be solved inside our libraries (KDE Frameworks) or Qt. Other parts need to be solved inside Plasma and finally, each app also needs to be checked to see if they behave correctly. There is also some completely independent topic, that can be worked on by different teams. e.g. fixing the keyboard navigation in apps doesn't involve deep knowledge of how the AT-SPI protocol works and can be handled by two different team And more importantly, this is something that also needs to be solved in the greater Linux and Free Software community and this is an occasion to work closely with our friends at Qt and GNOME. == Risks and needs == The primary risk that could happen with this goal is that after it is voted, nothing really happens and nobody is motivated to work on it. This is due to the fact that working on the accessibility topic is a bit of a thankless task with not a lot of visibility for most of the users. I hope the KDE goal will help make this work more visible and additionally accessibility is actually a good reason to ask for funds. I know that NLNet for example is doing accessibility audits and we might also want to look in the Prototype Fund. Even if we don't achieve everything we wanted in the 2 years period, it will still be a net improvement to the status quo. And since there are various areas to work on, I'm not expecting a blocking issue on one area to block other parts of the work. We mostly need people with disabilities who can serve as guinea pigs and give us feedback and developers working on this feedback :) But having people who blog about the improvements, and write documentation is also important and generally any help is more than welcome :) == Champion == I'm Carl and I'm part of the community since 2018. I was involved with various parts of the community first documentation, then web and now mostly Kirigami app development (Kalendar, Tokodon and NeoChat). I'm a bit familiar with the accessibility topic. I developed [Konstrat](https://invent.kde.org/accessibility/kontrast/) 2 years ago and did various changes to improve keyboard navigation in KDE apps and I'm generally interested in this topic and I want to dig deeper into it. == Interest == This section is intended for people other than the Champion to sign up and show support for the Goal. If you are interested to actively joining the effort and doing the work, add your name below (this does not count as voting for the Goal):

(still a draft subject to changes) == Motivation == In the KDE community, we are creating amazing software, but unfortunately, not everyone can make use of it. For example, if you are blind, you won't be able to use Plasma to its full extent because some parts of the UI aren't accessible with the keyboard, or your screen reader can't read the content of a widget, or you can't type and instead need voice control, ... And it is a much bigger topic than just screen readers and keyboard navigation. We need to improve our focus handling, add special input methods (Voice, Braille, ...), improve the color contrast of UI elements have a way to zoom inside the UI (magnification), ... And while these changes are targeted at user groups with some disabilities, this will also help users without disabilities since better contrasts and keyboards are something normal users also benefictss that benefit everyone. This would also help with the adoption of Plasma in the public and private sector since compliance with accessibility standards is now required in the EU and USA. == Plan == From an accessibility point of view, I think it would be good to first look at the current state of Plasma and KDE software in general when using it with a screenreader and how Wayland and containers (Flatpak) change the situation. This is important because we need to exactly know where we are and in which direction we are moving. I believe it would also be a good idea to invite some interested members to an accessibility training workshop ideally targetted at Qt application developers, but even one for web developers can be helpful to learn to identify issues. == Community == Accessibility is not something that can be solved in one place but needs involvement in many parts of KDE. Some part of the issue needs to be solved inside our libraries (KDE Frameworks) or Qt. Other parts need to be solved inside Plasma and finally, each app also needs to be checked to see if they behave correctly. There is also some completely independent topic, that can be worked on by different teams. e.g. fixing the keyboard navigation in apps doesn't involve deep knowledge of how the AT-SPI protocol works and can be handled by two different team And more importantly, this is something that also needs to be solved in the greater Linux and Free Software community and this is an occasion to work closely with our friends at Qt and GNOME. == Risks and needs == The primary risk that could happen with this goal is that after it is voted, nothing really happens and nobody is motivated to work on it. This is due to the fact that working on the accessibility topic is a bit of a thankless task with not a lot of visibility for most of the users. I hope the KDE goal will help make this work more visible and additionally accessibility is actually a good reason to ask for funds. I know that NLNet for example is doing accessibility audits and we might also want to look in the Prototype Fund. Even if we don't achieve everything we wanted in the 2 years period, it will still be a net improvement to the status quo. And since there are various areas to work on, I'm not expecting a blocking issue on one area to block other parts of the work. We mostly need people with disabilities who can serve as guinea pigs and give us feedback and developers working on this feedback :) But having people who blog about the improvements, and write documentation is also important and generally any help is more than welcome :) == Champion == I'm Carl and I'm part of the community since 2018. I was involved with various parts of the community first documentation, then web and now mostly Kirigami app development (Kalendar, Tokodon and NeoChat). I'm a bit familiar with the accessibility topic. I developed [Konstrat](https://invent.kde.org/accessibility/kontrast/) 2 years ago and did various changes to improve keyboard navigation in KDE apps and I'm generally interested in this topic and I want to dig deeper into it. == Interest == This section is intended for people other than the Champion to sign up and show support for the Goal. If you are interested to actively joining the effort and doing the work, add your name below (this does not count as voting for the Goal):