Summer Internship Development: Improving the release notes webpage

Posted by Juris Majors on August 30, 2019

Motivation

During our summer internship in Tilburg, we worked on improving the current release notes website and the process of distributing release notes information to customers. Currently, release notes for each quarter are manually formatted, translated to PDF’s and then distributed to the customers. Our goal was to improve the website so that process would become less cumbersome.

Furthermore, the quarterly release notes are available only for a fraction of all 13 TOPdesk languages. Partially this is because the notes have always been manually translated and that takes a lot of time. Therefore, we experimented with different services and translator models to see if automatic translations are viable.

After the bootcamp, we spent the remaining 6 weeks of the internship on developing these functionalities.

Enough blabbering… how did we do all of it in one summer?

Success Criteria of WCAG 2.1 Summarized

Posted by Joppe Kroon on July 15, 2019

The WCAG 2.1 update published in 2018 was a backwards compatible, additions only version. It adds 12 new A and AA (and 2 AAA) level success criteria focused on mobile accessibility, people with low vision, and people with cognitive and learning disabilities.

Reading through all the documentation can be intimidating, whereas a checklist can be too brief. Inspired by the session on WCAG 2.1 at NCDT of 2019, this post summarizes each success criterion; hopefully creating a middle ground between the full specifications and a checklist.

At the end of each section you’ll find a link to the “Understanding” document of the success criterion. Here you’ll find all exemptions, recommended techniques, and more.

If you are in fact looking for a checklist, WebAIM has created a checklist of all 2.x success criteria. Alternatively, the How to Meet WCAG (Quick Reference) is always a good place to start.

Raising awareness about Accessibility

Posted by Anna Maier on May 24, 2019

“Software programs should be usable by everyone.”

I think everyone can agree with that statement. Unfortunately, there is some extra work needed to make a program truly accessible. Even worse, this is often only thought of in the last bit of a project. This leads to accessibility often being cut out because of time and budget constraints. If accessibility would be considered from the start, it could be built in more easily. But how can we make us as developers more aware so that we actively think about accessibility when building the software?

Our answer: let’s experience first hand how (in)accessible our software is!

We decided to host an accessibility challenge for our colleagues. Read below how this turned out…