A software developer's life can get lonely. Developers spend a lot of time immersed in their code, and often don't get to see the direct impact of their work on the users. That is why events like Randa Meetings are necessary. They help build bonds within the community and show the developers that their work is appreciated.

Randa Meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE. --- Scarlett Clark

Randa Meetings are a yearly collection of KDE Community contributor sprints that take place in Randa, Switzerland. With origins dating back to a Plasma meeting in 2009, Randa is one of the most important developer-related events in the community.

View from Randa. Photo by Gilles Caulier, CC BY 2.0

This year, Randa Meetings were held from September 10 to September 16, and were centered around a meaningful theme - accessibility.

Accessibility in Free and Open Source Software

Accessibility is incredibly important, yet so often neglected in the process of software development, and implemented almost as an afterthought. Users with disabilities and impairments often find themselves excluded from using the software, and prevented from participating in activities that the rest of us take for granted. Essentially, the software makes them feel as if they don't matter.

To remedy this, many governments enforce laws requiring software to be accessible. There are also accessibility standards, guidelines, and checklists to help developers make their software accessible to all.

FOSS communities and projects have the potential to play a major role in driving software accessibility efforts because of their open nature. People with disabilities can communicate directly with developers, report issues, and request features that they need. Proprietary products are rarely this open to feedback, not to mention the fact they are often very expensive.

Accessibility Settings module in Plasma 5

Assistive technology covers a wide range of products and solutions: from screen magnifiers, screen readers, and text prediction methods to text-to-speech interfaces, speech recognition software, and simplified computer interfaces. There are also advanced solutions like 3D-printed prosthetic limbs, and those that allow controlling the mouse by moving the head or just the eyes.

The best thing about all this technology is that it benefits everyone. Although people usually associate the word "accessibility" with hearing or visually impaired people, assistive technology can make life easier for many other groups: dyslexic or illiterate people, cognitively disabled people, the elderly, anyone with limited mobility or just bad eyesight.

The analogy is clear with wheelchair-accessible spaces, which are useful to parents with baby strollers, people with bicycles and shopping carts, and delivery drivers. Likewise, improving keyboard navigation, image and color contrast, and text-to-speech tools results in satisfaction among non-disabled users. Making software accessible means making software better.

Making KDE Software More Accessible

Generally speaking, there are two ways to make software accessible: either by building special accessibility-focused tools from scratch, or by implementing accessibility features and improvements into existing applications. The latter is what the Randa Meetings 2017 were all about.

digiKam with David Edmundson from Plasma in the background. Photo by Gilles Caulier, CC BY 2.0

The developers created a useful KWin plugin that can simulate different types of color blindness. This will help in all future accessibility efforts, as it helps developers understand what their color schemes will look like to visually impaired users.

KMyMoney was made more accessible via improvements to keyboard navigation. New keyboard shortcuts were added, and others simplified to make them easier to use.

Randa Meetings 2017 were made special by Manuel, a visitor from Italy who stayed at the Randa house during the sprint. Manuel is a deaf user, and he took the time to explain the problems that hearing-impaired users encounter with KDE software, and software in general. His feedback was extremely valuable in the context of the sprint's theme, and helped developers come up with accessibility-oriented solutions.

Meeting in Randa with other participants makes you aware of deficiencies, possibilities, and needs. For a newcomer, like myself, it was also a chance to meet some community members, see what kind of people build KDE software, and take a look behind the scenes. --- Lukasz Wojnilowicz

Apart from fixing individual applications, a lot of work was done on the Plasma desktop environment itself. Accessibility-related improvements include the ability to navigate the Plasma panel using voice feedback and the keyboard. The following video demonstrates this feature in action:

KRunner was made completely accessible, and this change is visible in Plasma 5.11. The Orca Screen Reader works well with KRunner, and can read the entered query, as well as let the user know which element of the interface is currently focused.

There was also a round of discussions on best practices for accessibility in KDE software. When testing software, the developers should try to use it only with their keyboard, and then only with the mouse. Too much customization is not a good idea, so it should be avoided, especially when it comes to colors, fonts, and focus handling.

Another good practice is to test the application with a screen reader. This experience should highlight potential issues for disabled users. In the end, it all comes down to empathy - being able to put yourself in the user's shoes, and the willingness to make your software available to as many people as possible, without excluding anyone.

More Plans and Achievements from the Randa Meetings 2017

Of course, the developers worked on so much more than just accessibility. The KDE PIM team discussed the results of their KMail User Survey, and tackled the most pressing issue reported by the uses - broken and unreliable search. They also ported the entire Kontact codebase away from the obsolete KDateTime component.

KMyMoney saw some important changes. All plugin KCM modules were ported to KF5. The backup feature is, well, back up and available to use, and database loading was improved so as to prevent the incompatibility between new and old KMyMoney files.

After successfully participating in Google Summer of Code, the digiKam team gathered in Randa to further polish the new code contributed by students. They also worked on the media server functionality, which allows users to share their photo collections across different devices (smartphones, tablets, TVs...) using DLNA.

The developers of Kube worked on resolving an annoying issue with live queries which slows down email synchronization, especially when there are thousands of emails. They also discussed the possibility of implementing an HTML composer to edit emails in Kube, and made plans for GPG implementation. In collaboration with developers from other KDE projects, they explored the options for making Kube cross-platform, and looked for the best way to build Kube on macOS and Windows. Finally, they implemented a visualization in the configuration dialog which indicates when the user input is invalid in configuration fields.

Last but not least, Kdenlive received color correction improvements, and the developers worked on bringing back the popular TypeWriter effect. They also fixed the import of image sequences, worked on porting Kdenlive to Windows and macOS, and removed the warning about missing DVD tools that used to appear when starting Kdenlive for the first time.

Looking Forward to the Next Randa Meetings

With another successful Randa Meetings behind us, we can start planning for the next session.

If you like the work our developers are doing, you can directly support it by donating to KDE. You can also contribute to KDE and make an impact on the users by joining our mentored project called Season of KDE.

Who knows, maybe in the future you too will attend the Randa Meetings!