Language and accessibility on the internet.

Posted by Floris Claassens on February 17, 2022

A gathering of research, bad opinions and some extra curiosities

Screen readers are a great piece of software that help people with a visual impairment navigate the digital world. Though screen readers can interpret a lot of web content without any help, from time to time they do need some cues from developers on how to interpret the content. One of those cues is the language of the page. Many people will consume multilingual content at some point in their life. Screen readers need a way to find out which language to use for their pronunciation.

On the internet screen readers use the “lang” attribute (short for language) which can be set on the html element of the page. As the value of this attribute developers can use a (usually) two to four letter code to designate the main language of the page. The first two letters depict the language, and the last two letters depict the dialect. For example, fr-fr is the code for metropolitan French while fr-ca is the code for Canadian French. If you are familiar with SEO (search engine optimization) you might also have heard about the “hreflang” attribute, which uses the same language codes. Though they might seem very similar, they serve a very different purpose.

Testing Accessibility with Accessibility Insights

Posted by Anna Maier on December 9, 2019

There are many tools out there that help you check if your website or webapp is accessible. Most of them do an automatic check based on some accessibility guidelines. Some also provide functionality to do checks yourself, for example, to check the color contrast. The open source tool Accessibility Insights takes a different approach: on top of the usual automated checks there is a set of guided manual checks. This makes it a great tool to learn about accessibility testing and programming.

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…