Description
We should have Accessibility (a11y) as a longterm goal.
“When given the choice between an accessible bathroom or a non-accessible one, many people would pick the accessible one: there’s more space, it’s more comfortable, it’s a no-brainer. Digital products are the same. When given the choice, people naturally prefer what’s easier for them to use, to read, or to understand.”
“Accessible design helps everyone. It improves experiences not just for people with disabilities, but for people in temporary situations where their usual way of interacting with your product won’t work — say, if they’re outside and can’t see their screen well or if their mouse runs out of battery and they can only use their keyboard.”
“Accessibility is not a constraint: It is a design philosophy that encourages you to make better choices for your users, and helps you focus on what really matters. Simplicity will always be the most difficult target to reach in a design, and accessibility can be one of the best tools to get you there.”
— Slack Design Blog
KDE Software has seen rapid improvements especially in the User Interface (UI) recently.
Accessibility, another core component of the User Experience (UX), has also seen improvements but we have a long way to go to make our software more accessible and in turn more powerful.
Accessibility does not just describe screenreaders and Accessibility Toolkits (ATK) but for also for example keyboard navigation and focus handling. This one example would help with many use-cases: users who use screen readers, users who use keyboard navigation, users who automate/optimize their workflows, etc. Everyone wins because more accessible means more powerful.
The linux-a11y group would help testing as it is very interested in good, accessible desktops and applications.
It would also allow to create automated UI testing using the ATK as well.
Some areas of focus include:
- Keyboard navigation
- Focus handling
- Screenreader/ ATK integration
- Alternative Input Methods (Voice/ Braille/ Other languages/ OSK/ Dasher, IBus) T8888, T11054
- Documentation of Accessibility features
- Magnification/ Zoom
- Revamping UI of the components
- Adding a section for Accessibility to our HIG T11040
- Improving the accessibility of our documentation in general (for example adding alt= tags to images)
- Automate accessibility tests
- ...
What it will take
It will take a change in how we approach and talk about accessibility. We should think of it as one of our core values rather than how we tend to think of it as a specialization (Plasma Accessibility). We should try to decrease the time it takes to address accessibility issues as much as possible, and to solve them as best as we can. We need to treat accessibility with the urgency it deserves. It will take a lot of reiterating and most importantly a lot of community involvement.
How we know we succeeded
This could be verified if our software :
- can easily be used without mouse interaction
- has proper screenreader support
- can easily be used with alternative input methods
- brings more joy to the (potential) users
Relevant links
List of Accessibility issues: https://phabricator.kde.org/project/view/249/
I am willing to put work into this
- @chempfling (Patches, Testing, Documentation)
- linux-a11y group (Patches, Testing, Documentation)
- @fabianr (Adding more about accessibility to the HIG)
- @gladhorn (helping others getting started, fixing issues when needed, improving Qt accessibility)
- @ognarb (Patches websites)
- @fux (Testing, hopefully Patches and organizational (e.g. sprint) work)
I am interested
- @chempfling
- linux-a11y group
- @lavender
- @lydia
- @ndavis
