Make KDE more Accessible for Everybody
Open, Needs TriagePublic

Description

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 moved this task from Backlog to not ready for voting on the Goal Setting 2019 board.
chempfling updated the task description. (Show Details)Jun 11 2019, 1:19 PM
chempfling updated the task description. (Show Details)
chempfling updated the task description. (Show Details)Jun 11 2019, 1:34 PM
chempfling updated the task description. (Show Details)Jun 11 2019, 1:51 PM
chempfling updated the task description. (Show Details)
fabianr updated the task description. (Show Details)Jun 11 2019, 2:05 PM
fabianr added a subscriber: fabianr.
chempfling updated the task description. (Show Details)Jun 11 2019, 2:56 PM
chempfling added a subscriber: fux.
lavender updated the task description. (Show Details)Jun 11 2019, 4:27 PM
chempfling updated the task description. (Show Details)Jun 11 2019, 4:37 PM

@lavender thanks for helping out with the text :). i m not the "best" english speaker XD.

@lavender thanks for helping out with the text :). i m not the "best" english speaker XD.

We all contribute in different ways :) Your text was a great foundation to build on, and I hope others build on mine.

crozbo added a subscriber: crozbo.Jun 12 2019, 6:16 AM

I make suggestion in T11067 to plasma implement better tilling window management. I am not sure does that help in term of Accessibility(for people with disabilities), but it certainly help in Keyboard navigation and Focus handling (and maybe help in voice inputting). So, it seems that my goal suggestion is sub-task for this goal.

chempfling updated the task description. (Show Details)Jun 12 2019, 7:25 AM
chempfling updated the task description. (Show Details)
gladhorn updated the task description. (Show Details)Jun 12 2019, 7:43 AM
ognarb updated the task description. (Show Details)Jun 12 2019, 8:30 AM
ognarb added a subscriber: ognarb.
fux updated the task description. (Show Details)Jun 12 2019, 7:06 PM
chempfling added a comment.EditedJun 13 2019, 12:47 AM

I just read the comments in the blog announcement about the KDE goals and just found a interested guy.

Without proper accessibility we lock them out. How bad. But nice to see some more public interest.

http://blog.lydiapintscher.de/2019/06/09/evolving-kde-lets-set-some-new-goals-for-kde/#comment-272801

lydia updated the task description. (Show Details)Jun 15 2019, 7:10 AM

I'd like to add that the work has started independent of this goal. So @chempfling has already been active for a year, making many improvements, so that basic usage of the desktop is now possible for blind people. Making this an official goal would be really nice, I'd hope to get even more people on board that way.

Additional :), it would help to fit our new shiny HIG!
https://hig.kde.org/accessibility/index.html

special thanks to @fabianr

jrioux added a subscriber: jrioux.Jun 18 2019, 10:50 PM

Also, should KDE review it's default key mapping ? I end up having to configure switch desktop up/down/left/right to crtl+alt+arrow. Are there many other default mapping that could be added ? also never found what was : alt+shift+backtab ...

I like using meta+arrow to title a window, but more commands should be added for true keyboard navigation. like move to desktop/screen, fullscreen, put focus on screen X...

Perhaps review defaults shortcuts, do pools to find what ppl change and try to define a complete set of shortcut commands that would please most ? Or provide different default key-profile ?

chempfling added a comment.EditedJun 18 2019, 11:55 PM

Also, should KDE review it's default key mapping ? I end up having to configure switch desktop up/down/left/right to crtl+alt+arrow. Are there many other default mapping that could be added ? also never found what was : alt+shift+backtab ...

I like using meta+arrow to title a window, but more commands should be added for true keyboard navigation. like move to desktop/screen, fullscreen, put focus on screen X...

Perhaps review defaults shortcuts, do pools to find what ppl change and try to define a complete set of shortcut commands that would please most ? Or provide different default key-profile ?

IMO a good default key mapping is a huge part of Accessibility. I think those should be intuitive and easy to remember.
agree here. many parts are not reachable using shortcuts at all.
try to access the notification area or networks using shortcuts..

it is what i m going to tell here... we talk about enterprise desktop. but simple tasks are not possible using keyboard only at all... until this happens..we don't need even to think about kerberos or special auth algorithms.

we strugle at the basics here.

by the way... also if wikipedia is an other opinion. accessibility is not only a part for blind or impaired people. i m not blind and want to use my desktop like an pro using my keyboard....

Also, should KDE review it's default key mapping ? I end up having to configure switch desktop up/down/left/right to crtl+alt+arrow. Are there many other default mapping that could be added ? also never found what was : alt+shift+backtab ...

I like using meta+arrow to title a window, but more commands should be added for true keyboard navigation. like move to desktop/screen, fullscreen, put focus on screen X...

Perhaps review defaults shortcuts, do pools to find what ppl change and try to define a complete set of shortcut commands that would please most ? Or provide different default key-profile ?

IMO a good default key mapping is a huge part of Accessibility. I think those should be intuitive and easy to remember.
agree here. many parts are not reachable using shortcuts at all.
try to access the notification area or networks using shortcuts..

it is what i m going to tell here... we talk about enterprise desktop. but simple tasks are not possible using keyboard only at all... until this happens..we don't need even to think about kerberos or special auth algorithms.

we strugle at the basics here.

by the way... also if wikipedia is an other opinion. accessibility is not only a part for blind or impaired people. i m not blind and want to use my desktop like an pro using my keyboard....

