In T12192#216454, @hein wrote:

@chwmpfling Definitely the plan! Will appreciate your review

Sounds awsome, i have to play with its accessibility later.
Would be cool to keep accessibility in mind just from beginning to have a proper focus and keyboard handling :). I can take a look at the accesdibility roles and labels then if wanted.

In T10837#210437, @vinzenzv wrote:

If you're looking for a location for this sprint just ping me. Maybe we at TUXEDO Computers could arrange something here in southern Germany.

In T11520#203532, @thiagosueto wrote:

Quite interesting stuff! I did not know about Ctrl+Space, F7, F10, Shift+F10, Ctrl+F4, Ctrl+Shift+PictureUp/Down.

I also did not know that Pos1 = Home and Picture Up/Down = PageUp/PageDown.

One thing I noticed is that Ctrl+F4 conflicts with Plasma's default "Switch to Desktop 4". It's a non-issue if Ctrl+W exists, though.

In case of UI accessibility i know that the following terms are true and most importaint for basic keyboard only navigation:

• all combinatins with META are made for "global scope" like window manager, desktop environment and such.
• Alt + XXX combinations are used for the menu bar of the current application
• Tab: brings the user to the next Element
• Shift + Tab: brings the user to the previouse element
• Ctrl + Tab: brings the user to the next Panel ( logical group of widgets)
• Ctrl + Shift + Tab brings the user to the prviouse Panel ( logical group of widgets)
• Arrow keys: bring the focus to the next element in the arrow direction
• Return: activates current element (like leftclick on current focused element)
• Spacebar: activates current element (like leftclick on current focused element)
• Shift+ Arrow: mark entries in direction
• Ctrl + Spacebar: select entries with cherrypicking (hold Ctrl to navigate around and not lose the current selection; navigation without hold Ctrl removes selection)
• F10: focus/ (on some systems also opens ) the menubar of the current application
• Shift + F10: opens context menu (like rightclick on current focused element) - not every keyboard has an "menu key" thats why this is an alternative -> special laptops
• ESC: stop current activity
• F7: Toggles an Caret on / off -> Textcursor
• F1: Open Help
• F2: Rename / edit
• F3: Search
• Alt + F4: Close current application
• Ctrl + Q: Close current application (in multi tap applications)
• Ctrl + F4: Close current Tab (in multi tap applications)
• Ctrl + W: Close current Tab (in multi tap applications)
• F5: Refresh
• F11: Fullscreen / Window Mode Toggle
• Pos1: focus first element
• End: focus last element
• Picture up/ down: move all the screen up / down
• Ctrl + Picture up/ down: go to next tab.
• Ctrl + Shift + Picture up / down: go to previous tab

In T11074#203505, @KonqiDragon wrote:

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.

i m all in with this. Keyboard shortcuts an navigation is one of the most basic parts for accessibility and power users. I will do some investigation here and come back with hopefully something useful.

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.

Awsome, Thanks!
@broulik could you take a look at? we should have now an own accessibility role for notifications what needs to be set.

In T11074#195406, @paulb wrote:

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?

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

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

In T11074#192473, @johanneszarl wrote:

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.

In T11074#191715, @feverfew wrote:

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.

In T11074#189317, @jrioux wrote:

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..

Landed.
Thanks!

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

In D17936#478833, @ognarb wrote:

Hello @chempfling, I saw that you was involved with accessibility around KDE. I would love to get some feedback on the accessibility of this website http://docs.carlschwan.eu.

I already know about the accessibility problem with the language picker (I will change it), but I would love to get more feedback and improvement ideas to make the documentation more accessible.

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

Thanks a lot for your comment.
I consider that proper accessibility is one of the thing that is/was lacking in Elisa and should be taken for granted.

you are completly right.
A11y is important in enterprise sector. thats why i created T11074 its very needed and its already too long out of scope

By the way: Thanks for care about accessibility! this is awsome :).

I added an Issue for adding the notification role:
https://bugreports.qt.io/browse/QTBUG-76333

Here some update from the a11y side:

• We just prepared an Accessibility section in our HIG (Human interface Guidelines), what are ready to land. Issue T11040

https://invent.kde.org/websites/hig-kde-org/merge_requests/22

• I just brought up the idea to make accessibility as an main goal for 2019. See Issue T11074

This is ready to land.
https://invent.kde.org/websites/hig-kde-org/merge_requests/22

Thanks for clearification :) . Again what learned.
Looks good to me!

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

+1 here :).
additional, phabricator is not very accessible to blind people what prevent them to dive in for help

In T11054#187796, @lavender wrote:

Should we have input methods as a goal or maybe something a bit more broad such as Accessibility?

i think you don't need the
"Accessible.onPressAction"
stuff when you use

• onPressed

insteed of :

• onClicked

In T11041#187327, @broulik wrote:

It's on purpose they don't get focus as they should never interrupt you. We need to find a way to address this in some way without jeopardizing the default usecase.

I found an example extension for gnome-shell. It sends the clipboard (when it changes) to orca using ATK to make orca announce the clipboard change.

In T11041#187327, @broulik wrote:

It's on purpose they don't get focus as they should never interrupt you. We need to find a way to address this in some way without jeopardizing the default usecase.

I got information that there is some financal support for stuff like that.
but i m too late :/. So i will not stay at plasma sprint.
still my plan is to have an A11y sprint.

In D21608#474960, @ngraham wrote:

In D21608#474936, @chempfling wrote:

an small thing we need to take care, is that also the current active element gets the focus. screenreaders react to the "focus:true" property to present the current active element.
in Kickoff this is an issue. I will test this here next couple of days.
Thanks!!! :).

In fact that was just improved/fixed yesterday in D21081!

Woe :) cool this looks very promising.
you can just add Plasma Accessibility i will try to review then as soon as i find time :)
thanks for care about that :).

Is reviewed. i need to merge this.

In T10837#182826, @gladhorn wrote:

Hi, I very much think we should meet :) The Plasma sprint is a good option, since we can then influence the right people. Do you think it would be possible to travel to Valencia for you Chrys?

If we add the desktop frame we should add the desktop icons as well or/and maybe the "normal icons".

Seems that the scheduled week has a lot of holidays here in germany. so i may be able to join you for several days.

this is a bad week for me as there are a lot of familiy internal stuff like birthdays and stuff.
But I would be happy to join you guys. let me give a talk to my girlfriend and familiy first. If i can join, I assume could not join for all the week as i have already scheduled my per year vocation to other dates.

@davidedmundson, ping?

I close this and keep the outstanding issues on track in T10836 as the initial bits are working now.

@gladhorn maybe you want to review my patch when you find a quite minute :).

In T10099#182472, @gladhorn wrote:

The initial implementation was written, but lacked testing by actual users. I guess setting the terminal role should be rather simple (just setting the property in the right place). I haven't looked at this in ages, let me know if you want help :)

In T10019#182504, @gladhorn wrote:

You can build Qt and run Kate with the patched Qt version. Sadly the change to Qt needs more work and I haven't gotten around to it for a long time :(

Maybe it would be a good idea to merge all the ATK roles with the QT ones? So we could provice all needed roles?
there is stuff what might be nice for other places as well. like ATK_ROLE_ICON.

https://mail.gnome.org/archives/orca-list/2019-April/msg00032.html

3. and way to access the volume is still needed. i assigned a key activate it.

seems to work mostly now with plasma 5.15

will get fixed by D20449
no more changes are needed then.
i mark this as done as the real problem isnt the a11y label and role