I completely agree, and in a lot of countries a certain amount of accessibility support is required for enterprise usage. It seems to me we are jumping the gun a little and we need to focus on the fundamentals first.

ervin added a subscriber: ervin.Jun 23 2019, 12:26 PM

I make suggestion in T11067 to plasma implement better tilling window management. I am not sure does that help in term of Accessibility(for people with disabilities), but it certainly help in Keyboard navigation and Focus handling (and maybe help in voice inputting). So, it seems that my goal suggestion is sub-task for this goal.

I agree with this. I prefer stronger and less goals if they are well focused. I think T11067 could be merged into that one without making it incoherent. So what about you join forces here and help refine the KDE Accessibility goal?

Note that this goal is necessary for T11080 to succeed. It's quite common in a lot of companies/governments that they make suitable provisions for those with disabilities, where possible.

Note that this goal is necessary for T11080 to succeed. It's quite common in a lot of companies/governments that they make suitable provisions for those with disabilities, where possible.

indeed. before we think about all the fancy stuff, we need IMO a solid base (not the last 20 percent..).
same i see for input methods... i don't see why input methods are not part of accessibility and why T11054 is separate.
A input method exists to bridge between human and computer aka accessibility. to make a computer more accessible its not necessary only useful for impaired people. IBUS is more than just make Chinese or Vietnamese work...

I also believe T11093 can tie very well with this and T11080. If we brainstorm properly we can standardise certain widgets such that many goals are met at once, with a decreased maintenance burden for everyone involved.

If this goal is chosen, I'd like to make a suggestion:
For me as an application developer it would be beneficial to have detailed guidelines towards this goal:

  • what is considered the base standard?
  • what additional steps can be taken?
  • And most importantly: have some test plans for the different aspects of accessibility that I can check my application against.

If this goal is chosen, I'd like to make a suggestion:
For me as an application developer it would be beneficial to have detailed guidelines towards this goal:

  • what is considered the base standard?
  • what additional steps can be taken?
  • And most importantly: have some test plans for the different aspects of accessibility that I can check my application against.

Howdy,
yea this is a good point :). Thats why we added an initial section to our Human Interface Guidelines. Still a long way to go, but if we don’t start now we miss the train.
See here :
https://hig.kde.org/accessibility/index.html

We are always interested in feedback as its the very initial state but IMO a very good beginning :)

chempfling added a comment.EditedJul 19 2019, 10:08 PM

One reason more to apply this Goal :) otherwise we do not fit out own HIG for large parts.

lydia added a subscriber: lydia.Aug 3 2019, 3:47 PM

Do you consider this ready for voting? If so please move it to the next column.

Ok, I think its ready :) and cross my finger for an A11y open minded community :)

lydia updated the task description. (Show Details)Aug 3 2019, 4:11 PM
lydia added a comment.Aug 13 2019, 8:49 PM

Quick reminder that there are two days left before the voting starts. Please make any changes you still want to make soon.

paulb added a subscriber: paulb.Aug 13 2019, 9:37 PM

Hey @chempfling, I think the title of your goal should be more explicit in what you want to achieve. May I suggest Make KDE more Accessible for Everybody?

Hey @chempfling, I think the title of your goal should be more explicit in what you want to achieve. May I suggest Make KDE more Accessible for Everybody?

Sounds reasonable:). Thanks!

chempfling renamed this task from KDE Accessibility to Make KDE more Accessible for Everybody.Aug 14 2019, 6:45 AM
This comment was removed by chempfling.
lydia added a comment.Aug 24 2019, 3:39 PM

Vote invite were sent to everyone subscribed to the KDE community mailing list and everyone with a developer account. Any contributor who didn't receive one please subscribe to the mailing list to not miss future announcements and send me a quick email (lydia@kde.org) and I'll send you a vote invite.

ndavis updated the task description. (Show Details)Aug 25 2019, 2:37 AM
ndavis added a subscriber: ndavis.
lydia added a comment.Sep 9 2019, 8:24 AM

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board. We'd be happy to support this.

Thanks! I do think that we will work towards better accessibility independent of this. I think we'll have the support of many other developers, but sadly accessibility is not the most mainstream topic. I do intend to meet up with at least @chempfling some time soon (sadly I end up being busy way too often).
I think it was a good exercise to formulate the goal in any case and I think we'll continue to influence other developers to make good choices for all users :)

Oh yea, we will for sure towards improving the accessibility. This is very needed at this point :).
if others here want to help and pick up some accessibility related tasks (what often goes hand in hand with usability, as it also means you can use the desktop with eyboard only), just assign to the accessibility mailing list and join us :).
We are happy for any helping hand and it would be coold to fom a real accessibility team.

https://mail.kde.org/mailman/listinfo/kde-accessibility

@gladhorn, yea lets talk soon. but i know. my job also reserve currently a lot of my time. but this might change as soon as the current ERP projects ends.

KonqiDragon added a subscriber: KonqiDragon.EditedOct 4 2019, 9:26 AM

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.


I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

chempfling added a comment.EditedOct 4 2019, 9:55 AM

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.


I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

Sounds great, but maybe the wrong threat? i cannot bring flash formatting and accessibility together in my mint somehow. Maybe can you explain?

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.


I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

Sounds great, but maybe the wrong threat? i cannot bring flash formatting and accessibility together in my mint somehow. Maybe can you explain?

This "easy" way of formatting in Linux Mint is available only in Cinnamon edition.

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.


I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

This thread is about improving access to KDE software to all - A11y, not about individual issues. Please keep comments friendly and helpful -- and on-topic.

Thanks.